[issue41176] revise Tkinter mainloop dispatching flag behavior

[E. Paine]

E. Paine  added the comment:

Apologies, it is not waiting for the tcl queue and instead the call waits 
indefinitely for `Tcl_ConditionWait` (tkinter adds it to the queue and then 
waits for the command to finish executing). Do we need some mechanism to alert 
people after a second, for example, that the thread is waiting for the mainloop 
to come up?

--
nosy: +taleinat

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41176] revise Tkinter mainloop dispatching flag behavior

[E. Paine]

E. Paine  added the comment:

I have just finished reviewing the proposed PR, and am happy with the content. 
During the process of developing the PR, we established that the behaviour that 
should be deprecated is the error after a second of waiting in a thread. 
Instead, on `WaitForMainloop` removal, we should pass straight through and use 
the tcl queue to wait for mainloop.

@Serhiy, is waiting for the tcl queue acceptable behaviour? It seemed to behave 
correctly during my tests and if it is acceptable, both me and Richard would 
really appreciate your review of the PR.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41176] revise Tkinter mainloop dispatching flag behavior

[Richard Sheridan]

Richard Sheridan  added the comment:

I'm planning to write the long-awaited Tkinter Internals section of the docs. 
(https://github.com/python/cpython/blame/master/Doc/library/tk.rst#L48) I've 
spent too much time at this point to let it all go down the memory hole. 
Unfortunately, I don't know how ALL of the internals work. Is there someone 
else we could add to nosy that might be interested in writing some subsections?

Also, should this extended docs contribution be a new issue or rolled in with 
this one? Much abbreviated documentation of the new methods in this PR could be 
added to tkinter.rst. The new docs issue would be dependent on this issue since 
I won't be able to complete the docs until we have finished discussing what the 
future behavior of threads waiting for `dispatching` will be (error & poll vs 
Tcl_ConditionWait).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41176] revise Tkinter mainloop dispatching flag behavior

[Richard Sheridan]

Richard Sheridan  added the comment:

I'd like to consider one more possibility for future behavior that sort of came 
to mind while discussing the PR. In current behavior, it is possible to use 
`willdispatch` to trick `WaitForMainloop` into letting a thread pass through 
the timeout, where it will eventually wait on a `Tcl_ConditionWait` in 
`Tkapp_ThreadSend`. 

This could be very efficient default behavior, since no polling is required; 
the thread just goes when the loop comes up. Is it possible to make this a 
well-documented feature and default behavior of tkinter? Or would it be too 
surprising for new and existing users? It would be important to make sure that 
threads aren't silently getting lost in old programs and new users can figure 
out they need to call `mainloop`, `doonevent`, or `update` when not on the REPL 
or the thread will hang.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41176] revise Tkinter mainloop dispatching flag behavior

[Richard Sheridan]

Change by Richard Sheridan :


--
keywords: +patch
pull_requests: +20448
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21299

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41176] revise Tkinter mainloop dispatching flag behavior

[Richard Sheridan]

Richard Sheridan  added the comment:

Removing `WaitForMainloop` would surely break some existing programs, but
that's why I suggested deprecation instead of just removing it suddenly. We
could issue a RuntimeWarning if `WaitForMainloop` actually waits and tell
the client to take responsibility for the race condition they created.
(They may have no idea! What if their delay unexpectedly increases to 1.2
seconds?) Whether or not waiting gets deprecated, it would make sense to
make the sleep behavior configurable instead of hardcoded. I'll include
something along those lines in my PR.

On Wed, Jul 1, 2020 at 6:15 AM E. Paine  wrote:

>
> E. Paine  added the comment:
>
> I agree it would be helpful to expose an explicit way of telling if the
> mainloop was running but am not sure about removing `WaitForMainloop` as it
> could very easily break existing programs.
>
> If a program executes a tkinter method in a thread before the mainloop is
> executed, the method will wait because of the call to `WaitForMainloop`. In
> the example script this is done deliberately to demonstrate the behaviour
> but could be done accidentally if the main thread has to do something else
> before the mainloop (and after the thread has been created).
>
> I think the changes (whatever is concluded we should do) would be
> considered an 'enhancement', which would not be backported to 3.9 and
> before (I believe 'behaviour' is generally used for logic errors).
>
> I am very willing to help review a PR, however the people you really need
> to convince are Serhiy and/or Guilherme (I have added them to the nosy).
>
> --
> nosy: +epaine, gpolo, serhiy.storchaka
> versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
> Added file: https://bugs.python.org/file49283/waitmainloop.py
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41176] revise Tkinter mainloop dispatching flag behavior

