Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Kent Johnson]

On Thu, Mar 5, 2009 at 11:36 AM, Wayne Watson
 wrote:

> It looks like your sample code code has the right idea, but the hang up with
> the original code is getting entered values back to the main program and
> available globally through it. The trick in your code, I think, is to get
> the data back the user entered, and set the main program's global variables
> (to mimic the original program). I'm stuck with the original concept of the
> main code setting self.hourly_rate to the new value to, say, 15 in the
> Dialog setup that calls the Dialog GUI. That is, when the Dialog returns,
> the code must set self.hourly_rate to 15. I may not like that, but that's
> the way the author designed it. I do not want to rewrite lots of code
> because of it. So instead of the code after the return to the from Dialog
> being hard coded, I need to construct executable statements from the list
> above to do the job.

This is not a big change from the code I wrote. Instead of printing
the values, return a dict mapping names to values:
  return dict((name, widget.get()) for name, widget in self.widgets.items())

Then in the caller, use setattr() to set the attributes on self:
  for name, value in returned_values.items():
setattr(self, name, value)

Kent
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Wayne Watson]

Yes, you have the idea. Here's about the simplest summary I wrote to
another person that I can muster. It may clarify matters. The anumber
I'm referring to is in the 80 line version I posted to start this
thread.

A Simple Explanation (I hope) 
Consider some of the new
code I put into the original 2000 line program written by someone else.


    def SetConfigDictionary():

    config_var_list = [
    {'name':'gray_scale', 'value':True, 'type': BOO},
    #  {'name':'color', 'value':None, 'type':
INT},  # gray_scale, ambiguity
    {'name':'post_event_stack', 'value':False, 'type': BOO},
    {'name':'post_event_format',  'value':'Tiff 2', 'type':
STR},
    {'name':'show_real_time', 'value':False, 'type': BOO},
    {'name':'hourly_rate', 'value':12, 'type': INT},
    {'name':'slowdown', 'value':1, 'type': INT},
    {'name':'start_time', 'value':'18:00:00', 'type': TIM},
    {'name':'stop_time',  'value':'10:00:00', 'type': TIM},
                blah, blah, ...
                ]
Like the self.anumber = 150 one will find
in the original program self.hourly_rate = 12, but it's now replaced by
running through that conf_var_list, and forming from the entry there
something like:  setattr(self, varName,
varValue), where varName is "hourly_rate" and varValue is 12. That is,
the program code no longer contains the explicity, hard coded,
self.hourly_rate = 12. Eventually, all this info is used to initialize
the big dialog in the image I sent (See a later response to Alan). It
all works just fine. However,
what has temporaily stumped me is how to retrieve any data the user
enters without use of the hard coded control variable references. That
activity takes place after (in 80 line version) dialog =
Enter_Data_Dialog( self.master,
sdict ).  Actually, I think I know, but haven't had the time to work
out the details. 
===End of Simple=

It looks like your sample code code has the right idea, but the hang up
with the original code is getting entered values back to the main
program and available globally through it. The trick in your code, I
think, is to get the data back the user entered, and set the main
program's global variables (to mimic the original program). I'm stuck
with the original concept of the main code setting self.hourly_rate to
the new value to, say, 15 in the Dialog setup that calls the Dialog
GUI. That is, when the Dialog returns, the code must set
self.hourly_rate to 15. I may not like that, but that's the way the
author designed it. I do not want to rewrite lots of code because of
it. So instead of the code after the return to the from Dialog being
hard coded, I need to construct executable statements from the list
above to do the job. 

Kent Johnson wrote:

...

  
I've stayed out of this because I don't really understand what you are
trying to do. But I *think* what you are looking for is a data-driven
GUI. Rather than hard-coding a bunch of variable names and types, you
want to build a gui based on a description of the data.

Here is a program that might give you some ideas about how to abstract
your problem. I don't expect it to exactly (or even closely) do what
you want but maybe it will point you in a useful direction. The heart
of it is the initial classes, which abstract the creation of a gui and
retrieval of a typed value, and the 'values' list in class App, which
is the definition of the values to display and their types. The gui
can be extended with additional entry lines simply by adding more
entries to the values list.

