Tuesday, August 8, 2006, 1:48:51 AM, Alexandre Julliard wrote:
Vitaliy Margolen wine-devel@kievinfo.com writes:
GetCursorPos really needs to query X, because there's no guarantee that the app is processing X events, and even if we hack around that
What do you mean here? X will always send notifies to a window (or am I wrong here?) And in notify handler we pretty much setting the cursor_pos.
But that requires that we pull events from the queue, and GetCursorPos() doesn't do that (and can't since we don't want to generate repaints etc. in there).
Ah you mean Wine's message queue? I thought we get X's notifies via direct callback. Is this not the case then?
we won't receive events from other processes anyway. Now it probably
That's the thing. We either need to send mouse notifications to all processes (via wineserver?) or don't really need them, as long as we can synch cursor_pos between processes.
That doesn't help, the other process is not necessarily a Wine process.
Well app shouldn't really need to know if cursor is outside it's window. And since we won't be generating WM_* messages in such case why even bother? Or... we can do something what native does - spurious WM_MOUSEMOVE messages (well known ... feature it seems) that probably come from querying mouse on some interval.
Not so. According to few tests native always sets cursor_pos (what ever it's called internally - I'll call it that ;-) in SetCursorPos(). But on mouse moves it's not being set immediately but after calling hooks and generating WM_ messages. And that's the part lots of games relay on, including native dinput.
Any chance you could write a small test case that replicates the behavior you have observed?
Attached. Small test and patch to fix it (against current git).
Vitaliy