Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: Tkinter.event.widget: handler gets name instead of widget.

Reply
Thread Tools

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

 
 
Terry Reedy
Guest
Posts: n/a
 
      07-09-2012
On 7/8/2012 5:19 PM, Frederic Rentsch wrote:
> Hi widget wizards,
>
> The manual describes the "event" attribute "widget" as "The widget
> which generated this event. This is a valid Tkinter widget instance, not
> a name. This attribute is set for all events."


Same in 3.3, with nice example of using it.

def turnRed(self, event):
event.widget["activeforeground"] = "red"

self.button.bind("<Enter>", self.turnRed)

> Ans so it is--has been until on the latest occasion "event.widget" was
> not the widget, but its name, crashing the handler.


Has event.widget been the widget only in other programs or previously
with the same program?



> # Here I build a list of selectable records having each four fields.
> # The fields are labels. The selectable line is a frame containing the
> # labels side by side. The line frames go into self, which is a Frame.
>
> for n in range (len (records)):


for n, record in enumerate(records):

> record = records [n]
> line_frame = Frame (self, name = '-%d-' % n, relief = RAISED, **BUTTON_FRAME_)
> line_frame.bind ('<Enter>', self.enter)
> line_frame.bind ('<Leave>', self.leave)
> line_frame.bind ('<ButtonRelease-1>', self.pick_record)
> line_frame.bind ('<ButtonRelease-3>', self.info_profile)
> line_frame.grid (row = n+2, column = 1)
> for i in self.range_n_fields: # (0, 1, 2, 3)
> field = Label (line_frame, text = record [self.INDICES [i]], anchor = W, width = self.COLUMN_WIDTHS [i], **DB_LIST_LABEL_)
> field.grid (row = 0, column = i, sticky = NW)


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'?


> # Here is the <Enter> handler:
>
> def enter (self, event):
> w = event.widget
> print 'hit list.enter (). Event, widget', event, w, w.__class__ # Tracing line
> w.config (bg = SELECTED_BG_COLOR)
>
> # And here is what comes out. The first line is my tracing line. The name is correct in that it
> # names the entered line_frame, but is wrong because it should be the line_frame, not its name.
> # The rest is the red exception message:
>
> hit list.enter (). Event, widget <Tkinter.Event instance at 0x9115dcc> .main-frame.data-frame.title-hit-list.-10- <type 'str'>
> Exception in Tkinter callback
> Traceback (most recent call last):
> File "/usr/lib/python2.6/lib-tk/Tkinter.py", line 1413, in __call__
> return self.func(*args)
> File "/home/fr/python/finance/piam/hit_list.py", line 83, in enter
> w.config (bg = SELECTABLE_BG_COLOR)
> AttributeError: 'str' object has no attribute 'config'
>
> # The same thing happens with <Leave>. The other handlers I haven't done yet. The same bindings work well in
> # a Menu class with the difference that the bindings are on the Labels, not a containing Frame.
>
> # Dell E6500, Ubuntu 10.04, Python 2.6


You might try a current Python release, and the latest tcl/tk 8.5.11
released last March (comes with 3.3.0 Windows release, don't know how on
Ubuntu). There might be (have been?) a bug with events on Frames, or on
Frames within Frames treated as widgets.

--
Terry Jan Reedy

 
Reply With Quote
 
 
 
 
Rick Johnson
Guest
Posts: n/a
 
      07-09-2012
On Jul 9, 12:58*am, Terry Reedy <(E-Mail Removed)> 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/
 
Reply With Quote
 
 
 
 
Terry Reedy
Guest
Posts: n/a
 
      07-09-2012
On 7/9/2012 1:49 PM, Rick Johnson wrote:
> On Jul 9, 12:58 am, Terry Reedy <(E-Mail Removed)> 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 ##


I copied and pasted this self-contained code into a 3.3 Idle edit window
and lightly edited for 3.x. Change 'Tkinter' to 'tkinter', remove
tkconstants import and prefix constants with 'tk.'. (The alternative:
change 'tkconstants' to 'tkinter.constants', but I prefer prefixes). It
runs as expected.