[E. Paine]

E. Paine  added the comment:

I agree it would be helpful to expose an explicit way of telling if the 
mainloop was running but am not sure about removing `WaitForMainloop` as it 
could very easily break existing programs.

If a program executes a tkinter method in a thread before the mainloop is 
executed, the method will wait because of the call to `WaitForMainloop`. In the 
example script this is done deliberately to demonstrate the behaviour but could 
be done accidentally if the main thread has to do something else before the 
mainloop (and after the thread has been created).

I think the changes (whatever is concluded we should do) would be considered an 
'enhancement', which would not be backported to 3.9 and before (I believe 
'behaviour' is generally used for logic errors).

I am very willing to help review a PR, however the people you really need to 
convince are Serhiy and/or Guilherme (I have added them to the nosy).

--
nosy: +epaine, gpolo, serhiy.storchaka
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49283/waitmainloop.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41176] revise Tkinter mainloop dispatching flag behavior

[Richard Sheridan]

New submission from Richard Sheridan :

This could also be considered a "behavior" type issue.

`TkappObject` has a member `dispatching` that could usefully be exposed by a 
very simple read-only method for users to determine at runtime if the tkinter 
mainloop is running. Matplotlib and I'm sure other packages rely on fragile 
hacks 
(https://github.com/matplotlib/matplotlib/blob/a68562aa230e5895136120f5073dd01f124d728d/lib/matplotlib/cbook/__init__.py#L65-L71)
 to determine this state. I ran into this in 
https://github.com/matplotlib/matplotlib/pull/17802. All these projects would 
be more reliable with a new "dispatching()" method on the TkappObject, 
tkinter.Misc objects, and possibly the tkinter module itself.

Internally, `dispatching` is used to, yes, determine if the mainloop is 
running. However, this determination is always done within the 
`WaitForMainloop` function 
(https://github.com/python/cpython/blob/bd4a3f21454a6012f4353e2255837561fc9f0e6a/Modules/_tkinter.c#L363-L380),
 which waits up to 1 second for the mainloop to come up. Apparently, this 
function allows a thread to implicitly wait for the loop to come up by calling 
any `TkappObject` method. This is a bad design choice in my opinion, because if 
client code wants to start immediately and the loop is not started by mistake, 
there will be a meaningless, hard-to-diagnose delay of one second before 
crashing. Instead, if some client code in a thread needs to wait for the 
mainloop to run, it should explicitly poll `dispatching()` on its own. This 
waiting behavior should be deprecated and, after a deprecation cycle perhaps, 
all `WaitForMainloop()` statements should be converted to inline 
`self->dispatching`.

The correctness of the `dispatching` flag is dampened by the currently 
existing, undocumented `willdispatch` method which simply arbitrarily sets the 
`dispatching` to 1. It seems `willdispatch` was added 18 years ago to 
circumvent a bug building pydoc caused by `WaitForMainloop` not waiting long 
enough, as it tricks `WaitForMainloop` into... not waiting for the mainloop. 
This was in my opinion a bad choice in comparison to adding a dispatching flag: 
again, if some thread needs to wait for the mainloop, it should poll 
`dispatching()`, and avoid adding spurious 1 second waits. `willdispatch` 
currently has no references in CPython and most GitHub references are to 
Pycharm stubs for the CPython method. It should be deprecated and removed to 
preserve the correctness of `dispatching`.

Happy to make a PR about this, except I don't understand clinic at all, nor the 
specifics of deprecation cycles in CPython.

--
components: Tkinter
messages: 372722
nosy: Richard Sheridan
priority: normal
severity: normal
status: open
title: revise Tkinter mainloop dispatching flag behavior
type: enhancement
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 
<https://bugs.python.org/issue41176>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27939] Tkinter mainloop raises when setting the value of ttk.LabeledScale

[Donald Stufft]

Changes by Donald Stufft :


--
pull_requests: +1005

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27939] Tkinter mainloop raises when setting the value of ttk.LabeledScale

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27939] Tkinter mainloop raises when setting the value of ttk.LabeledScale

