I've tryied to build a Tkinter form in some universal method, but I got a problem.
First look at my Method's code..
def BuildWindow(title, args, icon):
Window = Tk()
Window.title(title)
Window.wm_iconbitmap(icon)
for item in args:
item.master = Window
item.pack()
Window.mainloop()
When I'm trying to run this code, I'm getting two differnet Windows: one with the arguments from the list "args", and the other with the title and the icon only..
I want all the parameters to appear in the same Form..
can someone help me to solve it?
Thanks..
Based on the code presented, I must assume that args contains a list of widgets that have already been created. If they've already been created, an instance of Tk must already exist. Since this function is also creating in instance of Tk, that's why you get two windows.
You must create only a single instance of Tk for your entire application.
Related
I am trying to implement a little application that logs in a user and the user after log in can add/update/delete contents to/of a textfile. Here's a rough sketch of the code I have so far:
class admin():
def __init__(self):
self.app = Tk()
.
self.name=StringVar()
update = Button(self.app,....,command=self.update)
.
.
.
def update():
#Function to take different entries using Entry widget of tkinter in another window
anotherapp = Tk()
nameentry = Entry(anotherapp,textvariable = self.name)
submitbutton = Button(anotherapp,....,command=submit)
.
.
def submit():
#Opens a file and adds entries to a textfile.
namevar = self.name.get()
# code to append to file
To explain the above, I have a class admin. Creating an instance of this class would open a window with buttons that say create, update, delete and so on. On clicking one of the buttons, the respective functions (defined in the same class) would be called (I use lambda: in case the function has arguments, but so far, it doesn't).
So in the code I've mentioned, say I click on the Update button, it should call the update function which opens another window and takes the text that has to be updated in the text file (via the Entry widget). So according to the code it'll update the value of name. On clicking submit, the function submit uses .get() to get the string value of name, and appends it to the text file.
The code executes with no error but it DOES NOT read the input from the user. Blank lines get appended to my textfile when I click on the submit button.
Now I don't understand why this isn't working. The name variable is defined in init and can be updated by the functions of the same class. I have tried a lot of things to make this work, including adding parameters in the button commands, defining name elsewhere, etc. Even though I've solved the error, I get the same result: the file gets appended with blank lines. I've also tried to make name a class variable but that doesn't work since it is declared using StringVar() which needs it to be part of a tkinter window. I think I've also tried nesting submit function inside the update function, but I don't know why that didn't work out or if I hadn't implemented it correctly.
I don't know if it has to do with the working of tkinter's StringVar() and .get() function.
I can't think of any other way to implement the situation I have at hand. I am open to taking suggestions on changing the structure of the code, as long as it is not something major major and manages to achieve the functionality that I've described.
I am sorry if I've missed something basic, cause I've only started trying out OOP in python recently. And thanks in advance for any help.
I am a beginner and I am making a login system (just for practicing).
I'm using tkinter to develop a simple UI. The thing is that when I call a second root (sign_in root) with a button from another root (main_screen), and I try to get some values typed in entry with StringVars assigned to them, they return just an empty string ""
def main_screen():
root=Tk()
user=StringVar()
pas=StringVar()
btn2=Button(root,text='Sign-In',command=sign_in_screen)
btn2.place(x=125,y=160)
root.mainloop()
def sign_in_screen():
root1=Tk()
newuser=StringVar()
newpas=StringVar()
ent3=Entry(root1,width=28,textvariable=newuser)
ent3.place(x=100,y=50)
ent4=Entry(root1,width=28,textvariable=newpas,show="*")
ent4.place(x=100,y=100)
btn3=Button(root1,text='Sign-In',command=lambda:register(newuser.get(), newpas.get()))
btn3.place(x=50,y=160)
root1.mainloop()
main_screen()
Having multiple instances of Tk become hideously complicated because each one creates a separate tcl interpreter. This causes weird effects like what you see here. It's you almost always want to use the Toplevel widget.
Every source of documentation I've been able to find for this say that by calling itemconfig without any arguments will return a list of possible attributes that can be edited. I tried to do this with the following code:
import tkinter
from tkinter import *
master = Tk()
w = Canvas(master, width=200, height=100)
w.pack()
print(w.itemconfig('bg'))
...And it only returned an empty dictionary (it throws an error when I put in zero arguments, and no other arguments I could think of have given me results, except for actually using the function as intented)
I find it rather silly that nobody has written down all of the attributes that itemconfig can use (or if they have, I can't find it); being able to actually retrieve attributes would be nice, but far more than that, I'd like a complete list to be written down, since I can't find it anywhere.
The following code exhibits a problem I do not understand:
from Tkinter import *
root = Tk()
cheese_var = IntVar()
parrot_var = IntVar(value=1)
check_menu = Menu(tearoff=0)
check_menu.add_checkbutton(label="Cheese", variable=cheese_var)
check_menu.add_checkbutton(label="Parrot", variable=parrot_var)
count = 0
class Top():
def __init__(self):
global count
count += 1
self.tl = Toplevel(root)
Label(self.tl, text="Window " + str(count)).pack()
self.mb = Menubutton(self.tl, text="Push Me", bg='pink')
self.menu = Menu(self.mb, tearoff=0)
self.menu.add_cascade(label="Choices", menu=check_menu)
self.menu.add_command(label="New Window", command=new_top)
self.mb.config(menu=self.menu)
self.mb.pack()
def new_top():
Top()
Top()
root.mainloop()
The menu brought up by the menu button in the created top level window initially behaves as expected. Clicking on the New Window command there creates a new such window, which also behaves as expected. Indeed, as long as you keep creating new top level windows, everything continues to work as expected. However, once you delete (close) any one of those windows, then, in a subsequently created new window, the Choices cascade on the new menu is not functional. (It is still OK in the windows created before the closing of one.)
The situation in which I initially encountered this symptom was much more complex, but I was able to simplify it down to the above example which exhibits the issue. I have discovered that I can avoid the problem by having each instance of Top create its own check_menu as an attribute; but I do not understand why this should be necessary. Please point me the way if there is one to avoid the problem without such replication of a cascade menu used in multiple windows.
Unfortunately, I don't think it is possible to do what you want. I'll try to explain as best as I can.
When you first run the script, check_menu is created and works fine for the first window. As you create more windows, check_menu is simply shared between them. However, when you close one of them, check_menu (and everything under it) is destroyed. So, when you create a new window after that, check_menu no longer exists and it doesn't show.
However, the script doesn't throw an error because, for some reason, Tkinter allows you to assign menus to things that aren't menus. Believe it or not, none of the following code:
self.menu.add_cascade(label="Choices", menu=None)
self.menu.add_cascade(label="Choices", menu=1)
self.menu.add_cascade(label="Choices", menu="")
will break the script. Each line simply does nothing but create an empty cascade "Choices".
That is basically what is happening. After closing one window, check_menu and everything under it is destroyed. Yet, Tkinter doesn't throw an error but instead assigns a menu to something that is no longer a menu (as far as what it is assigning the menu to, I believe it is using the old instance of check_menu, which was destroyed).
To solve this problem, recreate check_menu and everything under it each time you call Top. In other words, put the code for check_menu (and its options) in the __init__ method of Top. That way, each time Top is called, check_menu will exist.
Hope this helps (and that I explained it sufficiently :)
I'm using Python 2.7, if that matters.
Here is a code I wrote for fun:
def p():
root = Tk()
def cmd(event):
print int(slider.get())
slider = Scale(root, orient = "horizontal", from_ = 0, to = 100, command = cmd, state = "disabled")
def enable():
slider.config(state = "active")
b = Button(root, text = "Enable slider", command = enable)
b.grid()
slider.grid(row = 1)
root.mainloop()
For this code, I'm wondering why the command for Scale requires an event, but that for Button does not. It seems that for some widgets in Tkinter their commands need to have "event" as an argument, and other don't. Why? How to distinguish them?
Thanks.
Scale doesn't take an event. It takes the current value. Try this:
def cmd(value):
print int(value)
If you read the Tk tutorial, it explains this:
There is a "command" configuration option, which lets you specify a script to call whenever the scale is changed. Tk will automatically append the current value of the scale as a parameter each time it invokes this script (we saw a similar thing with extra parameters being added to scrollbar callbacks and those on the widgets they scroll).
Or, if you read the actual manpage:
Specifies the prefix of a Tcl command to invoke whenever the scale's value is changed via a widget command. The actual command consists of this option followed by a space and a real number indicating the new value of the scale.
In other words, the way to distinguish them is to read the docs. Unfortunately, the Tkinter docs aren't all that complete—they assume you already know how Tcl/Tk works, or how to look it up yourself. That's why the docs start off with a list of links to sources of Tk documentation.
If you prefer to figure it out by trial and error, it's not that hard to see what gets passed:
def cmd(*args):
print('Scale command says {}'.format(args))
def enable(*args):
print('Button command says {}'.format(args))
But this won't always tell you everything you need to know; there are other callbacks whose arguments aren't obvious enough to figure out without a lot more work, or which are configurable (e.g., the validate callback).
When you set up a binding (with the bind) command, the callback always is given an event object.
When you are working with the command attribute of a widget, different widgets send different information to the command. In this case they never send an event, but they will send other types of data. This is simply due to the fact different commands do different things.
The scale widget is no different -- you claim the callback takes an event, but that is false. It is passed the current value of the scale widget rather than an event object.