We all know that the
generated-on-demand messages like
WM_MOUSE­MOVE,
WM_PAINT,
and WM_TIMER messages
are not posted into the queue when the corresponding event occurs,
but rather are generated by
Get­Message or Peek­Message
...
We all know that the
generated-on-demand messages like
WM_MOUSE­MOVE,
WM_PAINT,
and WM_TIMER messages
are not posted into the queue when the corresponding event occurs,
but rather are generated by
Get­Message or Peek­Message
when they detect that they are about to conclude that there is
no message to return
and
the generated-on-demand message can be returned.
When this happens,
the window manager creates the message on the fly,
posts it into the queue,
and hey, how about that,
the
Get­Message or Peek­Message
function now has a message to return!
Note that this auto-generate can happen even though the queue
is not empty,
because the message filters control what messages in the queue
can be returned.
For example,
suppose the message queue contains the following messages:
{ hwnd1, WM_CLIP­BOARD­UPDATE }
{ hwnd2, WM_LBUTTON­DOWN }
(Note that the above diagram is not strictly correct,
because the WM_LBUTTON­DOWN message
goes into the input queue, not the message queue,
but the distinction is not important here.)
Suppose you now call
Get­Message(&msg, hwnd1,
WM_MOUSE­FIRST, WM_MOUSE­LAST).
None of the messages in the queue satisfy the message filter:
The first message meets the window filter, but the message
is not in range.
The second message meets the message range filter, but
does not meet the window filter.
The Get­Message function is about to give up
and say "I guess I need to wait for a message,"
but before it finally concedes defeat,
it says,
"Hang on there.
I see a note that tells me that I should auto-generate a
WM_MOUSE­MOVE message
for window hwnd1.
And that message satisfies the message filter.
I'll generate it now!"
The Get­Message function posts the
{ hwnd1, WM_MOUSE­MOVE }
message into the queue
(assigning it the current time as the timestamp),
and then it says,
"Hey, lookie here! A message that satisfies the filter!"
It then removes the message from the queue and returns it.
(Note that this algorithm is conceptual.
It doesn't actually work this way internally.
In particular, the window manager does not literally talk to itself,
at least not out loud.)
Okay, so in the Get­Message case,
even if the message conceptually goes into the queue,
it comes right back out immediately,
so you never actually observe it there.
Now repeat the exercise with the
Peek­Message function.
As before, the
WM_MOUSE­MOVE message
is posted into the queue with the current time as the timestamp.
If the PM_REMOVE flag is passed,
then the message is removed from the queue and returned,
just like Get­Message.
If the PM_NO­REMOVE flag is passed,
then things get interesting:
The message is returned but not removed from the queue.
You now have a WM_MOUSE­MOVE message
physically residing in the queue!
This is the answer to the puzzle:
If auto-generated messages are generated on demand,
how is it possible for them to end up sitting in your message queue?
I recall a bug investigation from nearly two decades ago which
basically boiled down to this issue:
Somebody PM_NO­REMOVE'd an auto-generated
message and not only left it in the queue,
but kept generating new ones without processing the old ones.
Eventually, the message queue filled up.
(Note that this is also the answer to the puzzle:
If WM_MOUSE­MOVE is generated on demand,
how can it be possible to retrieve a
WM_MOUSE­MOVE message
with a timestamp different from the current time?)
