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