ANN: Thinking in Tkinter

[Russell E. Owen]

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>...
>>...(text elided)...
>...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 
available at 
<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.

-- Russell