My understanding is any modal dialog automatically has its own message-pump, running on a thread dedicated to that dialog - is that right?
If so, how does a modal dialog's existence affect the main application's message loop? Do both run in parallel, does one take priority?
I have a situation where a modal dialog seems to get stuck for several seconds waiting for something, and wondered if it's possible the dialog is forced to wait until the main application thread is not busy?
As IInspectable explained, the modal dialog will run in the same thread as the caller. Therefore if you run the dialog from the main UI thread that has your main message loop, you'll end up with a nested message loop. The stack would look something like:
WinMain
YourMainMessageLoop
DispatchMessage
SomeMessageHandler
DoModal
and DoModal spins in its own GetMessage/TranslateMessage/DispatchMessage loop. The main message loop (YourMainMessageLoop in the sample stack above) is "active" in the sense that it's still running, but it's blocked by the dialog's message loop. Execution won't return to YourMainMessageLoop until DoModal exits.
Note that even if you're within the modal dialog's message loop, your other windows will still handle messages because GetMessage and DispatchMessage will still retrieve and direct messages to those windows and invoke their WndProcs.
Related
I'm building an application with a main window and a sub-window that I'd like to present as a modal session. So I'm using this code within the window controller:
self.session = [[NSApplication sharedApplication] beginModalSessionForWindow: self.window];
[[NSApplication sharedApplication] runModalSession: self.session];
However, regardless of where I put this code - in windowDidLoad, in a post-windowDidLoad call from the main window, or even in the window controller's init function - what I get is a modeless sub-window. The sub-window appears over the main window, but the main window continues to respond to input events.
What am I doing wrong?
nvm - found my answer by reading some examples. (Once again, hours of research before posting on Stack failed to yield answers, and I stumble across insight right after posting.)
For posterity, here's the answer: beginModalSessionForWindow doesn't work like runModalForWindow.
With runModal, you can execute that code anywhere, and Cocoa will immediately halt all processing except for the modal window. (Unfortunately, that includes timers tied to non-UI events for background processing.) The code that executes runModal is blocked, and resumes only after the modal window is closed. The system enforces the modality of the window.
beginModalSessionForWindow works very differently. Wherever you execute it, the code starts up the modal window and then keeps executing. In the general use case (as demonstrated in Apple's examples), if you call beginModal before a loop and then condition the loop on polling the status of the session, the loop can perform whatever other processing you want; and during the loop, it's also blocking normal UI events - just like any IBAction would when executing a long-running loop.
The point is that beginModalSession actually doesn't enforce any modality of the window. Rather, your code enforces the modality of the window by executing a long-running loop. If you don't use a loop, but instead just let the "modal" session run and resume the ordinary event loop... then your other windows get all event processing, including UI events. The "modal" window becomes modeless.
I will argue that "beginModalSessionForWindow" should really be called beginModelessSessionForWindow, because that's what it does: it creates a modeless window and returns.
ShowWindow(g_hWnd, 1);
UpdateWindow(g_hWnd);
I am wondering why we need to call UpdateWindow following the ShowWindow?
It is entirely unnecessary, your window will paint just fine without it.
You'll see a minor benefit from it if your program goes off doing lots of stuff after creating the window but before entering the message loop. The user has something to look at. A splash screen is the more typical approach.
ShowWindow does not repaint the window. The call to UpdateWindow sends WM_PAINT message to the window and thus repainting it.
Normally, the system sends WM_PAINT only if the message queue is empty. Under normal circumstances this is good enough and it actually optimizes out a lot of unnecessary repaint. The messages in the queue often will change application state which can often result in invalidating part of the window, and hence result in yet another painting (so the user sees the new application state). So the repaint just happens after all such messages are handled and the system thinks the new window content will be valid for some time (until yet another message(s) come into the queue).
However if you need to force the WM_PAINT immediately and bypass the logic above, you may force sending WM_PAINT (if there is an invalid region) by calling UpdateWindow().
ShowWindow causes a WM_PAINT message, whereas anything which makes a previously hidden part of a window visible. UpdateWindow does any outstanding paint message(s) to be delivered immediately, waiting until the paint processing is complete until returning. Without the call to UpdateWindow the message isn't received until your program goes into the message loop. This avoids any possible delay in response to the user.
Here it was told me something I can't understand about wxPython and other GUI toolkits.
When I call GetLabel from a 'static text' control, there gets an event enqueued and GetLabel doesn't return until this event was processed by the main loop.
Why gets an event enqueued for such a simple task?
Why doesn't the method return immediately, but block til the message was processed?
I don't think GetLabel fires an event. The problem you were having in that other question is that you were using threads to try to manipulate the GUI and get information from it. Your thread is blocking the GUI's main thread. If you called GetLabel() from within your GUI code (such as within an event handler for a button), it would be immediate.
When a modal dialog box is present, messages sent to the main window using PostMessage do not go through that window's message loop. In fact, no message go through the main window's message loop while the modal dialog is present. They do make it to the main window's WndProc presumably through some message loop in the dialog handling.
Is this normal or am I doing something bizarre?
This is normal, the dialog box becomes modal by pumping its own message loop. This should not be a problem, DispatchMessage still delivers the message to the window procedure. Make sure you post with a valid window handle. Otherwise also the reason that PostThreadMessage() is a guaranteed fail whale if the thread creates any windows. Like MessageBox().
We have a MFC Visual-C++ application that is not reacting to any user input.
(Note: Currently only known on one machine. The behavior does recur occasionally, but only after the App has been running for several days!)
The application is redrawn when we switch to it via Alt-Tab (or the Task Bar), but we cannot, for example, activate it's main window by clicking on the title bar.
We have already pulled 4 dumps with WinDbg and checked the active instructions. We always were in some redraw code or somesuch inside the main thread (the GUI thread). We definitely were/are not in a modal message loop and the main thread's stack always looked "OK". (Most/all worker threads were idling, waiting for some event, no suspicious code there either.)
When investigating the problem with Spy++, we see the behavior specified also in this separate question, namely that we seem to get paint and activation messages, but no user input is routed to the application. When I have the application window on the screen, and select it to show messages of the main window,
it will only show "generic" "referesh" messages and nothing else
If I drill deeper, and select all messages for the whole process,
this is what we see:
The app is apparently only processing messages on one hidden sub-window (00CB09F0), and what we see there is a constant stream of 200 WM_PAINT messages per second.
Normally this Sub Window isn't processing any messages at all (except refresh WM_PAINT etc. when Windows sends them). It is normally used as a drawing area and the drawing happens through a WM_TIMER message on it's parent (010A09B8) window. (This WM_TIMER message isn't shown on the hanging app either though.)
The performance profile as shown in process explorer looks like this (100% kernel time, more or less):
I'd say that you have a redraw loop in that window that receives the WM_PAINT flood.
That usually happens if you call Invalidate or similar from the processing of the WM_PAINT message, directly or indirectly.
Other posibility is that, since you say that you are using a timer to redraw the window, the actual drawing is taking more time that the time it self, so the messages pile up in the queue.
Yet another posibility is that you are invalidating the window from a different thread than the one making the painting.
Anyway, you should ensure that you are calling Invalidate*() properly (you showed no code), and never from the OnPaint event. And avoid calling UpdateWindow() as this function can mess things if called without a little care.
I've seen this problem when an exception is thrown from a dialog. MFC's DoModal function disables the main program window then reenables it when the dialog returns; exceptions bypass the reenabling part and the main window remains disabled forever.