ID: Q96006
The information in this article applies to:
Under Win32, messages have the same priorities as with Windows 3.1.
With normal use of GetMessage() (passing zeros for all arguments except the LPMSG parameter) or PeekMessage(), any message on the application queue is processed before user input messages. And input messages are processed before WM_TIMER and WM_PAINT "messages."
For example, PostMessage() puts a message in the application queue. However, when the user moves the mouse or presses a key, these messages are placed on another queue (the system queue in Windows 3.1; a private, per- thread input queue in Win32).
GetMessage() and its siblings do not look at the user input queue until the application queue is empty. Also, the WM_TIMER and WM_PAINT messages are not handled until there are no other messages (for the thread) to process. The WM_TIMER and WM_PAINT messages can be thought of as boolean toggles, because multiple WM_PAINT or WM_TIMER messages waiting in the queue will be combined into one message. This reduces the number of times a window must repaint itself.
Under this scheme, prioritization can be considered tri-level. All posted messages are higher priority than user input messages because they reside in different queues. And all user input messages are higher priority than WM_PAINT and WM_TIMER messages.
The only difference in the Win32 model from the Windows versions 3.x model is that there is effectively a system queue per thread (for user input messages) rather than one global system queue. The prioritization scheme for messages is identical.
For information concerning SendMessage() from one thread to another, please see the following article(s) in the Microsoft Knowledge Base:
ARTICLE-ID: Q95000
TITLE : SendMessage() in a Multithreaded Environment
Keywords : kbNTOS kbGrpUser kbWinOS kbWndw kbWndwMsg
Issue type : kbinfoLast Reviewed: December 26, 1998