Re: Debugging non-zero exit code

Hi,

On Sat, 6 Feb 2016 22:22:38 +0200
Reinis Danne <[email protected]> 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 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.

> 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().
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". 

Best regards

Michael

.-.. .. ...- .   .-.. --- -. --.   .- -. -..   .--. .-. --- ... .--. . .-.

A princess should not be afraid -- not with a brave knight to protect her.
		-- McCoy, "Shore Leave", stardate 3025.3