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.