Jukka Heinonen jhei@iki.fi writes:
The reason for this is that raw hardware messages get processed before menu event loop starts. Raw event processing turns raw events into cooked events and because menu event loop has not started yet, game window is not capturing events and thus clicks on menu bar are turned into nonclient messages. These cooked messages are put back into message queue.
Raw messages are not supposed to get processed while there is a cooked message in the queue. Is the app filtering messages in GetMessage? Could you please do a +server trace showing the problem?
Alexandre Julliard wrote:
Raw messages are not supposed to get processed while there is a cooked message in the queue. Is the app filtering messages in GetMessage? Could you please do a +server trace showing the problem?
Well, raw messages can be processed even though there is a cooked message in the queue if the application calls GetMessage and the requested message range does not include mouse messages. This seems to be the case here.
It looks like the correct fix is much more simple than I thought it would be: wineserver get_message handler just needs to check that there are no pending cooked messages before returning raw messages and some signaling magic must be added to prevent wakeups for raw messages if a cooked message has been queued.
Here is (hopefully) the relevant part of +server trace:
080703b8: get_message( flags=1, get_win=00000000, get_first=00000100, get_last=00000108 ) 080703b8: get_message() = 0 { type=6, win=00000000, msg=00000200, wparam=00000001, lparam=00000000, x=142, y=26, time=0000b7b8, info=00020022, data={} } 080703b8: send_message( id=0x80703b8, type=7, win=00020022, msg=000000a0, wparam=00000005, lparam=001a008e, x=142, y=26, time=0000b7b8, info=00020022, timeout=0, data={} ) 080703b8: send_message() = 0 080703b8: get_message( flags=1, get_win=00000000, get_first=00000100, get_last=00000108 ) 080703b8: get_message() = 0 { type=6, win=00000000, msg=00000202, wparam=00000000, lparam=00000000, x=142, y=26, time=0000b7b8, info=00020022, data={} } 080703b8: send_message( id=0x80703b8, type=7, win=00020022, msg=000000a2, wparam=00000005, lparam=001a008e, x=142, y=26, time=0000b7b8, info=00020022, timeout=0, data={} ) 080703b8: send_message() = 0
On Sat, Nov 24, 2001 at 04:47:39PM +0200, Jukka Heinonen wrote:
Alexandre Julliard wrote:
Raw messages are not supposed to get processed while there is a cooked message in the queue. Is the app filtering messages in GetMessage? Could you please do a +server trace showing the problem?
Well, raw messages can be processed even though there is a cooked message in the queue if the application calls GetMessage and the requested message range does not include mouse messages. This seems to be the case here.
I think this is the very same problem that Snood has, a freeware game. It allows shooting on the very first mouse click, but after that, no more events take place. This is due to Snood sending a special 0x5555 (?, dunno any more) message on every mouse click, which is supposed to signal some other proc a mouse click. Unfortunately the GetMessage() (or was it PeekMessage ?) which is supposed to fetch further mouse movements then always fetches the 0x5555 message and thus further mouse notification messages are inhibited. (dunno whether my description is exact, it's something like that, but I'm afraid the description is slightly wrong).
In short: you should definitely have a look at Snood, I think, as I'm pretty sure it's the very same problem.
Jukka Heinonen wrote:
It looks like the correct fix is much more simple than I thought it would be: wineserver get_message handler just needs to check that there are no pending cooked messages before returning raw messages and some signaling magic must be added to prevent wakeups for raw messages if a cooked message has been queued.
The above solution does not work. If menu is activated using keyboard shortcuts we can still have one broken cooked message queued.
As far as I can see, mouse message handling works in normal cases, but when capture is enabled, Wine has at least these problems:
- When capture is enabled, capturing window can receive nonclient messages for clicks processed before capture was enabled. - Subwindows of captured window can receive mouse messages queued before capture was enabled. - After capture is disabled, old capturing window can still receive captured messages queued before capture was disabled. - MSDN page about SetCapture describes that capturing window receives mouse messages only when mouse is over the capturing window (This likely includes child windows. MSDN explicitly says that this excludes child windows that belong to other threads.) or when mouse button is pressed over capturing window and button is help down (this means all windows owned by current process no matter which thread owns them). If I understand it correctly, Wine capturing doesn't work with multiple threads and it doesn't care whether mouse buttons are pressed or not.
-
Alexandre Julliard -
Andreas Mohr -
Jukka Heinonen