Re: The basics of Windows' messages
- From: "William DePalo [MVP VC++]" <willd.no.spam@xxxxxxxx>
- Date: Tue, 6 Jun 2006 01:50:57 -0400
"Ney André de Mello Zunino" <zunino@xxxxxxxxxxx> wrote in message
news:u8M4dKSiGHA.1600@xxxxxxxxxxxxxxxxxxxxxxx
Up to this point, the thread owning the queue would do nothing else in its
available time slice other than check for messages on its queue (with,
e.g., /GetMessage()/).
That's close to the truth but not required. Windows applications must pump
messages or they appear "hung" or "stuck" to the user. But some applications
when there are no messages pending may do some other processing that does
not take much time between messages.
As soon as it realizes there is a message, the thread removes it from the
queue and dispatches it (calls /DispatchMessage()/). The code in
/DispatchMessage()/ will find out which window procedure should be called
and then invoke it. All this happens in the context of the thread which
initially removed the message from the queue. As the message processing is
over, the thread will resume its queue watching activity and the whole
cycle starts over.
Yes. That's pretty much it as far as messages that are posted go. Messages
may be sent as well. In the case of messages sent _across_ processes, the
sender is blocked until the receiver processes the message. When the
receiver next calls GetMessage() or PeekMessage(), Windows will note that
there is a sent message pending, and it will route it to the traget window
before fetching the next message from the queue.
Regards,
Will
.
- Follow-Ups:
- Re: The basics of Windows' messages
- From: Ney André de Mello Zunino
- Re: The basics of Windows' messages
- References:
- The basics of Windows' messages
- From: Ney André de Mello Zunino
- The basics of Windows' messages
- Prev by Date: Re: Windriver need to resume OS work..
- Next by Date: Re: The basics of Windows' messages
- Previous by thread: The basics of Windows' messages
- Next by thread: Re: The basics of Windows' messages
- Index(es):
Relevant Pages
|