Kent

from Tkinter import *

# These classes encapsulate creating a gui element and retrieving a
typed value from it
# The constructors create the elements, the get() methods return values

class TextWidget(object):
def __init__(self, master, label, row):
Label(master, text=label).grid(row=row, sticky=W)
self.entry = Entry(master)
self.entry.grid(row=row, column=1)

class StringWidget(TextWidget):
def get(self):
return self.entry.get()

class IntWidget(TextWidget):
def get(self):
# This will blow up if the entry is not a valid integer
# Better would be to validate or constrain the input
value = self.entry.get()
return int(value) if value else 0

class BoolWidget(object):
def __init__(self, master, label, row):
self.var = IntVar()
cb = Checkbutton(master, text=label, variable=self.var)
cb.grid(row=row, columnspan=2, sticky=W)

def get(self):
return bool(self.var.get())

class App:
def __init__(self, master):
# List of parameter name, parameter description, widget type
values = [
('name', 'Your name:', StringWidget),
('age', 'Your age:', IntWidget),
('subscribe', 'Send emails', BoolWidget),
]

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Kent Johnson]

On Tue, Mar 3, 2009 at 2:54 PM, Wayne Watson
 wrote:
> I see my post of yesterday, "Maintaining the Same Variable Type--Tkinter",
> went over like a lead balloon. :-)
> (Note though the Myth Busters TV series successfully built and flew a lead
> balloon.)
>
> Let's see if I can really simplify what I'm after. I've pulled the
> essentials out of the original larger program I'm trying to modify. 2000
> lines down to 80. I've only added a few lines of my own, and changed the
> menu and dialog content. Although I've heavily modified the original code to
> accept a config file, and set up variable to initialize the widgets, trying
> to bridge some code in the Enter_Data_Dialog and Set_Enter_Data objects
> control variable code is where the trouble lays for completing the
> modifications.
>
> The code below puts up a window with one menu and two submenus items,  Enter
> Data, and Exit. Select Enter Data and put in an integer number. It all works
> fine. Basically, what I want to do is eliminate code like
> dialog.anumberVar.get() and replace it by constructing the appropriate names
> for the config file. In this case, the config file might contain:
>     anumber = 123

I've stayed out of this because I don't really understand what you are
trying to do. But I *think* what you are looking for is a data-driven
GUI. Rather than hard-coding a bunch of variable names and types, you
want to build a gui based on a description of the data.

Here is a program that might give you some ideas about how to abstract
your problem. I don't expect it to exactly (or even closely) do what
you want but maybe it will point you in a useful direction. The heart
of it is the initial classes, which abstract the creation of a gui and
retrieval of a typed value, and the 'values' list in class App, which
is the definition of the values to display and their types. The gui
can be extended with additional entry lines simply by adding more
entries to the values list.

Kent

from Tkinter import *

# These classes encapsulate creating a gui element and retrieving a
typed value from it
# The constructors create the elements, the get() methods return values

class TextWidget(object):
def __init__(self, master, label, row):
Label(master, text=label).grid(row=row, sticky=W)
self.entry = Entry(master)
self.entry.grid(row=row, column=1)

class StringWidget(TextWidget):
def get(self):
return self.entry.get()

class IntWidget(TextWidget):
def get(self):
# This will blow up if the entry is not a valid integer
# Better would be to validate or constrain the input
value = self.entry.get()
return int(value) if value else 0

class BoolWidget(object):
def __init__(self, master, label, row):
self.var = IntVar()
cb = Checkbutton(master, text=label, variable=self.var)
cb.grid(row=row, columnspan=2, sticky=W)

def get(self):
return bool(self.var.get())

class App:
def __init__(self, master):
# List of parameter name, parameter description, widget type
values = [
('name', 'Your name:', StringWidget),
('age', 'Your age:', IntWidget),
('subscribe', 'Send emails', BoolWidget),
]

