Jukka Heinonen jhei@iki.fi writes:
- Function process_raw_mouse_message should only determine which window was under mouse and resend message to that window as a cooked message. Everything else (especially separating normal messages from nonclient messages and handling mouse captures) should be moved to process_cooked_mouse_message. Actually, I fail to see why raw messages are needed at all, since function SendInput could do this as well.
No, processing raw messages requires sending messages to the app (mainly WM_NCHITTEST) and you cannot do this from anywhere. Also if you separate the window determination from the rest you'll have to send two WM_NCHITTEST for every message which is clearly wrong.
Maybe what we should do is when the cooked message is rejected by the message filter it should be queued back as a raw message and processed again next time around.
- Supporting multi-threaded capture is actually the easiest part, although it might be quite useless (Does any application really require it?). When mouse button is pressed in capturing window, process_cooked_mouse_message sets process-wide flag that states that global capture is in effect. After that, either process_raw_mouse_message or SendInput sees that this flag is set and resends all mouse messages to capturing window until button release message is received, which clears the flag.
I'm not sure what you are trying to fix here. This should already work fine, X takes care of sending messages to the right thread when mouse is captured.
Alexandre Julliard wrote:
Maybe what we should do is when the cooked message is rejected by the message filter it should be queued back as a raw message and processed again next time around.
This does not work since mouse messages would be reordered. Even if the requeued raw message is put at the head of the queue, it would only mean that mouse message processing stops until filter is changed.
Here is (another) proposal:
- Function process_raw_mouse_message copies wParam into lParam (because this function might destroy the old value of wParam) and works just like it does now except that it does not try to determine whether messages are captured or not. - Function process_cooked_mouse_message checks if received message is captured message. If it is, function changes nonclient messages back into normal mouse messages and replaces target window with capturing window. Function also sets lParam to the correct value. - Wineserver get_message handler is passed capturing window. When it considers whether cooked messages fit filter criteria, it first checks if the message is captured. If message is captured, the handler uses modified window handle and message type values in filter test.
The only problem that I see in this proposal is that calling PeekMessage before and after SetCapture call might return different message types for the same message. However, I believe this to be the correct behaviour.
-
Alexandre Julliard -
Jukka Heinonen