ANN: Thinking in Tkinter
Russell E. Owen
owen at nospam.invalid
Tue Sep 10 17:11:59 EDT 2002
In article <3D7C210F.7090708 at something.invalid>,
Greg Ewing <see_reply_address at something.invalid> wrote:
> "Joseph A. Knapka" <jknapka at earthlink.net> wrote in message news:<3D798461.B3FE0E06 at earthlink.net>...
>...I hope you're aware that what you're doing in your buttons
>example is NOT equivalent to using the "command" option.
>The latter does a number of extra things: it waits until
>the mouse is released, and triggers the handler only if
>the release is within the button.
(what Joseph was doing was binding the button to the <Button-1> event,
e.g. mybutton.bind("<Button-1>", afunction))
Alas, too true. Button-1 fires when the mouse button is pressed (very
nonstandard behavior) and ButtonRelease fires when the mouse button is
released even if the mouse is no longer over the Button object. I don't
know of any event binding that does a proper job of emulating the
standard behavior of pressing a button. Button(command=...) is the way
to go for this.
If you need to know which button the user pressed (or any other
information that you know at the time you specify the button command
callback), define a new callback function that contains the information.
You certainly don't have to use lambda (and I never do).
Scott David Daniels wrote a very useful class that makes writing
callback functions that contain stored information a breeze. It is
<http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52549>). I make
heavy use of it and feel it really cleans up my code.
Actually, I use a minor variant I wrote that optimizes the common case
of no stored keyword arguments. You can get my version (as well a
Tkinter summary I wrote) at <http://www.astro.washington.edu/owen>; the
former is called GenericCallback and can be found in util.zip.
More information about the Python-list