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.