# Create the widgets
row = 0
self.widgets = {}
for name, desc, widget in values:
self.widgets[name] = widget(master, desc, row)
row += 1

# Button to print values
Button(master, text="Show", command=self.show).grid(row=row)

def show(self):
for name, widget in self.widgets.items():
print name, type(widget.get()), widget.get()


root = Tk()
app = App(root)
root.mainloop()
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Alan Gauld]

"Wayne Watson"  wrote


I'm not sure what normal is. Do you have an example,


Is this what you have in mind 
?

=start
from Tkinter import *
master = Tk()
e = Entry(master)
e.pack()
e.focus_set()

def callback():
   print e.get()

b = Button(master, text="get", width=10, command=callback)
b.pack()

mainloop()
end


Yes thats exactly what I had in mind.

This begs the question as to why one would use control variables at 
all?
From a light reading of the subject, it seems as though they may 
help

in certain circumstances of coupling.


Yes, although you can still do it by hand.

One special quality of a control variable is that it can be shared 
by a

number of different widgets, and the control variable can remember
all the widgets that are currently sharing it.


This is fairly rare in my experience but it would be handy. But OTOH
its sufficiently complex that I might prefer to make that complexity
explicit so that I remember its there!

HTH,

Alan G. 



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Wayne Watson]

Title: Signature.html




I have yet to really use Tkinter to put together any widgets, so I'm
not sure what normal is. Do you have an example, or could you construct
an example to replace the one in the 80 line program?  My plan is to
get this config interface working, and later to worry about
constructing new widgets.  

Is this what you have in mind
?
=start
from Tkinter import *
master = Tk()
e = Entry(master)
e.pack()
e.focus_set()

def callback():
    print e.get()

b = Button(master, text="get", width=10, command=callback)
b.pack()

mainloop()
end
This begs the question as to why one would use control variables at
all? From a light reading of the subject, it seems as though they may
help in certain circumstances of coupling.

>From Tkinter reference: a GUI for Python
One special quality of a control variable is
that it can be shared by a number of different widgets, and the control
variable can remember all the widgets that are currently sharing it.
This means, in particular, that if your program stores a value v into a
control variable c
with its c.set(v)
method, any widgets that are linked to that control variable are
automatically updated on the screen.. 

Alan Gauld wrote:

"Wayne Watson"  wrote
  There's another way?

  
  
Sure, just create normal Entry widgets and capture the input string and
convert/assign it as you would a string captured from raw_input() in a
console. No magic required.
  
  
Its slightly more code but I find the auto assignment of values to
variables catches me out sometimes so I prefer to keep it explicit.
  
  
Alan G.
  
  
___
  
Tutor maillist  -  Tutor@python.org
  
http://mail.python.org/mailman/listinfo/tutor
  
  


-- 


   Wayne Watson (Watson Adventures, Prop., Nevada City, CA)

 (121.01 Deg. W, 39.26 Deg. N) GMT-8 hr std. time)


“In mathematics you don't understand things. 
 You just get used to them.” -- John Von Neumann
(P.S. The same is true in life.)




Web Page: 



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Wayne Watson]

Title: Signature.html




No error messages. Just a clean finish. 

Alan Gauld wrote:

"Wayne Watson"  wrote
  
  
  One starts it by double clicking on the py
file. 
  
And just to be clear, it exits OK when you run it that way?
  
  
I would expect so since that's the normal way to run a Tkinter program.
IDLE is only intended to be a development tool not a runtime program.
  
  
   Nope. I just tried it. It works fine from
there. 
    Does that include running from the
command console? 
  
  
Alan G.
  
  
___
  
Tutor maillist  -  Tutor@python.org
  
http://mail.python.org/mailman/listinfo/tutor
  
  


-- 


   Wayne Watson (Watson Adventures, Prop., Nevada City, CA)

 (121.01 Deg. W, 39.26 Deg. N) GMT-8 hr std. time)


