Windows can display any number of windows at a time. To route mouse and
keyboard input to the appropriate window, Windows uses message queues.
Windows maintains a single system message queue and any number of thread
message queues, one for each 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's message queue only when the thread makes
its first call to one of the Win32 API User or 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. Windows 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 Windows to send them to the appropriate
window procedure for processing.
With the exception of the WM_PAINT
message, Windows 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, however, is kept in the queue and is
forwarded to the window procedure only when the queue contains no other
messages. 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 MSG
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 PostMessage
An application can remove a message from its queue by using the GetMessage
function. To examine a message without removing it from its queue, an
application can use the PeekMessage
function. This function fills MSG
with information about the message.
After removing a message from its queue, an application can use the DispatchMessage
function to direct Windows to send the message to a window procedure for
takes a pointer to MSG
that was filled by a previous call to the GetMessage
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 GetMessageTime
functions while processing a message.
A thread can use the WaitMessage
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 SetMessageExtraInfo
function to associate a 32-bit value with the current thread's message queue.
Then call the GetMessageExtraInfo
function to get the value associated with the last message retrieved by the GetMessage
- Software for developers
Software for Android Developers
- More information resources
Unix Manual Pages
- Databases for Amazon shops developers
Amazon Categories Database
Browse Nodes Database