Vitaliy Margolen <[EMAIL PROTECTED]> 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). >> 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. > 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? -- Alexandre Julliard [EMAIL PROTECTED]