“In mathematics you don't understand things. 
 You just get used to them.” -- John Von Neumann
(P.S. The same is true in life.)




Web Page: 



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Alan Gauld]

"Wayne Watson"  wrote 

There's another way?


Sure, just create normal Entry widgets and capture 
the input string and convert/assign it as you would a 
string captured from raw_input() in a console. 
No magic required.


Its slightly more code but I find the auto assignment 
of values to variables catches me out sometimes so 
I prefer to keep it explicit.


Alan G.

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Alan Gauld]

"Wayne Watson"  wrote

One starts it by double clicking on the py file. 


And just to be clear, it exits OK when you run it that way?

I would expect so since that's the normal way to run 
a Tkinter program. IDLE is only intended to be a 
development tool not a runtime program.


 Nope. I just tried it. It works fine from there. 

Does that include running from the command console? 


Alan G.

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Wayne Watson]

Title: Signature.html




Memory malfunction. I've been using the program to add features so much
with IDLE my brain went IDLE. One starts it by double clicking on the
py file. It is possible some users might have drifted off into IDLE
though, but unlikely. 

Wayne Watson wrote:

  
Nope. I just tried it. It works fine from there. Interesting, as far as
I know, the author wanted us to run it from IDLE. That may explain some
other oddities.  I'll check with him. I'm quite sure in his user manual
he never talks about the command console.
  
Alan Gauld wrote:
  
"Wayne Watson" 
wrote 


BTW, the Quit function is original but doesn't kill the window when
Quit is used. 


Does that include running from the command console? 
Is this another IDLE/Tkinter issue maybe? 

Alan G. 

___ 
Tutor maillist  -  Tutor@python.org

http://mail.python.org/mailman/listinfo/tutor


  
  
  -- 
  
  
 Wayne Watson (Watson Adventures, Prop., Nevada City, CA)

 (121.01 Deg. W, 39.26 Deg. N) GMT-8 hr std. time)


“In mathematics you don't understand things. 
 You just get used to them.” -- John Von Neumann
(P.S. The same is true in life.)

  
  
  
Web Page: 
  
  

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor
  


-- 

Signature.html
   Wayne Watson (Watson Adventures, Prop., Nevada City, CA)

 (121.01 Deg. W, 39.26 Deg. N) GMT-8 hr std. time)


“In mathematics you don't understand things. 
 You just get used to them.” -- John Von Neumann
(P.S. The same is true in life.)




Web Page: 




___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Wayne Watson]

Title: Signature.html




There's another way?

Alan Gauld wrote:

"Wayne Watson"  wrote
  
  
  Note though the use of control variables like
IntVar, etc. 
  
FWIW. Personally I never use those "convenience" features of Tk. I
prefer to explicitly set and get them myself.
  
  
Alan G
  
  
___
  
Tutor maillist  -  Tutor@python.org
  
http://mail.python.org/mailman/listinfo/tutor
  
  


-- 


   Wayne Watson (Watson Adventures, Prop., Nevada City, CA)

 (121.01 Deg. W, 39.26 Deg. N) GMT-8 hr std. time)


“In mathematics you don't understand things. 
 You just get used to them.” -- John Von Neumann
(P.S. The same is true in life.)




Web Page: 



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Wayne Watson]

Title: Signature.html




Nope. I just tried it. It works fine from there. Interesting, as far as
I know, the author wanted us to run it from IDLE. That may explain some
other oddities.  I'll check with him. I'm quite sure in his user manual
he never talks about the command console.

Alan Gauld wrote:

"Wayne Watson"  wrote
  
  
  
BTW, the Quit function is original but doesn't kill the window when
Quit is used.

  
  
Does that include running from the command console?
  
Is this another IDLE/Tkinter issue maybe?
  
  
Alan G. 
  
___
  
Tutor maillist  -  Tutor@python.org
  
http://mail.python.org/mailman/listinfo/tutor
  
  


-- 


   Wayne Watson (Watson Adventures, Prop., Nevada City, CA)

 (121.01 Deg. W, 39.26 Deg. N) GMT-8 hr std. time)