import tkinter as tk

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=tk.SOLID)
f.pack(fill=tk.X, expand=tk.YES, padx=5, pady=5)
root.mainloop()

Add details and data (maybe less than 10 records) until you get what you
want or recreate problem.

--
Terry Jan Reedy



 
Reply With Quote
 
Frederic Rentsch
Guest
Posts: n/a
 
      07-09-2012
On Mon, 2012-07-09 at 10:49 -0700, Rick Johnson wrote:
> On Jul 9, 12:58 am, Terry Reedy <(E-Mail Removed)> 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/


Rick,
Thanks for your remarks. I spent most of the day working with Terry's
input. And now I am falling asleep. So I shall study your inspirations
tomorrow.

Frederic


 
Reply With Quote
 
Frederic Rentsch
Guest
Posts: n/a
 
      07-10-2012
On Mon, 2012-07-09 at 10:49 -0700, Rick Johnson wrote:
> On Jul 9, 12:58 am, Terry Reedy <(E-Mail Removed)> 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


 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      07-10-2012
I've tried to condense your code using the very limited info you have
provided. I have removed unnecessarily configuring of widgets and
exaggerated the widget borders to make debugging easier. Read below
for Q&A.

## START CONDENSED CODE ##
records = range(4)

CNF_SUBFRAME = {
'bd':5, # rowFrame boder width.
'relief':RIDGE,
}

CNF_LABEL = {
'anchor':W,
'width':10,
'bg':'gray',
}

class FooFrame(tk.Frame):
def __init__(self, master, **kw):
tk.Frame.__init__(self, master, **kw)
self.build_records()

def build_records(self):
# Should this method be called by __init__???
# Not sure if "records" is passed-in or global???
for n in range(len(records)):
record = records[n]
rowFrame = tk.Frame(self, name='-%d-'%n, **CNF_SUBFRAME)
rowFrame.bind ('<Enter>', self.evtEnter)
rowFrame.bind ('<Leave>', self.evtLeave)
rowFrame.bind ('<ButtonRelease-1>',
self.evtButtonOneRelease)
rowFrame.bind ('<ButtonRelease-3>',
self.evtButtonThreeRelease)
rowFrame.grid (row=n+2, column=1, padx=5, pady=5)
for i in range(4):
lbtext = 'Label_'+str(i)
label = tk.Label(rowFrame, text=lbtext, **CNF_LABEL)
label.grid (row=0, column=i, sticky=NW)

def evtEnter(self, event):
w = event.widget
print 'evtEnter', w.winfo_class()
w.config(bg='magenta')

def evtLeave(self, event):
w = event.widget
print 'evtLeave', w.winfo_class()
w.config(bg='SystemButtonFace')

def evtButtonOneRelease(self, event):
w = event.widget
print 'evtButtonOneRelease', w.winfo_class()
w.config(bg='Green')

def evtButtonThreeRelease(self, event):
w = event.widget
print 'evtButtonThreeRelease', w.winfo_class()
w.config(bg='Blue')

if __name__ == '__main__':
root = tk.Tk()
frame = FooFrame(root, width=100, height=100, bg='red', bd=1)
frame.pack(padx=5, pady=5)
root.mainloop()
## END CONDENSED CODE ##


In the code sample provided, you will see that the label widgets
stacked on each row will block "click" events on the containing
"rowFrames" below them. You can get a click event (on the sub frames)
to work by clicking the exaggerated border on the frames. All the
events work properly for me, although this GUI interface seems
unintuitive even with proper borders and colors.

Fredric, I can't help but feel that you are not attacking the problem
correctly. Please explain the following questions in detail so that i
may be able to provide help:

Q1. You have subclassed a Tkinter.Frame and you are building "rows" of
sub-frames into this toplevel frame; with each row holding
horizontally stacked label widgets. Okay, I can see a need to wrap up
a "RowFrame" object, but i don't see a need to create a
"RowFrameFactory". Can you explain this design decision?

Q2. It seems odd to me that you want to engage the "rowFrame" widgets
via events but NOT the Label widgets. Can you explain this design
decision?

 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      07-11-2012

Also:

