Re: How does PeekMessage really work?
My bad, I keep forgetting that.
BTW, here is a link that explains all of this in more detail. Also some
difference between PeekMessage and GetMessage:
http://msdn.microsoft.com/en-us/library/ms644928(VS.85).aspx
AliR.
"Malachy Moses" <malachy.moses@gmail.com> wrote in message
news:7d1a0aff-3fa0-41d3-851f-1aeeac5f1b73@q26g2000prq.googlegroups.com...
See in-line, below ...
On Sep 8, 8:38 am, "AliR \(VC++ MVP\)" <A...@online.nospam> wrote:
See Below....."Denis Adamchuk" <DenisAdamc...@discussions.microsoft.com>
wrote in message
news:179A5207-EB0E-4381-9127-5BE1D90A0DBD@microsoft.com...
Hi everyone,
I'm writing an application where Windows messages are used in a special
manner and want to clarify how flexible is access to the thread message
queue.
I've read the MSDN article about PeekMessage and many web sites where
different opinions are expressed. My questions are the following...
1) What really does PeekMessage()?
Does it process messages sent from other threads by means of
SendMessage-family routines or just picks a message from the queue (or
from
where?) and give me a chance to analyze it and process it by myself?
PeekMessage retrieves a message from the calling thread's message queue,
it
doesn't care if was sent view SendMessage or PostMessage. PeekMessage does
not process the message, that's job of the winproc to process messages
(this
happens during the call to DispatchMessage), PeekMessage simply returns
the
message that is at the top of the queue.
This incorrectly infers that a message sent by SendMessage somehow
ends up in the message queue. It doesn't. A message sent by
SendMessage is a non-queued message that does not end up in the
message queue, and is not retrievable by a call to PeekMessage (or a
call to GetMessage).
A message sent by SendMessage calls the target window's WinProc
directly, without going through the message queue. If the thread
calling SendMessage is the same thread as the target window, then a
call to SendMessage is very much like a simple function call, that
calls the WinProc for the target window. If the are in different
threads, then the process is more complicated, but the end result is
the same in that sent messages are non-queued messages that bypass the
message queue and do not somehow end up in the message queue.
On the other hand, messages posted by PostMessage end up in the
message queue, together with other messages that get routed through
the message queue (like timer messages, paint messages, system
messages, keyboard messages, etc.) It's only if the message resides
in the message queue that the message can be retrived by calls to
PeekMessage or GetMessages.
As one explanation, see Paul DiLascia's C++ Q&A column from December
2000, "Sending Messages in Windows" at
http://msdn.microsoft.com/en-us/magazine/cc301431.aspx
2) Does PeekMessage process ALL sent messages that are available now or
only
one of them?
PeekMessage returns one message at a time. Again it does not process
message
simply returns a message. Not that wRemoveMsg parameter let you tell it to
either remove the message if you are calling PeekMessage to process the
message after you receive it, or to leave it in the queue, if you are
calling PeekMessage just out of curiousity and won't really be processing
the message. See GetMessage if you always want to remove the message from
the queue.
PeekMessage will not process *any* sent messages, for the reason that
messages sent by using SendMessage will not go into the message queue.
<snip, I am not responding to the remainder of this post.>