[Roundup Robot]

Roundup Robot added the comment:

New changeset 394b2b4da150 by Serhiy Storchaka in branch '3.5':
Issue #27939: Fixed bugs in tkinter.ttk.LabeledScale and tkinter.Scale caused
https://hg.python.org/cpython/rev/394b2b4da150

New changeset 91884d043fdc by Serhiy Storchaka in branch '3.6':
Issue #27939: Fixed bugs in tkinter.ttk.LabeledScale and tkinter.Scale caused
https://hg.python.org/cpython/rev/91884d043fdc

New changeset 9e3931aa1ff0 by Serhiy Storchaka in branch 'default':
Issue #27939: Fixed bugs in tkinter.ttk.LabeledScale and tkinter.Scale caused
https://hg.python.org/cpython/rev/9e3931aa1ff0

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27939] Tkinter mainloop raises when setting the value of ttk.LabeledScale

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This is caused by replacing int() by self._tk.getint() in IntVar.get() 
(issue23880). But the failure can be reproduced even in 3.4 if set 
tk.wantobjects = 0 before creating root widget.

One way is making getint() accepting floats. This fizes original example, but 
doesn't solve the issue for tk.wantobjects = 0.

Other way is making IntVar.get() falling back to integer part of getdouble(). 
This fixes the example in both modes. Proposed patch goes this way.

--
assignee:  -> serhiy.storchaka
keywords: +patch
stage: needs patch -> patch review
versions: +Python 3.7
Added file: http://bugs.python.org/file45203/tkinter_intvar_float_value.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27939] Tkinter mainloop raises when setting the value of ttk.LabeledScale

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
nosy: +serhiy.storchaka
stage:  -> needs patch
type: crash -> behavior
versions: +Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27939] Tkinter mainloop raises when setting the value of ttk.LabeledScale

[Goyo]

New submission from Goyo:

Calling mainloop after setting the value of a ttk.LabeledScale raises an error. 
The same happens if the value is set after entering the mainloop.

Does not affect python 3.4.3. Does not affect ttk.Scale. No error is raised if 
you do not call mainloop.


import tkinter as tk
import tkinter.ttk as ttk
root = tk.Tk()
w = ttk.LabeledScale(root)
w.pack()
w.scale.set(1)
root.mainloop()

Traceback (most recent call last):
  File 
"d:\users\u938001\AppData\Local\Programs\Python\Python35-32\lib\tkinter\__init__.py",
 line 1550, in __call__
return self.func(*args)
  File 
"d:\users\u938001\AppData\Local\Programs\Python\Python35-32\lib\tkinter\ttk.py",
 line 1540, in _adjust
newval = self._variable.get()
  File 
"d:\users\u938001\AppData\Local\Programs\Python\Python35-32\lib\tkinter\__init__.py",
 line 355, in get
return self._tk.getint(self._tk.globalgetvar(self._name))
TypeError: getint() argument must be str, not float

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "itcomp.py", line 8, in 
root.mainloop()
  File 
"d:\users\u938001\AppData\Local\Programs\Python\Python35-32\lib\tkinter\__init__.py",
 line 1131, in mainloop
self.tk.mainloop(n)
  File 
"d:\users\u938001\AppData\Local\Programs\Python\Python35-32\lib\tkinter\__init__.py",
 line 1554, in __call__
self.widget._report_exception()
AttributeError: 'IntVar' object has no attribute '_report_exception'

--
components: Tkinter
messages: 274223
nosy: goyodiaz
priority: normal
severity: normal
status: open
title: Tkinter mainloop raises when setting the value of ttk.LabeledScale
type: crash
versions: Python 3.5

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27939>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: exit from Tkinter mainloop Python 2.7

[Rick Johnson]

