On Jul 9, 12:58 am, Terry Reedy <tjre...@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 ##
-----------------------
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/
--
http://mail.python.org/mailman/listinfo/python-list
