That's pretty much the question's title. I must be missing some signals interpretation here...
On PyGTK, I'm doing:
class Foo:
def __init__(self):
self.gladefile = gladefile
self.wTree = gtk.glade.XML(self.gladefile, 'some_window')
self.window = self.wTree.get_widget('some_window')
events = { 'on_code_submit_clicked' : self.submit }
self.wTree.signal_autoconnect(events)
def submit(self):
self.window.destroy()
os.system('external_script')
code = Foo()
What's happening, is that when the button is clicked, it stay pressed, then the script runs, and after the external program is closed, the window "blinks", getting destroyed and recreated again.
I also tried the "pressed" and "released" signals.
The behavior I need:
Click on the button
Destroy the current window
Run external script (that will open another program's window)
Recreate the Foo() window after closing the external app.
What I can imagine is that the event is being run during the clicked event, not after. That's why the window remain opened. The PyGTK docs don't say anything about something like gtk_signal_connect_after on the glade page, that leaves me totally lost about it.
Why not hide the window and show it after the external script?
self.window.hide()
os.system('external_script')
self.window.show()
It looks like you'll have to call the external script from a thread.
I haven't worked with threads with python, but it looks like the threading module would do the job (at least that's what I would try). Glib also has thread support, but I can't find the pygtk docs for it.
When the external script has finished, don't recreate Foo from the thread but schedule a callback function to do so using gobject.idle_add. This is because all GUI work should be done on the gtk event thread, otherwise your program may crash.
Posting my solution... it's easy as.
self.window.hide()
glib.idle_add(subprocess.call, ['external_script', 'param'])
glib.idle_add(self.window.show)
Related
In my Cocoa application I have some computations done in the background. The background work is runned with DispatchQueue.global(qos: .utility).async.
This background task may report errors by showing a modal NSAlert via DispatchQueue.main.async.
Also, in my application user can run NSOpenPanel to open some files (with NSOpenPanel.runModal).
The problem is that if the user opens NSOpenPanel and at the same time the background task shows NSAlert, the application may hang.
user opens modal NSOpenPanel
background task opens modal NSAlert atop the NSOpenPanel
user clicks Close inside NSOpenPanel (it really can access NSOpenPanel despite the more modal NSAlert present).
both NSAlert and NSOpenPanel being closed and application hangs with main thread blocked inside NSOpenPanel.runModal()
application will not hang if user first close NSAlert and then NSOpenPanel.
The minimal code sample (the test IBaction is binded as the action for the button in the main window)
import Cocoa
#NSApplicationMain
class AppDelegate: NSObject, NSApplicationDelegate {
#IBOutlet weak var window: NSWindow!
#IBAction func test(_ sender: Any) {
//run some work in background
DispatchQueue.global(qos: .utility).async
{
sleep(1) //some work
//report errors in the main thread.
DispatchQueue.main.async {
let alert = NSAlert();
alert.informativeText = "Close NSOpen panel before this alert to reproduct the hang."
alert.runModal()
}
}
//user want to open a file and opens the open file dialog
let dlg = NSOpenPanel();
dlg.runModal();
}
}
So, what's wrong with this code and why it cause the hang in particular use cases? And how can I prevent such a hang?
Additional note: I discovered, then if I replace dlg.runModal() with NSApp.RunModal(for: dlg) (which is exactly the same as per Apple documentation), this will fix hang in the usecase described above.
But it still will close NSAlert automatically right after closing NSOpenPanel. And I still can't understood why this behave as it does.
Update
I updated the code above to include full code of AppDelegate class of minimal reproducible application. To reproduce the case, just create new SwiftApp in XCode, replace AppDelegate code, add button in the main window and wire button's action with test func. I also placed full ready-to-compile project on github: https://github.com/snechaev/hangTest
The code for configuring NSOpenPanel and NSAlert along with their results handling is excluded as such a code does not affect the hang.
I think you are deadlocking the main queue because runModal() blocks the main queue in two places of your code at the same time. If your code is reentrant, that is what you get.
Possible solutions:
Please avoid the use of app modal windows and use instead window modal windows a.k.a. sheets. To know how to use NSOpenPanel as a sheet, attach it to the window it pertains to. For an example, please see this answer:
NSOpenPanel as sheet
You can set a flag that prevents the user from opening the NSOpenPanel if the alert is being shown, but that is ugly and does not solve any future problems that can cause other deadlocks because most probably your code is reentrant.
I would like to add some details in addition to #jvarela answer and make some resume about the my issue.
Looks like there is no way to solve the problem with having the NSPanel/NSAlert as modal windows with blocking the caller thread (with runModal).
The non-modal (NSPanel.begin()) or modal non-blocking (NSPanel.beginSheet, NSPanel.beginSheetModal) do not lead the hang, but still lead to to unexpected automatic closing of NSAlert if user try to close NSPanel before NSAlert. Moreover, to use such a non-blocking approach, you will be forced to refactor the whole your codebase to use callbacks/completion handlers instead of blocking operations when using NSPanel.
I do not found the reason why the NSPanel not being blocked and continue to receive user input when I show modal NSAlert atop of it. I suspect that is because of security mechanism which run NSPanel in a separate process, but I have no evidences about this. And I still interested about this.
For the my current project I decide to leave the blocking way to use of NSPanel, because I have large codebase and it will hard to change it all in moment to use of completion handlers. For particuluar case with NSPanel + NSAlert I just don't allow user to open NSPanel while this particular background work in progress. The user now should wait background work to finish or manually cancel the work to be able to run Open file functionality.
Is there a property that tells if a form is deactivated by other form ShowModal procedure ?
EDIT :
My program has a tray icon that brings to front the main form when it's clicked. I want to disable this when another window is shown in modal state. Because not doing so the main form (which is disable) will cover the modal form and completly block my program.
This behaviour is to be expected. When a modal form is shown, the other forms are disabled. You don't need to disable anything at all, the framework already handles it all for you. The beep is sounding because you are attempting to interact with a disabled form.
If you want to be notified when your window has been disabled, for any reason, not just because a modal form has been shown, listen to the WM_ENABLE message. To test whether or not your main form has been disabled. Do that by calling the IsWindowEnabled Win32 function.
Having said that I feel that it is likely you've not diagnosed the issue correctly. It sounds like you might be suffering from window ownership problems, which are common in Delphi 6. Or perhaps you are attempting to restore the application incorrectly from your notification icon code. Use Application.BringToFront for that.
The VCL's handling of modal dialogs seem very mixed up. When you show a system provided modal dialog, e.g. MessageBox, windows are disabled whether or not they are visible. However, the VCL only disables visible windows when ShowModal is called. What's more, you cannot use Enabled to test whether or not the window is disabled, you must use the IsWindowEnabled Win32 function.
You can test Application.ModalLevel at any point in time to find out if there's a modal form. E.g.:
if Application.ModalLevel = 0 then
MainForm.Visible := True;
Note that non-TCustomForm descendants will not set modal level, API dialogs like a file open dialog or MessageBox for instance. If there's a possibility of such a thing, you might surround code that runs those dialogs with ModalStarted and ModalFinished.
It doesn't seem necessary in your case, but if you somehow need to be notified that a form/dialog is going modal, you can attach a handler to Application.OnModalBegin and Application.OnModalEnd events. You can use an TApplicationEvents component for that.
I am trying to open a modal window during a click handler to verify the user action but the window doesn't appear until the handler completes. The window code can be as simple as the following and it still will not display so it isn't something to do with my abstract class.
Window w = new Window();
w.setModal(true);
w.setImmediate(true);
// Add components etc etc
UI.getCurrent().addWindow(w);
I could add the action code to the windows OK/Yes handler but that would stop me creating a generic Message class to simplify/stop code duplication.
I am guessing there is something I dont understand about how Vaadin/GWT works (still a newbie!), could someone point me in the right direction?
Cheers
For UI stuff, you have to stop thinking of sequencial programming,
better to think about event-driven concepts.
For Vaadin you could create a Dialog Window which asks the yes/no question.
In you app you create this dialog and display it.
And you attach a event-handler which is fired when the user clicks yes/no,
and inside this handler you then do the required actions in your code.
You can also look at this add-on
https://vaadin.com/de/directory#addon/confirmdialog
The right direction is architecture overview https://vaadin.com/book/vaadin7/-/page/architecture.html#architecture.overview
In other words your code makes only response from server side, but only client side can show "modal" window.
In your case you have to create handler for ok button click event and wait for this event
In our project, we're using gtkmm and we have several classes that extend Gtk::Window in order to display our graphical interface.
I now found out what call produces the behaviour (described in the previous revision. The question now slightly changed.)
We're displaying one window, works like a charm.
Then, we have a window which displays various status messages. Let's call it MessageWindow. It has a method setMessage(Glib::ustring msg) which simply calls a label's set_text().
After some processing, we hide this window again and we now show a toolbar. Just yet another simple window, nothing crazy.
For all windows applies: The main thread calls show() on the window and creates a new thread which calls Gtk::Main::run() (without argument).
That's how it should be, until now.
The problem starts here: The main thread now wants to call MessageWindow::setMessage("any string"). a) if I call this method, the message window reacts completely correctly. But afterwards, the toolbar-window is displayed empty. b) if I don't call it, the message window doesn't change the label (which is absolutely clear), and the toolbar window is displayed as it should.
Seems like the windows are messing up each other.
Now the question:
If my gui-thread is blocking in Gtk::Main::run(), how can I now change the text of a label?
We're using gtkmm-2.4 (and no, we cannot upgrade)
Any help is appreciated.
Wow! That's complicated...
First: you should not manipulate windows from several threads. That is you should have just one GUI thread that does all the GUI work, and let the other threads communicate with it.
It is theoretically possible to make it work (in Linux; in Windows it is impossible) but it is more trouble than it is worth.
Second: the line Gtk::Main main(argc, argv) is not a call, it is an object declaration. The object main should live for the duration of the program, so if you use it in a object constructor, as soon as you return from it, the object will be destroyed! Just put it at the top of the main function and forget about it.
UPDATE: My usual approach here is to create a pipe, a g_io_channel to read, and write bytes on the other end.
Other option, although I didn't test it is to call get the GMainContext of the main thread and then g_idle_source_new() and attach that source to the main context with g_source_attach(). If you try this one and it works, please post your result here!
In my HTA, I hold it it open if an error occurred, and close it if everything was successful. At the start, I have the sysmenu property set to no because I do not want the user to close the HTA until it's finished. At the end, I want them to be able to click on the close button. Here's what I typed up to try to achieve this, but it doesn't seem to work? I suspect there is something I need to do to get the HTA to refresh it's windows properties?
Please note that any solution that completely reloads the window and/or makes the script execute again is not acceptable
If Not bHoldOpen Then
Call window.close
Else
Dim tagHTA
Set tagHTA = document.getElementsByTagName("hta:application").item(0)
Call tagHTA.setAttribute("sysmenu","yes")
End If
You cannot change it at runtime, its only available in the HTA: block as its value is used to determine how the physical window is to be initially created.
I thought you could produce a warning using the onBeforeUnload event & call cancelBubble to abort the close, but I tried it in IE8 and it still seems bugged; http://support.microsoft.com/kb/946214.
It would probably be simpler and easier for the user to comprehend if you were yo just unhide a "Close" button when the process completed.