On Friday, March 4, 2016 at 3:50:43 PM UTC-6, kevin...@gmail.com wrote:
> Thanks for your attention to this matter.
> My code now look like this: [...]

All of the help offered in this thread ignores the elephant
in the room. What are you trying to achieve here Kevin? To
me, this looks like some sort of dialog, but if it is a
dialog, the whole design is a miserable failure. And why in
the hell would you call the w.quit() method when the user
presses a "continue" button? Do you realize that the quit
method does not "close the dialog" (if you can call this a
dialog), no, but simply instructs Tkinter to stop processing
events? Once a user clicks your "continue" button, he can no
longer interact with the GUI, and the user is left in a
state of befuddlement.

Those who've attempted to help you have suggested that you
utilize the quit method in your "continue button callback"
so that the widgets will stay alive long enough for you to
fetch the value, but that is horrible advice. Trust me, the
quit method is not something you want to use unless you know
what you're doing. It's should never be used in daily
coding, and only in very specific advanced circumstances.

The destroy method that you utilized initially *IS* the
correct course of action here. You see, your interface is
not a failure because of the destroy method, no, it is a
failure because you failed to (1) fetch the values in the
button callback BEFORE the widgets are destroyed, and (2)
You failed to store those values somewhere that will be
persistent after the function returns. But even if you
followed both of these suggestions, you design is flawed.

If you want to create a proper "dialog interface", the key
is not to use the "quit" method, but to follow these simple
design rules:

  (1) Present the user with a "focused window" that contains
  "form" filled with "input fields" that will facilitate the
  inputting of the required values. Typically, but not
  always, you'll want this window to block program execution
  until the user submits the form (FYI: Dialogs that block
  are commonly referred to as "modal dialogs")
  
  (2) Include at least one button to submit the values. This
  button is typically named "Okay", or "Yes" or "Submit".
  But when the user presses this button, the dialog will
  *NOT* be closed until the values have been validated. If
  the values are found to be inadequate, the dialog will
  inform the user of his mistakes and refocus the input-form
  for editing. A more advanced dialog will utilize fields
  that validate their *OWN* values in "real time". These
  "real time validations" are less likely to confuse a user,
  and they facilitate a more efficient interface since the
  user will be aware of mistakes as they occur.
  
  (3) Include at least one button to cancel the interaction.
  Sometimes, a user will open a dialog accidentally, or for
  some other reason decide that they need a way out. For
  instance: Imagine all the times that you've accidentally
  pressed the X button on a window. If the window closed
  without first asking you "Do you really want to close
  without saving changes", you'd be screwed!

A proper "dialog window" will be constructed of three basic
top-level components:

+--+
|DIALOG_TITLE  |
+--+
|  |
|   DIALOG_BODY|
|  |
+--+
|  DIALOG_BUTTONS  |
+--+

The DIALOG_TITLE is simply a string that will be displayed
in the title bar of the dialog. The DIALOG_BODY is a fluid
area in the middle that can be filled with user-editable
fields, and the DIALOG_BUTTONS is an area at the bottom
where appropriate buttons will be displayed.

A proper dialog object will allow the caller to display the
dialog in either "modal" or "non-modal" forms, and it will
expose hooks that will allow the programmer to customize the
validation and submission of the form data. An even more
advanced version will require the programmer to extend a
"form object" and pass it into the constructor.

Fortunately, the tkSimpleDialog has already wrapped *SOME*
of this functionality up for you. All you need to do is
import the class and override a few "virtual methods" to
achieve your desired goal. The tkSimpleDialod.Dialog class
exposes 3 hooks that you can utilize to modify the behavior

  (1) body: In this method you create your widgets.It
  requires one argument which is a tk.Frame instance that
  the widgets can be made a child of.
  
  (2) validate: in this method you validate your widgets and
  return a Boolean flag. If you don't need any validation
  then don't bother to override it.
  
  (3) apply: In this method you can do something with the
  "dialog.result" *AFTER* the dialog closes. Typically
  though, you will handle this action from outside the
  dialog object. But in certain limited circumstances, it
  can 

Re: exit from Tkinter mainloop Python 2.7

[Peter Otten]

