출처: http://discuss.joelonsoftware.com/default.asp?design.4.18520.7
Windows messaging system
I have a few questions nagging my brain about windows, and any answers would be appreciated:
1) Is it correct to state that each window has its own message loop, but that the process as a whole operates only as a single thread? How come no windows creation functions allow you to automatically spawn the window as a separate thread, which I am could be beneficial by allowing one window to do work while another is blocked.
2) When a window responds to a message, a function gets called. While this function is underway, new messages must have to queue up, and the window would not be able to respond to paint or timer messages. However, if the function calls a DoModal window, the parent seems to continue to respond to paint and timer messages and yet goes back to the same function after the DoModal is complete. How does this work? While DoModal is active can the parent still process messages? Doesnt this mean that the parent window can now effectively process two messages at a time, in a multi-threading type of way?
3) I am only aware of windows systems? Has the messaging subsystem idea been around since Win95? Is this how other OSes operate, just with their own set of messages?
1) Is it correct to state that each window has its own message loop, but that the process as a whole operates only as a single thread? How come no windows creation functions allow you to automatically spawn the window as a separate thread, which I am could be beneficial by allowing one window to do work while another is blocked.
2) When a window responds to a message, a function gets called. While this function is underway, new messages must have to queue up, and the window would not be able to respond to paint or timer messages. However, if the function calls a DoModal window, the parent seems to continue to respond to paint and timer messages and yet goes back to the same function after the DoModal is complete. How does this work? While DoModal is active can the parent still process messages? Doesnt this mean that the parent window can now effectively process two messages at a time, in a multi-threading type of way?
3) I am only aware of windows systems? Has the messaging subsystem idea been around since Win95? Is this how other OSes operate, just with their own set of messages?
ThreadMan
Saturday, October 23, 2004
Saturday, October 23, 2004
Deleting … Approving …
There is only one active message loop. When you create a modal window, it has its own message loop, and the previous message loop is temporarily disabled.
Whatever window is currently active receives *all* messages for all windows.
The magic function is DispatchMessage, called from inside the message loop. It checks which window the message is for, and sends it to the appropriate window procedure.
This way you get the appearance of 'multithreading' i.e. all windows are processing as normal.
Questions like this usually solve themselves after doing some hands-on programming.
Whatever window is currently active receives *all* messages for all windows.
The magic function is DispatchMessage, called from inside the message loop. It checks which window the message is for, and sends it to the appropriate window procedure.
This way you get the appearance of 'multithreading' i.e. all windows are processing as normal.
Questions like this usually solve themselves after doing some hands-on programming.
Alex 
Sunday, October 24, 2004
Sunday, October 24, 2004
Deleting … Approving …
> and yet goes back to the same function after the DoModal is complete.
The window procedure is "reentrant", which means it can be interrupted while in the middle of something, and then called from somewhere else, and it will perform correctly.
The window procedure is "reentrant", which means it can be interrupted while in the middle of something, and then called from somewhere else, and it will perform correctly.
Alex
Sunday, October 24, 2004
Sunday, October 24, 2004
Deleting … Approving …
"There is only one active message loop. When you create a modal window, it has its own message loop, and the previous message loop is temporarily disabled."
I think this is incorrect as the parent window of a modal can still process WM_PAINT messages. Otherwise moving the child window across the parent would not cause the parent to redraw itself. My guess is that WM_PAINT, WM_TIMER etc. are still active, why WM_CHAR, WM_MOUSEDOWN etc. are dropped.
I think this is incorrect as the parent window of a modal can still process WM_PAINT messages. Otherwise moving the child window across the parent would not cause the parent to redraw itself. My guess is that WM_PAINT, WM_TIMER etc. are still active, why WM_CHAR, WM_MOUSEDOWN etc. are dropped.
ThreadMan
Sunday, October 24, 2004
Sunday, October 24, 2004
Deleting … Approving …
All windows participate in the message queue, regardless of whether they're modal or non-modal. There are wrinkles about whether an application is system modal or modal to an application.
All windowing systems use a similar mechanism but tend to be quite different in specific implementation. Windows 1.0 had exactly the same message queue.
All windowing systems use a similar mechanism but tend to be quite different in specific implementation. Windows 1.0 had exactly the same message queue.
Deleting … Approving …
> can still process WM_PAINT messages.
well you have to read the whole answer. Did you notice the part about DispatchMessage? Or do you skip over what you don't understand, and prefer to keep with whatever ideas you have of your own?
well you have to read the whole answer. Did you notice the part about DispatchMessage? Or do you skip over what you don't understand, and prefer to keep with whatever ideas you have of your own?
Alex
Sunday, October 24, 2004
Sunday, October 24, 2004
Deleting … Approving …
Wow, the answers to this question have been all over the place, and mostly wrong (or glossing over important details).
Each thread in a Win32 app can have it's own message loop. All windows created by that thread share that thread's message loop. The prototypical form of this loop is:
while( GetMessage( &msg, ... ) ) {
TranslateMessage( &msg, ... );
DispatchMessage( &msg, ... );
}
(I'm too lazy to look up the exact parameters, so trust me on the ..., ok?)
Let's look at what each of these lines does. First, GetMessage. This is basically "wait until the OS says there's a message for this thread." Once a message appears on the queue, GetMessage returns, and you need to process it.
The first stage of processing is the TranslateMessage call, which takes raw hardware messages (WM_KEYDOWN, for example) and turns them into somewhat friendlier message (WM_CHAR).
The second stage is DispatchMessage. This figures out which window on the thread that the message was actually aimed at and calls that window's window proc. As a result, each window recieves it's own messages.
Inside the DoModal call, there's a chunk of code that spins the message loop as well. Since you're still on the main thread, all the windows on that thread still process their messages (paint, move, etc.) even when a modal dialog is displayed.
So, why don't parent windows get keyboard or mouse messages? Part of the windowing system is that only the "active" window gets these messages. Since the parent window is disabled, it cannot be activated, and therefore the message queueing automatically routes these to the currently active window, which is the modal dialog.
Each thread in a Win32 app can have it's own message loop. All windows created by that thread share that thread's message loop. The prototypical form of this loop is:
while( GetMessage( &msg, ... ) ) {
TranslateMessage( &msg, ... );
DispatchMessage( &msg, ... );
}
(I'm too lazy to look up the exact parameters, so trust me on the ..., ok?)
Let's look at what each of these lines does. First, GetMessage. This is basically "wait until the OS says there's a message for this thread." Once a message appears on the queue, GetMessage returns, and you need to process it.
The first stage of processing is the TranslateMessage call, which takes raw hardware messages (WM_KEYDOWN, for example) and turns them into somewhat friendlier message (WM_CHAR).
The second stage is DispatchMessage. This figures out which window on the thread that the message was actually aimed at and calls that window's window proc. As a result, each window recieves it's own messages.
Inside the DoModal call, there's a chunk of code that spins the message loop as well. Since you're still on the main thread, all the windows on that thread still process their messages (paint, move, etc.) even when a modal dialog is displayed.
So, why don't parent windows get keyboard or mouse messages? Part of the windowing system is that only the "active" window gets these messages. Since the parent window is disabled, it cannot be activated, and therefore the message queueing automatically routes these to the currently active window, which is the modal dialog.
Chris Tavares
Monday, October 25, 2004
Monday, October 25, 2004
Deleting … Approving …
Oh, and yes, most other windowing systems act the same way in general, although the specifics of course vary widely from system to system.
X-Windows, for example, actually uses a network socket to transmit its messages, which is how you get the 'run on one machine, show window on another' behavior which is the best thing about X.
X-Windows, for example, actually uses a network socket to transmit its messages, which is how you get the 'run on one machine, show window on another' behavior which is the best thing about X.
Chris Tavares
Monday, October 25, 2004
Monday, October 25, 2004
Deleting … Approving …
This topic is archived. No further replies will be accepted.