“In mathematics you don't understand things. 
 You just get used to them.” -- John Von Neumann
(P.S. The same is true in life.)




Web Page: 



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Alan Gauld]

"Wayne Watson"  wrote

Note though the use of control variables like IntVar, etc. 


FWIW. Personally I never use those "convenience" features of Tk. 
I prefer to explicitly set and get them myself.


Alan G

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Wayne Watson]

Title: Signature.html




An interesting thought, I'll ponder it. Note though the use of control
variables like IntVar, etc. In the 2000 line original version of all
the program, integers, dates, and booleans are in use for the
simplified widget I produced. Note to the use of self.anumberVar.set.
(I think I mixed this up in my first response to you with StringVar.)



Alan Gauld wrote:

"Wayne Watson"  wrote
  
  
  Comments?

  
  
  class IntVar_GUI:

  
  
I just noticed the name of the class. This kind of implies that you are
  
intending writing GUIs for each data type? That shouldn't be necessary
  
since the inputs will be strings in each case. You only need to call
  
the appropriate conversion function when you pull the data back
  
from the input dialog.
  
  
The exception might be if you want a different inpuit mechanism - like
  
a drop down list or radio button. In that case the number of GUIs you
  
write is determined by the number of input mechanisms used not
  
the number of data types... Hopefully the mechanism list is shorter
  
than the data type list!
  
  
Just a thought.
  
  
  


-- 


   Wayne Watson (Watson Adventures, Prop., Nevada City, CA)

 (121.01 Deg. W, 39.26 Deg. N) GMT-8 hr std. time)


“In mathematics you don't understand things. 
 You just get used to them.” -- John Von Neumann
(P.S. The same is true in life.)




Web Page: 



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Wayne Watson]

Title: Signature.html




I browsed through your response, and it looks like this may be doable.
I'll look this over more carefully this evening. It seems as though
someone should have had a similar problem in the past. The Tkinter
interface seems to be a, I hope, temporary logjam. I don't recall
XWindow widgets needing the control variable notion.  

I've already overhauled a lot of the code, and names, initial values
are in list/dictionary form. That all works, but I've just started
considering how all this can be carried into the two objects mentioned
here.  Note too that I need to take care of things like self.anumberVar
= StringVar().  

I noted the eval too. Not my code. When the dust clears, I'll look at
it. The program is not for general distribution. 

As an aside, I've finally latched on to the idea of attributes in
Python terms.  The idea seems local to Python. 

Alan Gauld wrote:
"Wayne
Watson"  wrote
  
  
  see my post of yesterday, "Maintaining the
Same Variable Type--Tkinter",

went over like a lead balloon. :-)

  
  
Yeah, I had no idea what you meant :-)
  
  
   I've heavily modified the original code to
accept a config file,

and set up variable to initialize the widgets, trying to bridge

some code in the Enter_Data_Dialog and Set_Enter_Data

objects control variable code is where the trouble lays

  
  
Yep, and part of it is the attempt to create variables dynamically.
  
It's so much easier if you use a dictionary or a list of name,value
  
tuples.
  
  
  The code below puts up a window with one menu
and two

submenus items,  Enter Data, and Exit. Select Enter Data

and put in an integer number. It all works fine.

  
  
It works with hard coded variable names. Trying to use dynamic
  
variable names will be much trickier!
  
  
  Basically, what I want to do is eliminate
code like

dialog.anumberVar.get() and replace it by constructing the

appropriate names for the config file.

  
  
If you used a list of variables you could replace it with
  
  
self.varList[0][1] = dialog.myVar.get()
  
  
In this case, the config file might contain:
  
     anumber = 123

  
  
and you store that as
  
varList.append( (varname, varValue) )
  
  
If there is only one variable at a time you could just use the
  
tuple of course:
  
  
self.myVar = (varname, varValue)
  
  
Then the dialog return becomes:
  
  
self.myVar[1] = dialog.myVar.get()
  
  
You also need to make the dialog smart enough to read
  
