在MSDN上看到的，对理解消息队列很有用。
消息有两种：队列消息和非队列消息。
队列消息的传递方式：系统维护了一个单独的系统消息队列，并为每一个GUI线程维护一个消息队列，当队列消息，比如鼠标，键盘事件引发的消息，将先被放到系统消息队列中，然后按照队列的操作规则，系统一次移除一个消息，并检查该消息，然后发送到产生该目标窗口的线程消息队列中，线程从自己的消息队列中移除消息然后让系统将其发送到窗口过程。
非队列消息：不经过系统消息队列和线程消息队列的迂回，直接发送到目标窗口过程。
在队列消息中WM_PAINT message, the WM_TIMER message, and the WM_QUIT message三种消息是被放在消息队列的队尾的，以确保其他消息的FIFO特性。线程通过GetMessage 从线程消息队列中移除消息， 通过<?XML:NAMESPACE PREFIX = MSHELP /><MSHELP:LINK tabIndex=0 keywords=”_win32_DispatchMessage_cpp”>DispatchMessage</MSHELP:LINK> 驱使系统将消息发送到相应的窗口过程。
Message RoutingThe thread removes messages from its queue and directs the system to send them to the appropriate window procedure for processing.
The system uses two methods to route messages to a window procedure: posting messages to a first-in, first-out queue called a message queue, a system-defined memory object that temporarily stores messages, and sending messages directly to a window procedure.
Messages posted to a message queue are called queued messages. They are primarily the result of user input entered through the mouse or keyboard, such as <MSHELP:LINK tabIndex=0 keywords=”_win32_WM_MOUSEMOVE_cpp”>WM_MOUSEMOVE</MSHELP:LINK>, <MSHELP:LINK tabIndex=0 keywords=”_win32_WM_LBUTTONDOWN_cpp”>WM_LBUTTONDOWN</MSHELP:LINK>, <MSHELP:LINK tabIndex=0 keywords=”_win32_WM_KEYDOWN_cpp”>WM_KEYDOWN</MSHELP:LINK>, and <MSHELP:LINK tabIndex=0 keywords=”_win32_WM_CHAR_cpp”>WM_CHAR</MSHELP:LINK> messages. Other queued messages include the timer, paint, and quit messages: <MSHELP:LINK tabIndex=0 keywords=”_win32_WM_TIMER_cpp”>WM_TIMER</MSHELP:LINK>, WM_PAINT, and <MSHELP:LINK tabIndex=0 keywords=”_win32_WM_QUIT_cpp”>WM_QUIT</MSHELP:LINK>. Most other messages, which are sent directly to a window procedure, are called nonqueued messages.
Queued Messages
The system can display any number of windows at a time. To route mouse and keyboard input to the appropriate window, the system uses message queues.
The system maintains a single system message queue and one thread-specific message queue for each graphical user interface (GUI) thread. To avoid the overhead of creating a message queue for non–GUI threads, all threads are created initially without a message queue. The system creates a thread-specific message queue only when the thread makes its first call to one of the User or Windows Graphics Device Interface (GDI) functions.
Whenever the user moves the mouse, clicks the mouse buttons, or types on the keyboard, the device driver for the mouse or keyboard converts the input into messages and places them in the system message queue. The system removes the messages, one at a time, from the system message queue, examines them to determine the destination window, and then posts them to the message queue of the thread that created the destination window. A thread’s message queue receives all mouse and keyboard messages for the windows created by the thread. The thread removes messages from its queue and directs the system to send them to the appropriate window procedure for processing.
With the exception of the WM_PAINT message, the WM_TIMER message, and the WM_QUIT message, the system always posts messages at the end of a message queue. This ensures that a window receives its input messages in the proper first in, first out (FIFO) sequence. The WM_PAINT message, the WM_TIMER message, and the WM_QUIT message, however, are kept in the queue and are forwarded to the window procedure only when the queue contains no other messages. In addition, multiple WM_PAINT messages for the same window are combined into a single WM_PAINT message, consolidating all invalid parts of the client area into a single area. Combining WM_PAINT messages reduces the number of times a window must redraw the contents of its client area.
The system posts a message to a thread’s message queue by filling an <MSHELP:LINK tabIndex=0 keywords=”_win32_MSG_str_cpp”>MSG</MSHELP:LINK> structure and then copying it to the message queue. Information in MSG includes: the handle of the window for which the message is intended, the message identifier, the two message parameters, the time the message was posted, and the mouse cursor position. A thread can post a message to its own message queue or to the queue of another thread by using the <MSHELP:LINK tabIndex=0 keywords=”_win32_PostMessage_cpp”>PostMessage</MSHELP:LINK> or <MSHELP:LINK tabIndex=0 keywords=”_win32_PostThreadMessage_cpp”>PostThreadMessage</MSHELP:LINK> function.
An application can remove a message from its queue by using the <MSHELP:LINK tabIndex=0 keywords=”_win32_GetMessage_cpp”>GetMessage</MSHELP:LINK> function. To examine a message without removing it from its queue, an application can use the <MSHELP:LINK tabIndex=0 keywords=”_win32_PeekMessage_cpp”>PeekMessage</MSHELP:LINK> function. This function fills MSG with information about the message.
After removing a message from its queue, an application can use the <MSHELP:LINK tabIndex=0 keywords=”_win32_DispatchMessage_cpp”>DispatchMessage</MSHELP:LINK> function to direct the system to send the message to a window procedure for processing. DispatchMessage takes a pointer to MSG that was filled by a previous call to the GetMessage or PeekMessage function. DispatchMessage passes the window handle, the message identifier, and the two message parameters to the window procedure, but it does not pass the time the message was posted or mouse cursor position. An application can retrieve this information by calling the <MSHELP:LINK tabIndex=0 keywords=”_win32_GetMessageTime_cpp”>GetMessageTime</MSHELP:LINK> and <MSHELP:LINK tabIndex=0 keywords=”_win32_GetMessagePos_cpp”>GetMessagePos</MSHELP:LINK> functions while processing a message.
A thread can use the <MSHELP:LINK tabIndex=0 keywords=”_win32_WaitMessage_cpp”>WaitMessage</MSHELP:LINK> function to yield control to other threads when it has no messages in its message queue. The function suspends the thread and does not return until a new message is placed in the thread’s message queue.
You can call the <MSHELP:LINK tabIndex=0 keywords=”_win32_SetMessageExtraInfo_cpp”>SetMessageExtraInfo</MSHELP:LINK> function to associate a value with the current thread’s message queue. Then call the <MSHELP:LINK tabIndex=0 keywords=”_win32_GetMessageExtraInfo_cpp”>GetMessageExtraInfo</MSHELP:LINK> function to get the value associated with the last message retrieved by the GetMessage or PeekMessage function.
Nonqueued Messages
Nonqueued messages are sent immediately to the destination window procedure, bypassing the system message queue and thread message queue. The system typically sends nonqueued messages to notify a window of events that affect it. For example, when the user activates a new application window, the system sends the window a series of messages, including <MSHELP:LINK tabIndex=0 keywords=”_win32_WM_ACTIVATE_cpp”>WM_ACTIVATE</MSHELP:LINK>, <MSHELP:LINK tabIndex=0 keywords=”_win32_WM_SETFOCUS_cpp”>WM_SETFOCUS</MSHELP:LINK>, and <MSHELP:LINK tabIndex=0 keywords=”_win32_WM_SETCURSOR_cpp”>WM_SETCURSOR</MSHELP:LINK>. These messages notify the window that it has been activated, that keyboard input is being directed to the window, and that the mouse cursor has been moved within the borders of the window. Nonqueued messages can also result when an application calls certain system functions. For example, the system sends the <MSHELP:LINK tabIndex=0 keywords=”_win32_WM_WINDOWPOSCHANGED_cpp”>WM_WINDOWPOSCHANGED</MSHELP:LINK> message after an application uses the <MSHELP:LINK tabIndex=0 keywords=”_win32_SetWindowPos_cpp”>SetWindowPos</MSHELP:LINK> function to move a window.
Some functions that send nonqueued messages are <MSHELP:LINK tabIndex=0 keywords=”_win32_BroadcastSystemMessage_cpp”>BroadcastSystemMessage</MSHELP:LINK>, <MSHELP:LINK tabIndex=0 keywords=”_win32_BroadcastSystemMessageEx_cpp”>BroadcastSystemMessageEx</MSHELP:LINK>, <MSHELP:LINK tabIndex=0 keywords=”_win32_SendMessage_cpp”>SendMessage</MSHELP:LINK>, <MSHELP:LINK tabIndex=0 keywords=”_win32_SendMessageTimeout_cpp”>SendMessageTimeout</MSHELP:LINK>, and <MSHELP:LINK tabIndex=0 keywords=”_win32_SendNotifyMessage_cpp”>SendNotifyMessage</MSHELP:LINK>.