[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    serious msg problem
From:       Andreas Mohr <a.mohr () mailto ! de>
Date:       2000-09-30 22:43:53
[Download RAW message or body]

Hi all,

a game (-> www.snood.com) didn't react on mouse clicks any more after the
first one.
It has a PeekMessage() PM_NOREMOVE loop.
In that loop, it checks for several messages (WM_LBUTTONDOWN, PAINT, ...),
but *not* for WM_LBUTTONUP.
In case a message arrives that is not handled by that code, it does a
PostMessage of a very cool and special 5555 message.
Directly after that PostMessage code, it does the normal GetMessage()
of that PeekMessage loop.
The problem now is that the 5555 message gets retrieved by GetMessage()
*before* the WM_LBUTTONUP message which the initial PeekMessage of that
PeekMessage, PostMessage, GetMessage loop returned, even though it was
the LBUTTONUP that this GetMessage was *really* intended for !!
This happens because in MSG_PeekMessage (which GetMessage calls),
we handle hardware events *after* PostMessage'd events.
(most probably because we want to get rid of queued up messages first
before caring about hardware messages).
Snood did a PostMessage as a *direct* result of that WM_LBUTTONUP
PeekMessage, even before it removed the mouse msg from the queue again.

So that loop always got the LBUTTONUP msg in PeekMessage,
did a 5555 PostMessage and instantly a GetMessage of that 5555 message.
So it basically got stuck as the LBUTTONUP never got removed and always
reappeared.

So I moved the hardware event handling part of MSG_PeekMessage before the
PostMessage part in order to get rid of LBUTTONUP, and then it worked.
I'm not sure at all whether this is an optimal solution, though.
I'm pretty sure we want hardware events to get handled after our normal
msgs, but we have to make sure somehow that the messages a PeekMessageA()
returned are found by the subsequent GetMessageA() instead of other
messages inserted into the queue in the meantime.
Could it be a general requirement to mark PeekMessage'd msgs as being
next on the GetMessage() fetching perhaps ?
Could there be similar situations maybe not only with hardware events
involved perhaps ? (I didn't think about that yet, sorry)

What to do ?

All in all this sounds like a BIG problem for many programs again...

Of course all this happened because of the somewhat "non-standard"
message loop processing of that game...

Andreas Mohr

[prev in list] [next in list] [prev in thread] [next in thread]