Martin James wrote:
> There is a persistent rumour that Windows occasionally loses
> messages. I think that this fallacy arises from the behaviour of
> timers, which the Windows docs imply work by queueing messages. If
> the main thread is tied up for a time longer than a timer interval,
> it appears that a *timer message gets lost', hence the erroneous
> extrapolation that all windows messages are at risk of occasional
> 'loss'.
Windows does not lose messages in this case, because it never generates
timer or mouse-movement messages for the message queue in the first
place: when you call the Windows message pump, it won't look for timer
or mouse-movement events if it has any message in its queue. Windows
only checks the timers when you call its message pump (the GetMessage
call in WinMain in C). If there is nothing in the queue, it then
checks its timers and calls your message processing loop once (and only
once) for the first timer that it finds has tripped. If there are no
tripped timers, it then checks for mouse-movement and if it happened,
calls your message processing loop once with the current position. If
there is nothing at all to send you, it calls your loop with an
enter-idle message. It never generates timer or mouse-movement (or
obviously enter-idle) messages because of the huge risk of overflowing
the queue with messages that you could not keep up with or were
probably not interested in.
If your main thread blocks or cannot keep up with "normal" messages, it
won't get called with any of its timer and mouse-movement messages. I
first saw this documented in the Windows 3.0 SDK, and it still happens
on my current XP.
Ciaran
