What thread handles modal dialog windows in .Net?

Question

I have a pretty basic understanding of the GUI thread and the message loop, but I'm curious as to how that applies to one window starting a modal window. If I had to guess, I'd say that both windows are being run under the same GUI thread and that some parameter indicates that only events with the child window (the modal one) be executed, otherwise point out the modal window to the user.

This is simply a semi-educated guess and I accept that I may be wrong from square one. I'm not even sure if "GUI thread" is the right name for that thread, but people usually can guess what I'm talking about.

So in short, how do threads and modal windows get along together?

Answer 1

A window, or rather a window's messages, are handled by the thread that created the window: called CreateWindowEx. This might be indirect, with layers of software between the application code and the CreateWindowEx API call, but the call will always be there when creating a new window.

Answer 2

Both windows remain on the same thread. That thread -- the GUI thread -- continues to process messages for both windows.

What's special about a modal dialog is:

• The dialog's owner is set to the main window. This causes the dialog to always appear on top of the main window. It's possible to do this with modeless windows.

• The owner window stops receiving user input (mouse and keyboard messages) while the dialog is open. The dialog receives user input as normal. This is achieved by disabling the owner window, in the same way that you might disable a control on a dialog box.

Answer 3

This maybe contradictory, but no, no new thread is started for the new windows. However, a new message loop is opened. This keeps messages flowing through Windows and avoids halting other applications.

Messages will arrive and may be dispatched to the owner window's message loop. On the owner window, keyboard and mouse input have been disabled, but all other messages will be send through. Note from Hans Passant: actually, all top level windows of the same thread will be disabled this way.

As an example that you already touch on in your question, WM_PAINT is send through to the parent window. But also WM_TIMER, for instance. A message like WM_NCHITTEST will not be send through, as it is an input message. Nor will WM_KEYDOWN and similar.

This way, a messagebox can be moved, and the underlying owner gets neatly repainted, or a ticking clock still continues ticking.

Information partially from Rector and Newcomer's Win32 Programming, page 752+, old, but still valuable and valid info. This info applies to DialogBox, DialogBoxParam, DialogBoxIndirect and DialogBoxIndirectParam as well as any of the ..Ex versions. Internally, these Win32 API functions are called by WinForms.