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:
95000Â
(http://kbalertz.com/Feedback.aspx?kbNumber=95000/EN-US/
)
SendMessage() in a Multithreaded Environment