Re: Proposed solution for mouse capture problems

[Alexandre Julliard]

Jukka Heinonen  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.