Proposed solution for mouse capture problems

Alexandre Julliard julliard at winehq.com
Fri Nov 30 14:45:16 CST 2001


Jukka Heinonen <jhei at iki.fi> writes:

> 1. 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.

> 3. 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
julliard at winehq.com




More information about the wine-devel mailing list