mvh@cfa250.harvard.edu (Mike Van Hilst) (07/02/89)
Simply put: when a window has PointerMotionMask in its event mask, XCheckWindowEvent(.., ButtonMotionMask, ) returns all MotionNotify events, including those after the Button was released. I am using the MIT XV1R3. The problem is easy to demonstrate in dbx. Stop after the XNextEvent got the ButtonPress and before the afore mentioned call in a while loop. Release the button, move the pointer off the window and do "cont". I have an application which involves a lot of pointer tracking (drawing graphics, changing colors, magnifying the area of interest, displaying the pointer coordinates). In some situations the pointer is tracked, button or no. In other situations, the pointer is only tracked with a button down. Is this a bug which will be fixed in the next release, or does it reflect a design philosophy? Meanwhile, yes, I am going to use XCheckIfEvent(). Mike VanHilst
rws@EXPO.LCS.MIT.EDU (07/05/89)
Simply put: when a window has PointerMotionMask in its event mask,
XCheckWindowEvent(.., ButtonMotionMask, ) returns all MotionNotify
events, including those after the Button was released.
Is this a bug which will be fixed in the next release, or does it
reflect a design philosophy?
How about "a realistic limitation"? Note that a pointer can have more than
5 buttons, so a button can be down without that fact being noted in the event
structure (the state mask doesn't have a "some button is down" bit). As such,
XCheckWindowEvent plays it safe and assumes all MotionNotify events might have
been generated while some button was down. (It's not obvious whether this is a
better or worse assumption than doing it the other way, but that's the way it
is.) If you know which button (between 1 and 5) is down, then you can simply
call XCheckWindowEvent with the specific Button<N>MotionMask instead and get
the behaviour you desire.