Re: A Dangling Tk Entry
On Thu, 12 Mar 2009 04:34:57 -, W. eWatson notval...@sbcglobal.net wrote: I happened to notice that BJ and Rhondi started a small subthread to Nice to know your observation skills are up to scratch :-( this, so I thought I'd explore it. It led to interesting things, but not for its content. I reviewed some things. I'll do you the courtesy or wrapping this up. I'll get straight to the point and be a minimal as possible in my response, without accusing or implying anyone of anything. My guess is that the first culprit was here: entry = Entry(master, width=10, ... entry.insert(0,self.slowdown) --- no affect. Erm, no. You stated (and showed us the code) that it was entry = Entry(master,...).grid(...) *big* difference, and entry.insert(0, self.slowdown) *raises an exception*, which is a long way from having no effect. -- Rhodri James *-* Wildebeeste Herder to the Masses -- http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
On Mar 11, 1:09 am, Marc 'BlackJack' Rintsch bj_...@gmx.net wrote: Then he did it consequently wrong. `frame_delay` is always `None` here so the ``return`` is useless. You asked what this code means and now you don't like the answer that it's somewhat useless code!? Ciao, Marc 'BlackJack' Rintsch Oh this is not the first time Walter has asked for help and then scoffed at those who wish to help him. Just look back through a few of his posts. I had ignored the other rudeness but i won't anymore. -- http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
On Mon, 09 Mar 2009 21:14:51 -0700, W. eWatson wrote:
def Set_Enter_Data(self):
sdict = {}
sdict[ ok ] = False
sdict[ anumber ] = self.anumber
dialog = Enter_Data_Dialog( self.master, sdict ) ---
returning
That's not a call to the `body()` method so that ``return`` is
irrelevant here. Here an instance of `Enter_Data_Dialog` is created.
No ``return`` involved.
BTW if this is really just a dialog to enter a number, the functions
`askinteger()` or `askfloat()` from the `tkSimpleDialog` module can be
used.
What you are seeing here as an example, is a paired down version of the
2000 line program to focus on the particular problem at hand. The full
code uses up to 20 variable of various types, via the dialog object. It
uses them successfully to get the values the user has entered. How can
it be irrelevant if it works?
The ``return`` in `body()` has nothing to do with the source line you
marked.
The author thought this was the way to do it.
And he thought wrong because his `body()` method returns `None`. That
works but not the way it is intended.
It's not my invention. It's no fluke. He does the same thing in
another dialog that brings back about 6 values.
def body(self,master):
self.title(Box Settings)
print body from BSD
...
frame_delay = Entry( master,
textvariable=self.frame_delay_var,
width=10 ).grid( row=2, column=1, sticky=W )
...
Entry( master,
textvariable=self.untrigger_threshold_var, width=10
).grid( row=4, column=1, sticky=W )
self.untrigger_threshold_var.set( %d %
self.sdict[untrigger_threshold] )
return frame_delay
Then he did it consequently wrong. `frame_delay` is always `None` here
so the ``return`` is useless.
You asked what this code means and now you don't like the answer that
it's somewhat useless code!?
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
I happened to notice that BJ and Rhondi started a small subthread to this, so I thought I'd explore it. It led to interesting things, but not for its content. I reviewed some things. I'll do you the courtesy or wrapping this up. I'll get straight to the point and be a minimal as possible in my response, without accusing or implying anyone of anything. My guess is that the first culprit was here: entry = Entry(master, width=10, ... entry.insert(0,self.slowdown) --- no affect. The next culprit was this: self.anumberVar.set( %d % self.sdict[anumber] ) One must be very careful of what is in anumber. That's it. Nothing else. The changes I've made in the 2000 lines of code work, as I had intended. The sample code now works as I had intended. (And no, I am not providing it. This thread doesn't need more explanation.) I can now proceed to eliminate all the control variables. You'll have to be satisfied with what I've said. I have no more to say. All parts of this thread I consider closed. Include me out. -- Yogi Berra -- W. eWatson (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39° 15' 7 N, 121° 2' 32 W, 2700 feet Web Page: www.speckledwithstars.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
Rhodri James wrote:
On Tue, 10 Mar 2009 04:14:51 -, W. eWatson notval...@sbcglobal.net
wrote:
Marc 'BlackJack' Rintsch wrote:
On Mon, 09 Mar 2009 04:22:57 -0700, W. eWatson wrote:
Marc 'BlackJack' Rintsch wrote:
On Sun, 08 Mar 2009 22:20:09 -0700, W. eWatson wrote:
You didn't answer my question why entry is necessary at all. The
original author thought it was necessary to return entry. I'll give
you a peek at a segment of the code I'm working with here:
class Enter_Data_Dialog(tkSimpleDialog.Dialog):
def __init__(self, parent, sdict):
self.sdict = sdict
tkSimpleDialog.Dialog.__init__(self, parent)
def body(self,master):
self.title(Set a Number Entry Dialog)
Label( master, text=Number ).grid(row=0, sticky=W)
self.anumberVar = StringVar()
entry = Entry(master, width=10,
textvariable=self.anumberVar).grid(row=0,
column=1)
self.anumberVar.set( %d % self.sdict[anumber] )
return entry
`entry` is unnecessary here. But that was not obvious from your
previous example, as you trimmed the code. Now it is clear that
`entry` is always `None` because that's what `grid()` returns.
But according to the docs this method should return the widget, that
should get the focus, so maybe the author really wanted to return the
`Entry` instance here, instead of `None`.
He's got to return something, because he uses it upon return, as here:
`entry` is always `None`, so it is the same as returning nothing
because every function has an implicit ``return None`` at the end.
def Set_Enter_Data(self):
sdict = {}
sdict[ ok ] = False
sdict[ anumber ] = self.anumber
dialog = Enter_Data_Dialog( self.master, sdict ) ---
returning
That's not a call to the `body()` method so that ``return`` is
irrelevant here. Here an instance of `Enter_Data_Dialog` is
created. No ``return`` involved.
BTW if this is really just a dialog to enter a number, the functions
`askinteger()` or `askfloat()` from the `tkSimpleDialog` module can
be used.
Ciao,
Marc 'BlackJack' Rintsch
What you are seeing here as an example, is a paired down version of
the 2000 line program to focus on the particular problem at hand. The
full code uses up to 20 variable of various types, via the dialog
object. It uses them successfully to get the values the user has
entered. How can it be irrelevant if it works? The author thought this
was the way to do it. It's not my invention. It's no fluke. He does
the same thing in another dialog that brings back about 6 values.
def body(self,master):
[snip]
You're misunderstanding. The line that you arrowed above has absolutely
nothing whatsoever to do with the method body(), so keeping on showing
us ever fuller version of that isn't going to prove anything. Now if
you were to show us a line like something = dialog.body(something_else)
then you might be onto something, but personally I suspect you're going
to find that rather hard.
I'd be happy to comply. Perhaps I'm mistaken as what I was responding to in
the entanglement of responses, but I think I was making a point (again) that
the technique by the author works. This should clear matters up completely.
Here's the full 80+ lines of the example code. Note wrapped lines.
from Tkinter import *
import tkSimpleDialog
import tkMessageBox
class IntVar_GUI:
def __init__(self, master):
master.title('Control Variable Fun')
self.frame = Frame(master,takefocus=1,
highlightthickness=2, highlightcolor='blue')
self.frame.configure(height=200,width=200)
self.frame.pack()
#self.frame.bind(KeyPress, self.HandleKey)
self.anumber = 123 # Want name and value to be configurable
self.master = master
menu = Menu(master)
master.config(menu=menu)
self.mainMenu = Menu(menu)
menu.add_cascade(label=My Menu,menu=self.mainMenu)
self.mainMenu.add_command(label=Enter Data,
command=self.Set_Enter_Data)
self.mainMenu.add_command(label=Exit,underline=1,command=self.Quit)
self.Focus()
def Set_Enter_Data(self):
sdict = {}
sdict[ ok ] = False
sdict[ anumber ] = self.anumber
dialog = Enter_Data_Dialog( self.master, sdict )
self.Focus()
print Howdy, set data. Number is:, dialog.anumberVar.get()
print dict:, dialog.sdict
if not dialog.sdict[ok]:
return
try:
self.anumber = int(eval(dialog.anumberVar.get()))
print OK
except:
print Not OK
pass
print self.anumber:, self.anumber
def Quit(self):
self.running = False
#self.master.quit()
self.master.destroy()
def Focus( self ):
self.frame.focus_set()
class
Re: A Dangling Tk Entry
OK, here is a slightly cleaned up version of this horrible code. I did
not change too much at one time for fear of confusing you. The main
problem is you did not explicitly grid the entry like i told you
earlier, and why you are using eval is beyond any measure of sanity...
from Tkinter import *
import tkSimpleDialog
class IntVar_GUI:
def __init__(self, master):
self.master = master
master.title('Control Variable Fun')
self.frame = Frame(master, height=200, width=200,
takefocus=1, highlightthickness=2, highlightcolor='blue')
self.frame.pack()
#self.frame.bind(KeyPress, self.HandleKey)
self.anumber = 123 # Want name and value to be configurable
menu = Menu(master)
master.config(menu=menu)
self.mainMenu = Menu(menu)
menu.add_cascade(label=My Menu,menu=self.mainMenu)
self.mainMenu.add_command(label=Enter Data,
command=self.Set_Enter_Data)
self.mainMenu.add_command
(label=Exit,underline=1,command=self.Quit)
self.Focus()
def Set_Enter_Data(self):
sdict = {ok:False, anumber:self.anumber}
dialog = Enter_Data_Dialog(self.master, sdict)
self.Focus()
print Howdy, set data. Number is:, dialog.anumberVar.get()
print dict:, dialog.sdict
if not dialog.sdict[ok]:
return
try:
self.anumber = int(dialog.anumberVar.get())#why the heck
where you using eval here?
print OK
except:
print Not OK
pass
print self.anumber:, self.anumber
def Quit(self):
self.running = False
#self.master.quit()
self.master.destroy()
def Focus( self ):
self.frame.focus_set()
class Enter_Data_Dialog(tkSimpleDialog.Dialog):
def __init__(self, parent, sdict):
self.sdict = sdict
tkSimpleDialog.Dialog.__init__(self, parent)
def body(self,master):
self.title(Set a Number Entry Dialog)
Label( master, text=Number ).grid(row=0, sticky=W)
self.anumberVar = StringVar()
entry = Entry(master, width=10, textvariable=self.anumberVar)
entry.grid(row=0, column=1) #i told you to explicitly grid a
widget you want to call later
entry.insert(0,11)
self.anumberVar.set( %d % self.sdict[anumber] )
return entry
def apply(self):
self.sdict[ok] = True
def Process():
root = Tk()
app = IntVar_GUI(root)
root.mainloop()
if __name__ == __main__:
Process()
The next message i send will be a rewrite of this code in a proper
Pythonic fashion, this frankly is a plate of spaghetti!
--
http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
Alright try this code. The only thing that i left out was inheriting
from Frame, but since i cannot see your entire progam i did not want
to do that for fear of breaking some other code. You had a lot of
useless code in there and more code that was just a spaghetti mess. If
you want to return a dict instead of a tuple like i did feel free :)
from Tkinter import *
import tkSimpleDialog
class EnterDataDialog(tkSimpleDialog.Dialog):
def __init__(self, parent, sdict):
self.sdict = sdict
tkSimpleDialog.Dialog.__init__(self, parent)
def body(self, master):
self.title(Set a Number)
Label( master, text=Number ).grid(row=0, sticky=W)
self.v = IntVar()
entry = Entry(master, width=10, textvariable=self.v)
entry.grid(row=0, column=1) #i told you to explicitly grid a
widget you want to call later
self.v.set( %d % self.sdict[anumber] )
return entry #return widget that recieves focus
def validate(self):
try:
self.v.get()
except:
return 0
return 1
def apply(self):
self.result = self.v.get()
class IntVar_GUI():
def __init__(self, master):
self.master = master
master.title('Control Variable Fun')
frame = Frame(master, height=200, width=200, takefocus=1,
highlightthickness=2, highlightcolor='blue')
frame.pack()
self.anumber = 123 # Want name and value to be configurable
menu = Menu(master)
master.config(menu=menu)
mainMenu = Menu(menu)
menu.add_cascade(label=My Menu, menu=mainMenu)
mainMenu.add_command(label=Enter Data,
command=self.Set_Enter_Data)
self.master.protocol(WM_DELETE_WINDOW, self.onQuit)
frame.focus_set()
def Set_Enter_Data(self):
sdict = {anumber:self.anumber}
d = EnterDataDialog(self.master, sdict)
if d.result:
print User Entered: , d.result
else:
print 'The idiot pressed cancel!'
def onQuit(self):
self.running = False
self.master.destroy()
if __name__ == __main__:
root = Tk()
app = IntVar_GUI(root)
root.mainloop()
--
http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
Down, Fang! Down, boy. Down. -- Soupy Sales, Comedian, talking to his
imaginary animal, circa 1960.
Thank you very much. One more quote before I continue. A favorite.
The trouble with most folks isn't their ignorance. It's knowin' so
many things that ain't so. by Josh Billings, a 19th century
humorist (and not Mark Twain).
I could quote my wife next, but I'll skip it. As I believe I've repeatedly
said, (aren't those interesting words? Sort of sound huffy, don't they?), I
am not the author of the code. If I didn't mention it before, I am not about
to wholesale change his code for the purposes I have at hand, so I try to
remain faithful to what was written. As far as taking your grid suggestions,
I believe I did, very likely in the 2000 lines of father code (the author's
original code.) For whatever reason, they didn't work. Yes, even I am as a
lowly newcomer to Python and Tkinter have heard the eval story. Again, I do
not want diversions while I'm adding to this program.
Just to be clear about what I'm adding, the program needed, IMHO, a
configuration file. I've already added a menu item in other parts of the
code to save it, and to initialize the 'global' values the author uses in
IntVar_GUI. That's the alias here for Sentinel_GUI in the big program. Now I
can proceed to initialize the dialog and others without using control
variables. This config effort I could have skipped, but thought it's now or
never. I have things to add to the program that are way more interesting
than this, and will have big payoffs to the users (a closed group of about
40 users).
Despite my no messing with code technique policy, I may have to take into
consideration some of your changes here, and your follow up. And, yes, I
think I can now begin to tune up my geometry knowledge of Tkinter.
So again, thanks for your help. (I hope you don't mind my repetition here.)
:-)
r wrote:
OK, here is a slightly cleaned up version of this horrible code. I did
not change too much at one time for fear of confusing you. The main
problem is you did not explicitly grid the entry like i told you
earlier, and why you are using eval is beyond any measure of sanity...
from Tkinter import *
import tkSimpleDialog
class IntVar_GUI:
def __init__(self, master):
self.master = master
master.title('Control Variable Fun')
self.frame = Frame(master, height=200, width=200,
takefocus=1, highlightthickness=2, highlightcolor='blue')
self.frame.pack()
#self.frame.bind(KeyPress, self.HandleKey)
self.anumber = 123 # Want name and value to be configurable
menu = Menu(master)
master.config(menu=menu)
self.mainMenu = Menu(menu)
menu.add_cascade(label=My Menu,menu=self.mainMenu)
self.mainMenu.add_command(label=Enter Data,
command=self.Set_Enter_Data)
self.mainMenu.add_command
(label=Exit,underline=1,command=self.Quit)
self.Focus()
def Set_Enter_Data(self):
sdict = {ok:False, anumber:self.anumber}
dialog = Enter_Data_Dialog(self.master, sdict)
self.Focus()
print Howdy, set data. Number is:, dialog.anumberVar.get()
print dict:, dialog.sdict
if not dialog.sdict[ok]:
return
try:
self.anumber = int(dialog.anumberVar.get())#why the heck
where you using eval here?
print OK
except:
print Not OK
pass
print self.anumber:, self.anumber
def Quit(self):
self.running = False
#self.master.quit()
self.master.destroy()
def Focus( self ):
self.frame.focus_set()
class Enter_Data_Dialog(tkSimpleDialog.Dialog):
def __init__(self, parent, sdict):
self.sdict = sdict
tkSimpleDialog.Dialog.__init__(self, parent)
def body(self,master):
self.title(Set a Number Entry Dialog)
Label( master, text=Number ).grid(row=0, sticky=W)
self.anumberVar = StringVar()
entry = Entry(master, width=10, textvariable=self.anumberVar)
entry.grid(row=0, column=1) #i told you to explicitly grid a
widget you want to call later
entry.insert(0,11)
self.anumberVar.set( %d % self.sdict[anumber] )
return entry
def apply(self):
self.sdict[ok] = True
def Process():
root = Tk()
app = IntVar_GUI(root)
root.mainloop()
if __name__ == __main__:
Process()
The next message i send will be a rewrite of this code in a proper
Pythonic fashion, this frankly is a plate of spaghetti!
--
W. eWatson
(121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
Obz Site: 39° 15' 7 N, 121° 2' 32 W, 2700 feet
Web Page: www.speckledwithstars.net/
--
http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
On Mar 10, 10:52 am, W. eWatson notval...@sbcglobal.net wrote:
[snip: biting the hand that feeds]
This is not the first time you have come to c.l.py with hat in hand
seeking help and then scoffed at suggestions made by well respected
posters. I should have known you would just do the same again. I don't
know what you want but help is defiantly not it although that is
exactly what you need!
If I didn't mention it before, I am not about
to wholesale change his code for the purposes I have at hand, so I try to
remain faithful to what was written. As far as taking your grid suggestions,
I believe I did, very likely in the 2000 lines of father code (the author's
original code.) For whatever reason, they didn't work. Yes, even I am as a
lowly newcomer to Python and Tkinter have heard the eval story. Again, I do
not want diversions while I'm adding to this program.
[snip: non-sensical rambling]
You think my changes where wholesale. I untangled your spaghetti
code and showed you how it should be done with the same output you
originally had(while at the same time trying hard not to confuse you
by making the code too perfect), only unlike your mess, my code
doesn't throw 10 exceptions. There is nothing in there that will break
compatibility with your code, heck you said it was broken to start.
Just to be clear about what I'm adding, the program needed, IMHO, a
configuration file. I've already added a menu item in other parts of the
code to save it, and to initialize the 'global' values the author uses in
IntVar_GUI. That's the alias here for Sentinel_GUI in the big program. Now I
can proceed to initialize the dialog and others without using control
variables. This config effort I could have skipped, but thought it's now or
never. I have things to add to the program that are way more interesting
than this, and will have big payoffs to the users (a closed group of about
40 users).
If this 80 line code you posted actually is a line by line copy paste
from your suposedly high and mighty original author's code, you would
be much better off trashing this garbage and starting from scratch,
because apparently he had no idea what he was doing either. Using
naming conventions like IntVar_GUI instead of IntVarGui, and
Enter_Data_Dialog instead of EnterDataDialog . Not to mention this
redundant stupidity
sdict = {}
sdict[ ok ] = False
sdict[ anumber ] = self.anumber
Only a complete noob would do something like that! Not to mention that
he created a Focus method that calls one line of code. This is a
classic case of the blind leading the blind.
good day pal... and oh yea, good luck!
--
http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
r wrote:
On Mar 10, 10:52 am, W. eWatson notval...@sbcglobal.net wrote:
[snip: biting the hand that feeds]
This is not the first time you have come to c.l.py with hat in hand
seeking help and then scoffed at suggestions made by well respected
posters. I should have known you would just do the same again. I don't
know what you want but help is defiantly not it although that is
exactly what you need!
If I didn't mention it before, I am not about
to wholesale change his code for the purposes I have at hand, so I try to
remain faithful to what was written. As far as taking your grid suggestions,
I believe I did, very likely in the 2000 lines of father code (the author's
original code.) For whatever reason, they didn't work. Yes, even I am as a
lowly newcomer to Python and Tkinter have heard the eval story. Again, I do
not want diversions while I'm adding to this program.
[snip: non-sensical rambling]
You think my changes where wholesale. I untangled your spaghetti
code and showed you how it should be done with the same output you
originally had(while at the same time trying hard not to confuse you
by making the code too perfect), only unlike your mess, my code
doesn't throw 10 exceptions. There is nothing in there that will break
compatibility with your code, heck you said it was broken to start.
Just to be clear about what I'm adding, the program needed, IMHO, a
configuration file. I've already added a menu item in other parts of the
code to save it, and to initialize the 'global' values the author uses in
IntVar_GUI. That's the alias here for Sentinel_GUI in the big program. Now I
can proceed to initialize the dialog and others without using control
variables. This config effort I could have skipped, but thought it's now or
never. I have things to add to the program that are way more interesting
than this, and will have big payoffs to the users (a closed group of about
40 users).
If this 80 line code you posted actually is a line by line copy paste
from your suposedly high and mighty original author's code, you would
be much better off trashing this garbage and starting from scratch,
because apparently he had no idea what he was doing either. Using
naming conventions like IntVar_GUI instead of IntVarGui, and
Enter_Data_Dialog instead of EnterDataDialog . Not to mention this
redundant stupidity
sdict = {}
sdict[ ok ] = False
sdict[ anumber ] = self.anumber
Only a complete noob would do something like that! Not to mention that
he created a Focus method that calls one line of code. This is a
classic case of the blind leading the blind.
good day pal... and oh yea, good luck!
Pardon me, it was White Fang.
--
W. eWatson
(121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
Obz Site: 39° 15' 7 N, 121° 2' 32 W, 2700 feet
Web Page: www.speckledwithstars.net/
--
http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
On Tue, 10 Mar 2009 12:41:07 -, W. eWatson notval...@sbcglobal.net
wrote:
[snippety snip]
Rhodri James wrote:
You're misunderstanding. The line that you arrowed above has
absolutely
nothing whatsoever to do with the method body(), so keeping on
showing
us ever fuller version of that isn't going to prove anything. Now if
you were to show us a line like something =
dialog.body(something_else)
then you might be onto something, but personally I suspect you're
going
to find that rather hard.
I'd be happy to comply. Perhaps I'm mistaken as what I was responding to
in the entanglement of responses, but I think I was making a point
(again) that the technique by the author works. This should clear
matters up completely. Here's the full 80+ lines of the example code.
Note wrapped lines.
from Tkinter import *
import tkSimpleDialog
import tkMessageBox
class IntVar_GUI:
def __init__(self, master):
master.title('Control Variable Fun')
self.frame = Frame(master,takefocus=1,
highlightthickness=2, highlightcolor='blue')
self.frame.configure(height=200,width=200)
self.frame.pack()
#self.frame.bind(KeyPress, self.HandleKey)
self.anumber = 123 # Want name and value to be configurable
self.master = master
menu = Menu(master)
master.config(menu=menu)
self.mainMenu = Menu(menu)
menu.add_cascade(label=My Menu,menu=self.mainMenu)
self.mainMenu.add_command(label=Enter Data,
command=self.Set_Enter_Data)
self.mainMenu.add_command(label=Exit,underline=1,command=self.Quit)
self.Focus()
def Set_Enter_Data(self):
sdict = {}
sdict[ ok ] = False
sdict[ anumber ] = self.anumber
dialog = Enter_Data_Dialog( self.master, sdict )
self.Focus()
print Howdy, set data. Number is:, dialog.anumberVar.get()
print dict:, dialog.sdict
if not dialog.sdict[ok]:
return
try:
self.anumber = int(eval(dialog.anumberVar.get()))
print OK
except:
print Not OK
pass
print self.anumber:, self.anumber
def Quit(self):
self.running = False
#self.master.quit()
self.master.destroy()
def Focus( self ):
self.frame.focus_set()
class Enter_Data_Dialog(tkSimpleDialog.Dialog):
def __init__(self, parent, sdict):
self.sdict = sdict
tkSimpleDialog.Dialog.__init__(self, parent)
def body(self,master):
self.title(Set a Number Entry Dialog)
Label( master, text=Number ).grid(row=0, sticky=W)
self.anumberVar = StringVar()
entry = Entry(master, width=10,
textvariable=self.anumberVar).grid(row=0, column=1)
entry.insert(0,11)
self.anumberVar.set( %d % self.sdict[anumber] )
return entry
def apply(self):
self.sdict[ok] = True
def Process():
root = Tk()
app = IntVar_GUI(root)
root.mainloop()
if __name__ == __main__:
Process()
Because I'm operating out for a command prompt, I don't seem to be able
to copy all the error msgs, but here is the last one shown involving
line 68,
AttributeError: None Type' object has no attribute 'insert'
Line 68 is entry.insert(0,11)
I'm operating from the command line too. The traceback is:
Exception in Tkinter callback
Traceback (most recent call last):
File /usr/lib/python2.5/lib-tk/Tkinter.py, line 1406, in __call__
return self.func(*args)
File temp.py, line 34, in Set_Enter_Data
dialog = Enter_Data_Dialog( self.master, sdict )
File temp.py, line 60, in __init__
tkSimpleDialog.Dialog.__init__(self, parent)
File /usr/lib/python2.5/lib-tk/tkSimpleDialog.py, line 64, in __init__
self.initial_focus = self.body(body)
File temp.py, line 68, in body
entry.insert(0,11)
AttributeError: 'NoneType' object has no attribute 'insert'
In other words entry is None. This is the entry that's a local
variable in the Enter_Data_Dialog class body method (called
automatically by tkSimpleDialog.Dialog.__init__, it turns out, so my
apologies for implying that it wasn't called at all), the one that's
created by the line
entry = Entry(master,...).grid(row=0,...)
Given that this is what grid is expected to return, this shouldn't be
the shock that apparently it is. This entry is also the return value
from body, which won't be helpful. The Dialog documentation says this:
body(self, master)
create dialog body.
return widget that should have initial focus.
This method should be overridden, and is called
by the __init__ method.
This suggests that the code originally looked like this:
entry = Entry(master,...)
entry.grid(row=0,...)
and someone decided to optimise it. Put it back the way it
Re: A Dangling Tk Entry
On Sun, 08 Mar 2009 22:20:09 -0700, W. eWatson wrote: You didn't answer my question why entry is necessary at all. The original author thought it was necessary to return entry. I'll give you a peek at a segment of the code I'm working with here: class Enter_Data_Dialog(tkSimpleDialog.Dialog): def __init__(self, parent, sdict): self.sdict = sdict tkSimpleDialog.Dialog.__init__(self, parent) def body(self,master): self.title(Set a Number Entry Dialog) Label( master, text=Number ).grid(row=0, sticky=W) self.anumberVar = StringVar() entry = Entry(master, width=10, textvariable=self.anumberVar).grid(row=0, column=1) self.anumberVar.set( %d % self.sdict[anumber] ) return entry `entry` is unnecessary here. But that was not obvious from your previous example, as you trimmed the code. Now it is clear that `entry` is always `None` because that's what `grid()` returns. But according to the docs this method should return the widget, that should get the focus, so maybe the author really wanted to return the `Entry` instance here, instead of `None`. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
Marc 'BlackJack' Rintsch wrote:
On Sun, 08 Mar 2009 22:20:09 -0700, W. eWatson wrote:
You didn't answer my question why entry is necessary at all. The
original author thought it was necessary to return entry. I'll give you
a peek at a segment of the code I'm working with here:
class Enter_Data_Dialog(tkSimpleDialog.Dialog):
def __init__(self, parent, sdict):
self.sdict = sdict
tkSimpleDialog.Dialog.__init__(self, parent)
def body(self,master):
self.title(Set a Number Entry Dialog)
Label( master, text=Number ).grid(row=0, sticky=W)
self.anumberVar = StringVar()
entry = Entry(master, width=10,
textvariable=self.anumberVar).grid(row=0,
column=1)
self.anumberVar.set( %d % self.sdict[anumber] )
return entry
`entry` is unnecessary here. But that was not obvious from your previous
example, as you trimmed the code. Now it is clear that `entry` is always
`None` because that's what `grid()` returns.
But according to the docs this method should return the widget, that
should get the focus, so maybe the author really wanted to return the
`Entry` instance here, instead of `None`.
Ciao,
Marc 'BlackJack' Rintsch
He's got to return something, because he uses it upon return, as here:
def Set_Enter_Data(self):
sdict = {}
sdict[ ok ] = False
sdict[ anumber ] = self.anumber
dialog = Enter_Data_Dialog( self.master, sdict ) --- returning
self.Focus()
print Howdy, set data. Number is:, dialog.anumberVar.get()
print dict:, dialog.sdict
if not dialog.sdict[ok]:
return
try:
self.anumber = int(eval(dialog.anumberVar.get()))
print OK
except:
print Not OK
pass
print self.anumber:, self.anumber
--
W. eWatson
(121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
Obz Site: 39° 15' 7 N, 121° 2' 32 W, 2700 feet
Web Page: www.speckledwithstars.net/
--
http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
On Mon, 09 Mar 2009 04:22:57 -0700, W. eWatson wrote:
Marc 'BlackJack' Rintsch wrote:
On Sun, 08 Mar 2009 22:20:09 -0700, W. eWatson wrote:
You didn't answer my question why entry is necessary at all. The
original author thought it was necessary to return entry. I'll give
you a peek at a segment of the code I'm working with here:
class Enter_Data_Dialog(tkSimpleDialog.Dialog):
def __init__(self, parent, sdict):
self.sdict = sdict
tkSimpleDialog.Dialog.__init__(self, parent)
def body(self,master):
self.title(Set a Number Entry Dialog)
Label( master, text=Number ).grid(row=0, sticky=W)
self.anumberVar = StringVar()
entry = Entry(master, width=10,
textvariable=self.anumberVar).grid(row=0,
column=1)
self.anumberVar.set( %d % self.sdict[anumber] )
return entry
`entry` is unnecessary here. But that was not obvious from your
previous example, as you trimmed the code. Now it is clear that
`entry` is always `None` because that's what `grid()` returns.
But according to the docs this method should return the widget, that
should get the focus, so maybe the author really wanted to return the
`Entry` instance here, instead of `None`.
He's got to return something, because he uses it upon return, as here:
`entry` is always `None`, so it is the same as returning nothing because
every function has an implicit ``return None`` at the end.
def Set_Enter_Data(self):
sdict = {}
sdict[ ok ] = False
sdict[ anumber ] = self.anumber
dialog = Enter_Data_Dialog( self.master, sdict ) --- returning
That's not a call to the `body()` method so that ``return`` is irrelevant
here. Here an instance of `Enter_Data_Dialog` is created. No ``return``
involved.
BTW if this is really just a dialog to enter a number, the functions
`askinteger()` or `askfloat()` from the `tkSimpleDialog` module can be
used.
Ciao,
Marc 'BlackJack' Rintsch
--
http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
Marc 'BlackJack' Rintsch wrote:
On Mon, 09 Mar 2009 04:22:57 -0700, W. eWatson wrote:
Marc 'BlackJack' Rintsch wrote:
On Sun, 08 Mar 2009 22:20:09 -0700, W. eWatson wrote:
You didn't answer my question why entry is necessary at all. The
original author thought it was necessary to return entry. I'll give
you a peek at a segment of the code I'm working with here:
class Enter_Data_Dialog(tkSimpleDialog.Dialog):
def __init__(self, parent, sdict):
self.sdict = sdict
tkSimpleDialog.Dialog.__init__(self, parent)
def body(self,master):
self.title(Set a Number Entry Dialog)
Label( master, text=Number ).grid(row=0, sticky=W)
self.anumberVar = StringVar()
entry = Entry(master, width=10,
textvariable=self.anumberVar).grid(row=0,
column=1)
self.anumberVar.set( %d % self.sdict[anumber] )
return entry
`entry` is unnecessary here. But that was not obvious from your
previous example, as you trimmed the code. Now it is clear that
`entry` is always `None` because that's what `grid()` returns.
But according to the docs this method should return the widget, that
should get the focus, so maybe the author really wanted to return the
`Entry` instance here, instead of `None`.
He's got to return something, because he uses it upon return, as here:
`entry` is always `None`, so it is the same as returning nothing because
every function has an implicit ``return None`` at the end.
def Set_Enter_Data(self):
sdict = {}
sdict[ ok ] = False
sdict[ anumber ] = self.anumber
dialog = Enter_Data_Dialog( self.master, sdict ) --- returning
That's not a call to the `body()` method so that ``return`` is irrelevant
here. Here an instance of `Enter_Data_Dialog` is created. No ``return``
involved.
BTW if this is really just a dialog to enter a number, the functions
`askinteger()` or `askfloat()` from the `tkSimpleDialog` module can be
used.
Ciao,
Marc 'BlackJack' Rintsch
What you are seeing here as an example, is a paired down version of the 2000
line program to focus on the particular problem at hand. The full code uses
up to 20 variable of various types, via the dialog object. It uses them
successfully to get the values the user has entered. How can it be
irrelevant if it works? The author thought this was the way to do it. It's
not my invention. It's no fluke. He does the same thing in another dialog
that brings back about 6 values.
def body(self,master):
self.title(Box Settings)
print body from BSD
...
frame_delay = Entry( master,
textvariable=self.frame_delay_var,
width=10 ).grid( row=2, column=1, sticky=W )
...
Entry( master,
textvariable=self.untrigger_threshold_var,
width=10 ).grid( row=4, column=1, sticky=W )
self.untrigger_threshold_var.set( %d %
self.sdict[untrigger_threshold] )
return frame_delay
BTW, forget the textvariable use. They are irrelevant.
--
W. eWatson
(121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time)
Obz Site: 39° 15' 7 N, 121° 2' 32 W, 2700 feet
Web Page: www.speckledwithstars.net/
--
http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
On Tue, 10 Mar 2009 04:14:51 -, W. eWatson notval...@sbcglobal.net
wrote:
Marc 'BlackJack' Rintsch wrote:
On Mon, 09 Mar 2009 04:22:57 -0700, W. eWatson wrote:
Marc 'BlackJack' Rintsch wrote:
On Sun, 08 Mar 2009 22:20:09 -0700, W. eWatson wrote:
You didn't answer my question why entry is necessary at all. The
original author thought it was necessary to return entry. I'll give
you a peek at a segment of the code I'm working with here:
class Enter_Data_Dialog(tkSimpleDialog.Dialog):
def __init__(self, parent, sdict):
self.sdict = sdict
tkSimpleDialog.Dialog.__init__(self, parent)
def body(self,master):
self.title(Set a Number Entry Dialog)
Label( master, text=Number ).grid(row=0, sticky=W)
self.anumberVar = StringVar()
entry = Entry(master, width=10,
textvariable=self.anumberVar).grid(row=0,
column=1)
self.anumberVar.set( %d % self.sdict[anumber] )
return entry
`entry` is unnecessary here. But that was not obvious from your
previous example, as you trimmed the code. Now it is clear that
`entry` is always `None` because that's what `grid()` returns.
But according to the docs this method should return the widget, that
should get the focus, so maybe the author really wanted to return the
`Entry` instance here, instead of `None`.
He's got to return something, because he uses it upon return, as here:
`entry` is always `None`, so it is the same as returning nothing
because every function has an implicit ``return None`` at the end.
def Set_Enter_Data(self):
sdict = {}
sdict[ ok ] = False
sdict[ anumber ] = self.anumber
dialog = Enter_Data_Dialog( self.master, sdict ) ---
returning
That's not a call to the `body()` method so that ``return`` is
irrelevant here. Here an instance of `Enter_Data_Dialog` is created.
No ``return`` involved.
BTW if this is really just a dialog to enter a number, the functions
`askinteger()` or `askfloat()` from the `tkSimpleDialog` module can be
used.
Ciao,
Marc 'BlackJack' Rintsch
What you are seeing here as an example, is a paired down version of the
2000 line program to focus on the particular problem at hand. The full
code uses up to 20 variable of various types, via the dialog object. It
uses them successfully to get the values the user has entered. How can
it be irrelevant if it works? The author thought this was the way to do
it. It's not my invention. It's no fluke. He does the same thing in
another dialog that brings back about 6 values.
def body(self,master):
[snip]
You're misunderstanding. The line that you arrowed above has absolutely
nothing whatsoever to do with the method body(), so keeping on showing
us ever fuller version of that isn't going to prove anything. Now if
you were to show us a line like something = dialog.body(something_else)
then you might be onto something, but personally I suspect you're going
to find that rather hard.
--
Rhodri James *-* Wildebeeste Herder to the Masses
--
http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
Walter, Why don't you just explain in simple English exactly what you would like to do. You posts have jumped from why this to why that and none of your jumping around makes much sense. Typically you want to concentrate on one problem at a time and move in a linear fashion not hop around aimlessly like a flea on an elephants rump. -- http://mail.python.org/mailman/listinfo/python-list
A Dangling Tk Entry
I'm looking at some Tk code written by someone else, and am curious about a methodology in the code. A setup object called SetDlg contains to code to set up parameters for some widgets for a dialog of radio buttons, checkboxes, and text/string entries. It then calls ShowDlg. After it returns in resets any new values entered for parameters. It's return is entry, which is of class Entry. The curious code is in ShowDlg. It looks like Radiboutton(master, textvariable = ... Radiobutton(msster, textvariable = ... Checkbox(master, text=... entry = Entry(master, width=10, ... entry.insert(0,self.slowdown)# testing a default methodology Label( master, text=Max... Entry(master, width=10, textvar... ... return entry First, what is the meaning of entry=Entry(...? That is, other than create an Entry, why that particular position, and why not with say Checkbox? Further, SetDlg has used ShowDlg by calling dialog=ShowDlg(( self.master, set_a... dialog is then used to get at the parameters set by the user. I thought I'd give ShowDlg an attribute by using entry.insert(0,self.slowdown inserting it before return. Upon return from ShowDlg, which was invoked by, dialog = ShowDlg( self.master, set_a ..., I thought I'd grab slowdown with x= dialog.slowdown. The program didn't get that far, so, second, I'd like to know why it died on the insert statement? That line, produced 'NoneType' object has no attribute 'insert' , and entry and its type are None and type 'NoneType' What has gone wrong? -- W. eWatson (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39° 15' 7 N, 121° 2' 32 W, 2700 feet Web Page: www.speckledwithstars.net/ -- http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
On Mar 8, 9:34 pm, W. eWatson notval...@sbcglobal.net wrote: Radiboutton(master, textvariable = ... Radiobutton(msster, textvariable = ... Checkbox(master, text=... entry = Entry(master, width=10, ... entry.insert(0,self.slowdown) # testing a default methodology Label( master, text=Max... Entry(master, width=10, textvar... ... return entry First, what is the meaning of entry=Entry(...? That is, other than create an Entry, why that particular position, and why not with say Checkbox? It sounds like you don't understands some fundamentals of Tkinter programming. You only need to create a reference(instance) to a tk widget if you plan to access it later. Widgets like labels (in some cases) will never change, so creating an instance is just furturing your capal tunnel avancment. :). Checkbuttons and Radiobuttons use Variables to query thr widget so they also do not need to be instanced Something else that you need to understand, You must explicitly pack (), place(), or grid() a widget instance if you wish to call that instance later or you will get an error. #-- this no work --# entry = Entry(master).pack() #cannot call entry.method() #-- this works --# entry = Entry(master) entry.pack() Further, SetDlg has used ShowDlg by calling dialog=ShowDlg(( self.master, set_a... dialog is then used to get at the parameters set by the user. I thought I'd give ShowDlg an attribute by using entry.insert(0,self.slowdown inserting it before return. Upon return from ShowDlg, which was invoked by, dialog = ShowDlg( self.master, set_a ..., I thought I'd grab slowdown with x= dialog.slowdown. The program didn't get that far, so, second, I'd like to know why it died on the insert statement? That line, produced 'NoneType' object has no attribute 'insert' , and entry and its type are None and type 'NoneType' What has gone wrong? I would suspect a geometry manager issue here but you really should post all the code for this dialog. -- http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
r wrote: On Mar 8, 9:34 pm, W. eWatson notval...@sbcglobal.net wrote: Radiboutton(master, textvariable = ... Radiobutton(msster, textvariable = ... Checkbox(master, text=... entry = Entry(master, width=10, ... entry.insert(0,self.slowdown)# testing a default methodology Label( master, text=Max... Entry(master, width=10, textvar... ... return entry First, what is the meaning of entry=Entry(...? That is, other than create an Entry, why that particular position, and why not with say Checkbox? It sounds like you don't understands some fundamentals of Tkinter programming. You only need to create a reference(instance) to a tk widget if you plan to access it later. Widgets like labels (in some cases) will never change, so creating an instance is just furturing your capal tunnel avancment. :). Checkbuttons and Radiobuttons use Variables to query thr widget so they also do not need to be instanced Something else that you need to understand, You must explicitly pack (), place(), or grid() a widget instance if you wish to call that instance later or you will get an error. #-- this no work --# entry = Entry(master).pack() #cannot call entry.method() #-- this works --# entry = Entry(master) entry.pack() Further, SetDlg has used ShowDlg by calling dialog=ShowDlg(( self.master, set_a... dialog is then used to get at the parameters set by the user. I thought I'd give ShowDlg an attribute by using entry.insert(0,self.slowdown inserting it before return. Upon return from ShowDlg, which was invoked by, dialog = ShowDlg( self.master, set_a ..., I thought I'd grab slowdown with x= dialog.slowdown. The program didn't get that far, so, second, I'd like to know why it died on the insert statement? That line, produced 'NoneType' object has no attribute 'insert' , and entry and its type are None and type 'NoneType' What has gone wrong? I would suspect a geometry manager issue here but you really should post all the code for this dialog. Guilty as charged, somewhat. I'm modifying someone else's code to provide new features, and have modest understanding of how Tk works. However, the reason for making them an instance is not unreasonable at all. This should work. I really don't think the geometry mgr has anything to do with it. If there's an early miscue here on my part, it's about using insert. My understanding is that insert will allow me put something into the entry area shown in the widget on the screen. That is if, I put up: Enter Data Here: __, the _ represents the entry widget created. What I'm trying to do is initialeze it with, say, 1234. You didn't answer my question why entry is necessary at all. The original author thought it was necessary to return entry. I'll give you a peek at a segment of the code I'm working with here: class Enter_Data_Dialog(tkSimpleDialog.Dialog): def __init__(self, parent, sdict): self.sdict = sdict tkSimpleDialog.Dialog.__init__(self, parent) def body(self,master): self.title(Set a Number Entry Dialog) Label( master, text=Number ).grid(row=0, sticky=W) self.anumberVar = StringVar() entry = Entry(master, width=10, textvariable=self.anumberVar).grid(row=0, column=1) self.anumberVar.set( %d % self.sdict[anumber] ) return entry This code works. What I'm trying to do is to eliminate the unnecessary use of control variables. As it, stands the calling program sets up the default value for anumber and returns whatever new value enters. -- W. eWatson (121.015 Deg. W, 39.262 Deg. N) GMT-8 hr std. time) Obz Site: 39° 15' 7 N, 121° 2' 32 W, 2700 feet Web Page: www.speckledwithstars.net/ -- http://mail.python.org/mailman/listinfo/python-list