Q3: Why are you explicitly setting the name of your "subFrame" widgets
instead of allowing Tkinter to assign a unique name?...AND are you
aware of the conflicts that can arise from such changes[1]?

Q4: Are you aware of the built-in function "enumerate"[2]? I see you
are passing around indexes to iterables AND simultaneously needing the
obj reference itself. I prefer to keep indexing to a minimum. If
there is no bleeding edge performance issue to worry about (and there
almost *always* never is) why not use enumerate?

[1] http://www.pythonware.com/library/tk...dget-names.htm
[2] http://docs.python.org/release/3.0.1...html#enumerate
 
Reply With Quote
 
Frederic Rentsch
Guest
Posts: n/a
 
      07-11-2012
On Tue, 2012-07-10 at 18:06 -0700, Rick Johnson wrote:
> Also:
>
> Q3: Why are you explicitly setting the name of your "subFrame" widgets
> instead of allowing Tkinter to assign a unique name?...AND are you
> aware of the conflicts that can arise from such changes[1]?
>


I find custom-named widgets easier to work with during development. I can tell
what this is; ".main-frame.data-frame.title-hit-list.-10-". If I didn't assign
names it would look something line this:".2837029.283725.283762.2848308".
Once my program works I can drop custom-naming.
I understand that conflicts may arise if one assigns numeric names.
To find out whether the digits in the label names ('-10-' above) might
be implicated, I changed to spelled-out names ('ten'). The change had no
effect. The reference you list blow (x147-more-on-widget-names.htm)
indeed says "don't use names which only contain digits".

> Q4: Are you aware of the built-in function "enumerate"[2]? I see you
> are passing around indexes to iterables AND simultaneously needing the
> obj reference itself. I prefer to keep indexing to a minimum. If
> there is no bleeding edge performance issue to worry about (and there
> almost *always* never is) why not use enumerate?
>

Aware, yes. In the habit of, no. Thanks for the reminder.

> [1] http://www.pythonware.com/library/tk...dget-names.htm
> [2] http://docs.python.org/release/3.0.1...html#enumerate


Frederic


 
Reply With Quote
 
Frederic Rentsch
Guest
Posts: n/a
 
      07-12-2012
On Tue, 2012-07-10 at 15:11 -0700, Rick Johnson wrote:
> I've tried to condense your code using the very limited info you have
> provided. I have removed unnecessarily configuring of widgets and
> exaggerated the widget borders to make debugging easier. Read below
> for Q&A.
>
> ## START CONDENSED CODE ##
> records = range(4)
>
> CNF_SUBFRAME = {
> 'bd':5, # rowFrame boder width.
> 'relief':RIDGE,
> }
>
> CNF_LABEL = {
> 'anchor':W,
> 'width':10,
> 'bg':'gray',
> }
>
> class FooFrame(tk.Frame):
> def __init__(self, master, **kw):
> tk.Frame.__init__(self, master, **kw)
> self.build_records()
>
> def build_records(self):
> # Should this method be called by __init__???
> # Not sure if "records" is passed-in or global???
> for n in range(len(records)):
> record = records[n]
> rowFrame = tk.Frame(self, name='-%d-'%n, **CNF_SUBFRAME)
> rowFrame.bind ('<Enter>', self.evtEnter)
> rowFrame.bind ('<Leave>', self.evtLeave)
> rowFrame.bind ('<ButtonRelease-1>',
> self.evtButtonOneRelease)
> rowFrame.bind ('<ButtonRelease-3>',
> self.evtButtonThreeRelease)
> rowFrame.grid (row=n+2, column=1, padx=5, pady=5)
> for i in range(4):
> lbtext = 'Label_'+str(i)
> label = tk.Label(rowFrame, text=lbtext, **CNF_LABEL)
> label.grid (row=0, column=i, sticky=NW)
>
> def evtEnter(self, event):
> w = event.widget
> print 'evtEnter', w.winfo_class()
> w.config(bg='magenta')
>
> def evtLeave(self, event):
> w = event.widget
> print 'evtLeave', w.winfo_class()
> w.config(bg='SystemButtonFace')
>
> def evtButtonOneRelease(self, event):
> w = event.widget
> print 'evtButtonOneRelease', w.winfo_class()
> w.config(bg='Green')
>
> def evtButtonThreeRelease(self, event):
> w = event.widget
> print 'evtButtonThreeRelease', w.winfo_class()
> w.config(bg='Blue')
>
> if __name__ == '__main__':
> root = tk.Tk()
> frame = FooFrame(root, width=100, height=100, bg='red', bd=1)
> frame.pack(padx=5, pady=5)
> root.mainloop()
> ## END CONDENSED CODE ##
>
>
> In the code sample provided, you will see that the label widgets
> stacked on each row will block "click" events on the containing
> "rowFrames" below them. You can get a click event (on the sub frames)
> to work by clicking the exaggerated border on the frames. All the
> events work properly for me, although this GUI interface seems
> unintuitive even with proper borders and colors.
>
> Fredric, I can't help but feel that you are not attacking the problem
> correctly. Please explain the following questions in detail so that i
> may be able to provide help:
>

