Proposed solution for mouse capture problems

[Jukka Heinonen]

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.

-- 
Jukka Heinonen <http://www.iki.fi/jhei/>