[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: Proposed solution for mouse capture problems
From:       Alexandre Julliard <julliard () winehq ! com>
Date:       2001-11-30 20:45:16
[Download RAW message or body]

Jukka Heinonen <jhei@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@winehq.com

[prev in list] [next in list] [prev in thread] [next in thread]