Queued Messages
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 or
PostThreadMessage function.
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
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
GetMessageTime and
GetMessagePos 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 or
PeekMessage function.
- Software for developers
-
Delphi Components
.Net Components
Software for Android Developers
- More information resources
-
MegaDetailed.Net
Unix Manual Pages
Delphi Examples
- Databases for Amazon shops developers
-
Amazon Categories Database
Browse Nodes Database