It works for me too.

I spent another day running the offending class in a simplified
environment and it worked flawlessly. In what way the environment makes
the difference is anything but obvious. But it has got to be the
environment.

> Q1. You have subclassed a Tkinter.Frame and you are building "rows" of
> sub-frames into this toplevel frame; with each row holding
> horizontally stacked label widgets. Okay, I can see a need to wrap up
> a "RowFrame" object, but i don't see a need to create a
> "RowFrameFactory". Can you explain this design decision?
>

I sent this same response yesterday with a screen shot attached. The
message didn't pass. It must have been rejected by a spam filter. So I
try again without the screen shot. (Too bad. A picture is worth a
thousand words).
The "hit list" is a table of investment titles (stock, funds, bonds)
that displays upon entry of a search pattern into a respective template.
The table displays the matching records: name, symbol, ISIN, CUSIP, Sec.
Any line can be click-selected. So they are to look like buttons.
Representing the mentioned names and id codes in Label widgets was the
simplest way I could come up with to align them in columns, admittedly
without the benefit of much experience. But it does look good. the
layout is fine.
I find the Tkinter system quite challenging. Doing a layout isn't so
much a matter of dimensioning and placing things as a struggle to trick
a number of automatic dimensioning and placing mechanisms into
obliging--mechanisms that are rather numerous and hard to remember.

> Q2. It seems odd to me that you want to engage the "rowFrame" widgets
> via events but NOT the Label widgets. Can you explain this design
> decision?
>

Again, the labels serve to align the fields into columns. As to the
bindings, I just now found out, that <Entry> and <Leave> can be bound to
the line frame, but the mouse buttons don't act on the frame with the
labels covering it wall to wall. Entry will lighten up the background of
the line. Leave restores the normal color. <ButtonRelease-N> will select
the line, darkening the text. The coloring has to be done separately on
each label across the line, as the labels cover the frame. That isn't a
problem.

I'm sorry I can't post an intelligible piece that does NOT work. I
obviously can't post the whole thing. It is way too convoluted. But I
will post an intelligible condensate the moment I manage to distill one
without distilling away the flaw in question. At any rate I will post
the solution when I find it, which I will however long that may take.

Frederic


 
Reply With Quote
 
Peter Otten
Guest
Posts: n/a
 
      07-13-2012
Frederic Rentsch wrote:

> I'm sorry I can't post an intelligible piece that does NOT work. I
> obviously can't post the whole thing.


How about a pastebin then? Or even bitbucket/github as you need to track
changes anyway?

> It is way too convoluted.


"Convoluted" code is much easier to debug than no code

Another random idea: run your code on a more recent python/tcl installation.
If you are lucky you get a different error.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Tkinter.event.widget: handler gets name instead of widget. Frederic Rentsch Python 0 07-09-2012 08:39 PM
Tkinter.event.widget: handler gets name instead of widget. Frederic Rentsch Python 0 07-08-2012 09:19 PM
Return of gets gets John Joyce Ruby 0 04-23-2007 01:38 PM
gets gets John Joyce Ruby 2 03-26-2007 04:00 PM
Not only the selected HREF gets surrounded, but the whole row gets surrounded Stefan Mueller HTML 5 07-10-2006 11:53 AM



Advertisments