kevind0...@gmail.com wrote:

> 
> 
> Christian & Others:
> 
> Thanks for your attention to this matter.
> My code now look like this:
> 
> from Tkinter import *
> 
> 
> def butContinue():
> dbUser = entryName.get()

Here you set the local variable dbUser (every name you rebind inside a 
function is local to that function by default)

> pWord =  entryPWord.get()
> print dbUser

and here you print it.

> print pWord
> root1.quit()
> 
> 
> dbUser = ""

Here you set the global variable dbUser

> pWord  = ""
> root1 = Tk()
> ##root1.geometry("500x250")
> 
> 
> lblTop = Label(root1, text= '  Enter Values Below', font="Helvetica
> 14").grid(row=0, column=0, columnspan=2 , pady=5)
> ##lblTop.pack(side = TOP)
> 
> lblDB = Label(root1,text= 'Weight').grid(row=1, column=0 )
> lblPWord = Label(root1, text= 'Height').grid(row=2,column=0)
> entryName = Entry(root1)
> entryName.grid(row=1, column=1, pady=5)
> 
> entryPWord = Entry(root1)
> entryPWord.grid(row=2, column=1, pady = 5)
> 
> butGo  =  Button(root1, text="   Continue "  , command=butContinue
> ).grid(row=3, column=1, sticky=W, pady=10)
> 
> 
> root1.mainloop()
> 
> print "After the MainLoop"
> print dbUser

and here you print that global variable.

> print pWord
> 
> After I type in the text Weight and Height
> No error are reported and output looks like this:
> 
> Weight
> Height
> After the MainLoop
> 
> 
> Question:
> Why did this code not cause Weight and Height to print again.
> 
> print "After the MainLoop"
> print dbUser
> print pWord
> 
> Thanks in advance.

If you want

> def butContinue():
> dbUser = entryName.get()
> pWord =  entryPWord.get()

to change the global dbUser and pWord you need to declare them as global 
explicitly:

> def butContinue():
  global dbUser, pWord
> dbUser = entryName.get()
> pWord =  entryPWord.get()


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exit from Tkinter mainloop Python 2.7

[kevind0718]

Christian & Others:

Thanks for your attention to this matter.
My code now look like this:

from Tkinter import *


def butContinue():
dbUser = entryName.get()
pWord =  entryPWord.get()
print dbUser
print pWord
root1.quit()


dbUser = ""
pWord  = ""
root1 = Tk()
##root1.geometry("500x250")


lblTop = Label(root1, text= '  Enter Values Below', font="Helvetica 
14").grid(row=0, column=0, columnspan=2 , pady=5)
##lblTop.pack(side = TOP)

lblDB = Label(root1,text= 'Weight').grid(row=1, column=0 )
lblPWord = Label(root1, text= 'Height').grid(row=2,column=0)
entryName = Entry(root1)
entryName.grid(row=1, column=1, pady=5)

entryPWord = Entry(root1)
entryPWord.grid(row=2, column=1, pady = 5)

butGo  =  Button(root1, text="   Continue "  , command=butContinue 
).grid(row=3, column=1, sticky=W, pady=10)


root1.mainloop()

print "After the MainLoop"
print dbUser
print pWord

After I type in the text Weight and Height
No error are reported and output looks like this:

Weight
Height
After the MainLoop


Question:  
Why did this code not cause Weight and Height to print again.

print "After the MainLoop"
print dbUser
print pWord

Thanks in advance.


KBD


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exit from Tkinter mainloop Python 2.7

[Dave Farrance]

kevind0...@gmail.com wrote:

>from Tkinter import *
>
>def butContinue():
>root1.destroy()

As Christian said, you're destroying the root window and its children,
so instead use root1.quit() here.

> ...
>
>root1.mainloop()
>
>print entryName.get("1.0", "end-1c" )
>print entryPWord.get("1.0", "end-1c" )

And your root1.destroy() goes here instead. (The root window would
normally be destroyed on the script exit, but some IDE debuggers will
leave it open.) 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exit from Tkinter mainloop Python 2.7

[Peter Otten]

Christian Gollwitzer wrote:

> Am 23.02.16 um 22:39 schrieb kevind0...@gmail.com:
>> from Tkinter import *
>>
>> def butContinue():
>>  root1.destroy()
>> [...]
>> entryName = Entry(root1).grid(row=1, column=1, pady=5)
>> [...]
>> butGo  =  Button(root1, text="   Continue "  , command=butContinue
>> ).grid(row=3, column=1, sticky=W, pady=10)
>>
>> root1.mainloop()
>>
>> print entryName.get("1.0", "end-1c" )
> 
>> When I click on butGo I get the error below.
>> So is this some sort of scope error?
>> why does entryName not exist for me to grab it's value?
> 
> You call destroy() on the root window of Tk. If you destroy a window,
> that will destroy all of it's children. Therefore by deleting the root
> window, also the entryName widget was deleted. You need to export the
> values before you close the window, i.e. in the butContinue() function.

Even when you follow this advice, entryName was set to None by the line

>> entryName = Entry(root1).grid(row=1, column=1, pady=5)

as grid() always returns None. You need two steps

entryName = Entry(root1)
entryName.grid(row=1, column=1, pady=5)

Also,

>> print entryName.get("1.0", "end-1c" )

I believe that the Entry widget's get() method doesn't take any arguments.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: exit from Tkinter mainloop Python 2.7

[Christian Gollwitzer]

Am 23.02.16 um 22:39 schrieb kevind0...@gmail.com:

lblTop = Label(root1, text= '  Enter Values Below', font="Helvetica 
14").grid(row=0, column=0, columnspan=2 , pady=5)
##lblTop.pack(side = TOP)

lblDB = Label(root1,text= 'Weight').grid(row=1, column=0 )
lblPWord = Label(root1, text= 'Height').grid(row=2,column=0)


Also here, the labels look odd. Have you tried to do some alignment of 
the text with spaces? Remove the sapces and look at the "justify" option 
of the label widget and the "sticky" option for grid.


Christian
--
https://mail.python.org/mailman/listinfo/python-list

Re: exit from Tkinter mainloop Python 2.7

[Christian Gollwitzer]

Am 23.02.16 um 22:39 schrieb kevind0...@gmail.com:

from Tkinter import *

def butContinue():
 root1.destroy()
[...]
entryName = Entry(root1).grid(row=1, column=1, pady=5)
[...]
butGo  =  Button(root1, text="   Continue "  , command=butContinue 
).grid(row=3, column=1, sticky=W, pady=10)

root1.mainloop()

print entryName.get("1.0", "end-1c" )



When I click on butGo I get the error below.
So is this some sort of scope error?
why does entryName not exist for me to grab it's value?


You call destroy() on the root window of Tk. If you destroy a window, 
that will destroy all of it's children. Therefore by deleting the root 
window, also the entryName widget was deleted. You need to export the 
values before you close the window, i.e. in the butContinue() function.


There is another pitfall with Tk: if you delete the main window, you can 
get problems if you try to recreate it. If you want to show several 
pages in sequence or the like, you should withdraw the main window


root1.withdraw()

and popup a fresh toplevel by

t=Toplevel()
and do everything in t. Once you are finished, destroying t will keep 
your application alive (because the real root window is just hidden)


Another comment:

> root1.geometry("500x250")

Do not do this. The grid and pack geometry managers compute the needed 
space automatically. A fixed size in pixels can easily break, when you 
go to another computer with a different font size, screen resolution, or 
a different OS. If you are not satisfied with the whitespace, use the 
padding options of grid or pack.


Christian

--
https://mail.python.org/mailman/listinfo/python-list

exit from Tkinter mainloop Python 2.7

[kevind0718]

Hello:



Newbie here.

Spent the a good part of the day tinkering and reading tutorials,
I was able to create a sample that is very close to my requirement.

When I execute the code below the Dialog displayed as expected and
I can enter data into the textboxes.  All good.

When I click on butGo I get the error below.
So is this some sort of scope error?
why does entryName not exist for me to grab it's value?

Your kind assistance is requested.


Traceback (most recent call last):
  File "C:\Users\kduffy12\workspace\testPythonA\testA\simpleDialog.py", line 
25, in 
print entryName.get("1.0", "end-1c" )
AttributeError: 'NoneType' object has no attribute 'get'




from Tkinter import *


def butContinue():
root1.destroy()

root1 = Tk()
root1.geometry("500x250")


lblTop = Label(root1, text= '  Enter Values Below', font="Helvetica 
14").grid(row=0, column=0, columnspan=2 , pady=5)
##lblTop.pack(side = TOP)

lblDB = Label(root1,text= 'Weight').grid(row=1, column=0 )
lblPWord = Label(root1, text= 'Height').grid(row=2,column=0)
entryName = Entry(root1).grid(row=1, column=1, pady=5)

entryPWord = Entry(root1).grid(row=2, column=1, pady = 5)

butGo  =  Button(root1, text="   Continue "  , command=butContinue 
).grid(row=3, column=1, sticky=W, pady=10)


root1.mainloop()

print entryName.get("1.0", "end-1c" )
print entryPWord.get("1.0", "end-1c" )
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: tkinter mainloop

[ast]

Rick Johnson rantingrickjohn...@gmail.com a écrit dans le message de 
news:3385be62-e21c-4efe-802e-8f7351155...@googlegroups.com...




You don't need to call mainloop() when building Tkinter
widgets on the command-line, but for *real* scripts i believe
you'll need to. For instance, if you run the following code
you will see a window with a label inside:



You are right
In fact, I used to open *.py programs with IDLE and then I run
programs from IDLE menu. With this way, mainloop( ) is not
needed.
I tried to double click on a *.py to run a program. Without
mainloop( ), the console appears a split seconds, then
deseapears, and that's all. With mainloop( ) it works.





 Second question, is it possible to cancel a mainloop() ?


I don't think you meant to say cancel, did you really mean
pause?


 I neeed this feature because I have a main window root
 = Tk() which opens a Toplevel secondary window top =
 Toplevel() and I would like root window to be frozen
 while the user fills the top window.


Sounds like you're trying to create a modal dialog, yes?

Tkinter has a few methods for handling such cases. One is
called wait_window and another is called quit, with
wait_window being preferred over quit for most tasks.
There are also methods for setting the input focus and
grab. A good example for you to look at is the
tkSimpleDialog.Dialog class.


OK
tkinter.simpledialog.askstring is exactly what I need


Thanks 


--
https://mail.python.org/mailman/listinfo/python-list

tkinter mainloop

[ast]

Hello

mainloop() is a window method which starts the event manager 
which tracks for events (mouse, keyboard ...) to be send to the 
window.


But if I forget the root.mainloop() in my program, it works well 
anyway, I cant see any failure. Why ?


Second question, is it possible to cancel a mainloop() ?

I neeed this feature because I have a main window root = Tk()
which opens a Toplevel secondary window top = Toplevel()
and I would like root window to be frozen while the user fills
the top window. 


thx


--
https://mail.python.org/mailman/listinfo/python-list

Re: tkinter mainloop

[Terry Reedy]

On 11/19/2014 3:46 AM, ast wrote:

Hello

mainloop() is a window method which starts the event manager which
tracks for events (mouse, keyboard ...) to be send to the window.

But if I forget the root.mainloop() in my program, it works well anyway,
I cant see any failure. Why ?

Second question, is it possible to cancel a mainloop() ?


The one loop should been handling all events for all windows.


I neeed this feature because I have a main window root = Tk()
which opens a Toplevel secondary window top = Toplevel()
and I would like root window to be frozen while the user fills
the top window.


There are methods for freezing a widget.  Something like root.withdraw. 
 But there is more than one for doing slightly different things.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: tkinter mainloop

[Rick Johnson]

On Wednesday, November 19, 2014 5:23:38 AM UTC-6, Terry Reedy wrote:
 On 11/19/2014 3:46 AM, ast wrote:
  mainloop() is a window method which starts the event
  manager which tracks for events (mouse, keyboard ...) to
  be send to the window. But if I forget the
  root.mainloop() in my program, it works well anyway, I
  cant see any failure. Why ?

You don't need to call mainloop() when building Tkinter
widgets on the command-line, but for *real* scripts i believe
you'll need to. For instance, if you run the following code
you will see a window with a label inside:

## START CODE ##
import Tkinter as tk
root = tk.Tk()
label = tk.Label(root, text='Hello Blackness')
label.pack()
root.mainloop()
## END CODE ##

However, if you comment out the root.mainloop() line you
will see nothing. Post an example that shows how you build
Tkinter GUIs without calling mainloop.

  Second question, is it possible to cancel a mainloop() ?

I don't think you meant to say cancel, did you really mean
pause?

  I neeed this feature because I have a main window root
  = Tk() which opens a Toplevel secondary window top =
  Toplevel() and I would like root window to be frozen
  while the user fills the top window.

Sounds like you're trying to create a modal dialog, yes?

Tkinter has a few methods for handling such cases. One is
called wait_window and another is called quit, with
wait_window being preferred over quit for most tasks.
There are also methods for setting the input focus and
grab. A good example for you to look at is the
tkSimpleDialog.Dialog class. But remember, why re-invent the
wheel if you don't need to. The tkSimpleDialog.Dialog class
is a wrapper around a modal dialog behavior. And it is very
simple (imagine that!) to use.


## START CODE ##
import Tkinter as tk
from tkSimpleDialog import Dialog
from tkMessageBox import showerror
from Tkconstants import LEFT, YES, END

class MyDialog(Dialog):
def body(self, body):
tk.Label(body, text='Enter a value').pack(side=LEFT)
self.entry = tk.Entry(body)
self.entry.pack(side=LEFT, expand=YES)

def validate(self):
if self.entry.get() != '':
return True
showerror('', 'Must enter a value first, or cancel!')
return False

def apply(self):
self.result = self.entry.get()

if __name__ == '__main__':
root = tk.Tk()
root.update_idletasks() # Don't do this normally
d = MyDialog(root)
print 'User Entered: {0!r}'.format(d.result)
root.mainloop()
## END CODE ##

However, i must admit the API is both poorly written, uses
poor naming conventions for the hooks, and also trys to be
too implicit by auto-showing the dialog. I rewrote the entire 
class many years ago and have not missed it one bit. 

 There are methods for freezing a widget.  Something like
 root.withdraw. But there is more than one for doing
 slightly different things - Terry Jan Reedy

Actually that's not true Terry. The Toplevel method named
withdraw will cause a window to be hidden from view. And
if the OP tries to use withdraw on the root window, the root
and *ALL* child window(s) will be withdrawn, leaving no visible
windows at all -- at least in the example he gave anyhow.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re-creating a Tkinter mainloop()

[[EMAIL PROTECTED]]

Hi,

I am trying to run a Tkinter application in a thread and it
works pretty well to an extent. However, when I try to
recreate the application after the thread exits, the new
application never shows up. The code below the message
explains what I am trying.

On running this, you should see a simple two-button frame
pop-up, while a sting will keep being printed on the
console. Please press the QUIT button before the counter
counts down to 0. You should see done with main() on the
console. When the counter hits 0, I see

opening new thread

on the console, so main() is being called, but no window
appears.

I am quite new to Tkinter, so I hope I am being clear about
my intentions...

Thanks,
Srinath

from Tkinter import *
import thread
import time

class Application(Frame):
def say_hi(self):
print 'hello world'

def createWidgets(self):
self.QUIT = Button(self)
self.QUIT[text] = QUIT
self.QUIT[fg]   = red
self.QUIT[command] =  self.quit

self.QUIT.pack({side: left})

self.hi_there = Button(self)
self.hi_there[text] = Hello,
self.hi_there[command] = self.say_hi

self.hi_there.pack({side: left})

def __init__(self, master=None):
Frame.__init__(self, master)
self.pack()
self.createWidgets()

def main():
app = Application()
app.mainloop()
print 'done with main()'
app.destroy()

t = thread.start_new_thread(main, ())

n = 20
while 1:
print 'in main thread, n = %d' % n
time.sleep(0.5)
n -= 1
if n == 0:
print 'opening new thread'
t2 = thread.start_new_thread(main, ())

-- 
http://mail.python.org/mailman/listinfo/python-list