Tkinter.event.widget: handler gets name instead of widget.

Frederic Rentsch anthra.norell at bluewin.ch
Tue Jul 10 12:03:34 CEST 2012


On Mon, 2012-07-09 at 10:49 -0700, Rick Johnson wrote:
> On Jul 9, 12:58 am, Terry Reedy <tjre... at udel.edu> wrote:
> > When posting problem code, you should post a minimal, self-contained
> > example that people can try on other systems and versions. Can you
> > create the problem with one record, which you could give, and one
> > binding? Do you need 4 fields, or would 1 'work'?
> 
> I'll firmly back that sentiment. Fredric, if you cannot get the
> following simple code events to work properly, then how do you think
> you can get events working properly on something more complex?
> 
> ## START CODE ARTISTRY ##
> import Tkinter as tk
> from Tkconstants import *
> 
> class MyFrame(tk.Frame):
>     def __init__(self, master, **kw):
>         tk.Frame.__init__(self, master, **kw)
>         self.bind('<Enter>', self.evtMouseEnter)
>         self.bind('<Leave>', self.evtMouseLeave)
>         self.bind('<Button-1>', self.evtButtonOneClick)
> 
>     def evtMouseEnter(self, event):
>         event.widget.config(bg='magenta')
> 
>     def evtMouseLeave(self, event):
>         event.widget.config(bg='SystemButtonFace')
> 
>     def evtButtonOneClick(self, event):
>         event.widget.config(bg='green')
> 
> if __name__ == '__main__':
>     root = tk.Tk()
>     for x in range(10):
>         f = MyFrame(root, height=20, bd=1, relief=SOLID)
>         f.pack(fill=X, expand=YES, padx=5, pady=5)
>     root.mainloop()
> ## END CODE ARTISTRY ##
> 

This works perfectly well!

What makes the case difficult is an exceptional misbehavior for no
apparent reason. If I manage to strip the critical section of
environmental details in the interest of concision and legibility and
still reproduce the error I shall post it. So far I have failed: the
stripped model I distilled yesterday worked fine.

> -----------------------
> More points to ponder:
> -----------------------
> 1. Just because the Tkinter designers decided to use idiotic names for
> event sequences does not mean you are required to blindly follow their
> bad example (the whole: "if johnny jumps off a cliff...", thing comes
> to mind)
> 
> 2. I would strongly recommend you invest more thought into your event
> handler identifiers. ALL event handlers should marked as *event
> handlers* using a prefix. I like to use the prefix "evt". Some people
> prefer other prefixes. In any case, just remember to be consistent.
> Also, event handler names should reflect WHAT event they are
> processing, not some esoteric functionality of the application like
> "pick_record" or "info_profile". However if you like, simply have the
> event handler CALL an outside func/meth. This type of consistency is
> what separates the men from the boys.
> 
> 3. The Python Style Guide[1] frowns on superfluous white space (be it
> horizontal OR vertical!) I would strongly recommend you read and adapt
> as much of this style as you possibly can bear. Even if we don't all
> get along, it IS *very* important that we structure our code in a
> similar style.
> 
> [1] http://www.python.org/dev/peps/pep-0008/

Excellent suggestions.


Frederic





More information about the Python-list mailing list