[Tkinter-discuss] Debugging non-zero exit code

[Reinis Danne]

On Sat, Feb 06, 2016 at 11:10:04PM +0100, Michael Lange wrote:
> Hi,
> 
> On Sat, 6 Feb 2016 22:22:38 +0200
> Reinis Danne <rei4dan at gmail.com> wrote:
> 
> > No, it is not using threads. The issue seems to be caused by the
> > presence of another mainloop() (see
> > edit_pool.py::editPool.activate()). I now noticed that editPool
> > calls editPool.mainloop() during activation and then
> > editPool.quit() during deactivation, but the widget itself
> > remains.
> 
> ahaa, multiple mainloops are one thing that should *never* be done!
> 
> Not sure what you mean with "deactivation", is that something like a
> "readonly" or "disabled" state? If so, why not just change the widget
> state to "readonly" or "disabled"?

I mean "disabled" state, the widget alredy is set to disabled.

> > I don't want to destroy editPool when deactivated, because I want
> > the widget to be visible in the UI (instead of blank space). So
> > the solution of calling app.destroy() in place of app.quit()
> > seems to be the correct one for this case.
> 
> Nope, I disagree! If you want your widget to remain visible but disabled,
> then you should change its state to "disabled" but please leave the
> mainloop alone.

This app.destroy() I meant to call at app exit, not at disabling
editPool.

> > Is such use of nested mainloops considered an error? Is there a
> > better way of doing this?
> 
> Yes and yes. I am still not sure what exactly you want to achieve with
> two mainloops, but you certainly don't need them.
> If you need more than one toplevel window, use Toplevel() instead of a
> second Tk().

There is no second Tk(). The editPool(Frame) just calls
Frame.__init__() in __init__(). Then calls editPool.mainloop() in
editPool.activate().

> If you want to temporarily hide a Tk or Toplevel window without
> destroying it altogether, use withdraw(). If you want to temporarily hide
> a non-toplevel widget, use pack/grid_forget().
> If you want a widget to remain visible but inactive, set its state to
> "disabled" or "readonly", which ever fits best. If it is a custom
> "mega-widget" (as the editpool appears to be), simply set all of its
> subwidgets to state="disabled". 

As I said it disables it correctly, but uses mainloop() to handle
the input. Without it it doesn't input the text in the paper
after pressing Enter.


Reinis