Re: A Dangling Tk Entry
On Thu, 12 Mar 2009 04:34:57 -, W. eWatson 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 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
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: -- 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
On Tue, 10 Mar 2009 12:41:07 -, W. eWatson
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("", 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 d
Re: A Dangling Tk Entry
r wrote:
On Mar 10, 10:52 am, "W. eWatson" 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:
--
http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
On Mar 10, 10:52 am, "W. eWatson" 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
"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("", 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:
--
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
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("", 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
Rhodri James wrote:
> On Tue, 10 Mar 2009 04:14:51 -, W. eWatson
> 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("", 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:
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
Re: A Dangling Tk Entry
On Tue, 10 Mar 2009 04:14:51 -, W. eWatson
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
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:
--
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 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:
--
http://mail.python.org/mailman/listinfo/python-list
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
r wrote:
On Mar 8, 9:34 pm, "W. eWatson" 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:
--
http://mail.python.org/mailman/listinfo/python-list
Re: A Dangling Tk Entry
On Mar 8, 9:34 pm, "W. eWatson" 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
