Tkinter.event.widget: handler gets name instead of widget.
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):
> def evtMouseLeave(self, event):
> def evtButtonOneClick(self, event):
> 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)
> ## 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 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.
>  http://www.python.org/dev/peps/pep-0008/
More information about the Python-list