the name of the variable (myVar[0]) and set the label
  
accordingly... If you use dynamic variables you will need
  
to pass in the variable name and then use getattr to
  
retrieve the value. Or pass name and value - which
  
sounds a lot like a tuple?
  
  
The problem with trying to create actual variables is that
  
the rest of yor code must become psychic (or very complex)
  
to figure out what variable to use. Or you write a lott of
  
near identical code to handle every possible variable name!
  
  
  BTW, the Quit function is original but
doesn't kill the window

when Quit is used. What fixes that?

  
  
Brute force you can use sys.exit()!
  
  
But more normally you can use what you have used,
  
so I'm not sure why its not working!
  
  
  For more bonus points, it seems as though the
try statement

in the dialog should really bring up an "Error" dialog saying

something is wrong, when an invalid entry occurs.

  
  
You can use the standard 'showerror' or 'showwarning' dialogs
  
for that:
  
  
http://www.pythonware.com/library/tkinter/introduction/standard-dialogs.htm
  
  
Finally I note the use of eval() to evaluate the user input. That is
bad,
  
bad bad. And looks like there is no need since after eval'ing you
  
then use int(). You should be able to use int() directly on the input
  
and handle any ValueError exceptions etc to catch bad input.
  
  
HTH,
  
  
  


-- 


   Wayne Watson (Watson Adventures, Prop., Nevada City, CA)

 (121.01 Deg. W, 39.26 Deg. N) GMT-8 hr std. time)


“In mathematics you don't understand things. 
 You just get used to them.” -- John Von Neumann
(P.S. The same is true in life.)




Web Page: 




___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Alan Gauld]

"Wayne Watson"  wrote


Comments?



class IntVar_GUI:


I just noticed the name of the class. This kind of implies that you 
are

intending writing GUIs for each data type? That shouldn't be necessary
since the inputs will be strings in each case. You only need to call
the appropriate conversion function when you pull the data back
from the input dialog.

The exception might be if you want a different inpuit mechanism - like
a drop down list or radio button. In that case the number of GUIs you
write is determined by the number of input mechanisms used not
the number of data types... Hopefully the mechanism list is shorter
than the data type list!

Just a thought.


--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/ 



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Alan Gauld]

destroy() took care of it, but I wonder what advantage there was to 
Quit()?


destroy destroys the widget, quit exits the main loop.

destroying the top level widget usually causes the mainloop; to die 
too

so the end result is the same (provided you have no non-modal dialogs
open?).

HTH,

Alan G. 



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Alan Gauld]

"Wayne Watson"  wrote



BTW, the Quit function is original but doesn't kill the window when 
Quit is used.


Does that include running from the command console?
Is this another IDLE/Tkinter issue maybe?

Alan G. 



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Alan Gauld]

"Wayne Watson"  wrote

see my post of yesterday, "Maintaining the Same Variable 
Type--Tkinter",

went over like a lead balloon. :-)


Yeah, I had no idea what you meant :-)


 I've heavily modified the original code to accept a config file,
and set up variable to initialize the widgets, trying to bridge
some code in the Enter_Data_Dialog and Set_Enter_Data
objects control variable code is where the trouble lays


Yep, and part of it is the attempt to create variables dynamically.
It's so much easier if you use a dictionary or a list of name,value
tuples.


The code below puts up a window with one menu and two
submenus items,  Enter Data, and Exit. Select Enter Data
and put in an integer number. It all works fine.


It works with hard coded variable names. Trying to use dynamic
variable names will be much trickier!


Basically, what I want to do is eliminate code like
dialog.anumberVar.get() and replace it by constructing the
appropriate names for the config file.


If you used a list of variables you could replace it with

self.varList[0][1] = dialog.myVar.get()

In this case, the config file might contain:

   anumber = 123


and you store that as
varList.append( (varname, varValue) )

If there is only one variable at a time you could just use the
tuple of course:

self.myVar = (varname, varValue)

Then the dialog return becomes:

