bug in tkinter canvas event handling?

Fredrik Lundh fredrik at pythonware.com
Tue Nov 30 10:38:52 EST 1999


Ivan Van Laningham <ivanlan at callware.com> wrote:
> > > seems simple, but i don't get what i expect.  in particular,
> > > if i press a mouse button while pointing to one object, then drag
> > > to another and release, the release event callback tells me i
> > > was pointing to the first object.  i've distilled it down to a
> > > small test case, attached below.
> > >
> > > this seems like a bug to me, but experience has shown that it's
> > > probably a misconception on my part about how the event handling
> > > is supposed to work.
> > 
> > This behavior surprised me at first, too.  It's as though the first
> > canvas object is grabbing the pointer so that all events go to it.  I
> > got around the problem by looking for the x,y coords of the release
> > event and then finding the object(s) under that point on the canvas.
> 
> Actually, this isn't a bug.  All windowing systems (the ones I know
> about, anyway) behave this way by design; the down-click does indeed
> grab the mouse pointer, and does not let go until the up-click (or is
> that up-chuck?).

yep, but that's usually limited to entire windows -- that is, if you
press a mouse button over a window, all events will be sent to
that window until you release the mouse button.  Tk's canvas
widget contains special code to handle this for items inside a
single window (see PickCurrentItem in tkCanvas.c for details).

> You can see this behaviour even in windows, which
> hacks away at expected pointer motion with gleeful abandon.
> Click on a scrollbar, begin moving it, move the pointer out of
> the scrollbar, *watch the scrollbar snap to its previous position*

note that under Windows, it only snaps back if you
move it far enough.

> move the pointer back into the scrollbar, and finally *watch the
> scrollbar snap back under the pointer.*  This is repulsive and in-
> correct behaviour

or in other words, it's there by design: it allows you to
quickly get back to the original position, if you should
change your mind.  it also makes it easy to jump back
and forth between two positions in a long list

doesn't really have anything to do with the automatic
mouse grab -- the widget simply ignores motion events
if the mouse is too far away from the scrollbar (also
note that some applications, like MSIE, doesn't use this
feature.  it's most useful if the scrolled view can be very
large, and if most items in that view look about the same).

</F>





More information about the Python-list mailing list