self.myVar[1] = dialog.myVar.get()

You also need to make the dialog smart enough to read
the name of the variable (myVar[0]) and set the label
accordingly... If you use dynamic variables you will need
to pass in the variable name and then use getattr to
retrieve the value. Or pass name and value - which
sounds a lot like a tuple?

The problem with trying to create actual variables is that
the rest of yor code must become psychic (or very complex)
to figure out what variable to use. Or you write a lott of
near identical code to handle every possible variable name!


BTW, the Quit function is original but doesn't kill the window
when Quit is used. What fixes that?


Brute force you can use sys.exit()!

But more normally you can use what you have used,
so I'm not sure why its not working!


For more bonus points, it seems as though the try statement
in the dialog should really bring up an "Error" dialog saying
something is wrong, when an invalid entry occurs.


You can use the standard 'showerror' or 'showwarning' dialogs
for that:

http://www.pythonware.com/library/tkinter/introduction/standard-dialogs.htm

Finally I note the use of eval() to evaluate the user input. That is 
bad,

bad bad. And looks like there is no need since after eval'ing you
then use int(). You should be able to use int() directly on the input
and handle any ValueError exceptions etc to catch bad input.

HTH,


--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/


___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[Wayne Watson]

Title: Signature.html




WW, 
    good. Thanks. 
destroy() took care of it, but I wonder what advantage there was to
Quit()?
WW

W W wrote:

  On Tue, Mar 3, 2009 at 1:54 PM, Wayne Watson
 wrote:
  
  

BTW, the Quit function is original but doesn't kill the window when Quit is
used. What fixes that? For more bonus points, it seems as though the try
statement in the dialog should really bring up an "Error" dialog saying
something is wrong, when an invalid entry occurs. No need to construct an
error dialog for me, but I'd be curious how it might be handled.


  
  


For the error dialog you can easily use tkMessageBox:

just import tkMessageBox and then use this:

In [2]: tkMessageBox.showerror('Some Error', 'An Error occurred!')
Out[2]: 'ok'

If you're expecting a specific error you can use

try:
#some statements
except SpecificError:
#Handle the error

In this case (at least the block I looked at) it's just printing to
the command line. You can handle it using any one of the message boxes
or creating your own.

  
  
    def Quit(self):
    self.running = False
    self.master.quit()


  
  
You could also try self.master.destroy()

when I tried:

from Tkinter import *
root = Tk()
root.quit()

in an ipython session. It didn't close my root window but the destroy
method did.

HTH,
Wayne

  


-- 


   Wayne Watson (Watson Adventures, Prop., Nevada City, CA)

 (121.01 Deg. W, 39.26 Deg. N) GMT-8 hr std. time)


“In mathematics you don't understand things. 
 You just get used to them.” -- John Von Neumann
(P.S. The same is true in life.)




Web Page: 




___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Configuration File, Tkinter, IntVars--Manufacturing Variables

[W W]

On Tue, Mar 3, 2009 at 1:54 PM, Wayne Watson
 wrote:
>
> BTW, the Quit function is original but doesn't kill the window when Quit is
> used. What fixes that? For more bonus points, it seems as though the try
> statement in the dialog should really bring up an "Error" dialog saying
> something is wrong, when an invalid entry occurs. No need to construct an
> error dialog for me, but I'd be curious how it might be handled.
>



For the error dialog you can easily use tkMessageBox:

just import tkMessageBox and then use this:

In [2]: tkMessageBox.showerror('Some Error', 'An Error occurred!')
Out[2]: 'ok'

If you're expecting a specific error you can use

try:
#some statements
except SpecificError:
#Handle the error

In this case (at least the block I looked at) it's just printing to
the command line. You can handle it using any one of the message boxes
or creating your own.

>     def Quit(self):
>     self.running = False
>     self.master.quit()
>

You could also try self.master.destroy()

when I tried:

from Tkinter import *
root = Tk()
root.quit()

in an ipython session. It didn't close my root window but the destroy
method did.

HTH,
Wayne
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor