Terry J. Reedy added the comment:
As you gave the code, the two windows just sit there with mainloop running.
Replace it with
root.update()
#w.close()
root.destroy()
and run from IDLE editor and I see the ".!menu.windows" message. Uncomment the
close and it goes away.
Root.destroy recursively calls the .destroy methods of its children. Here,
ListedTopLevel.destroy is called. It calls TopLevel.destroy and
registry.delete. Its menubar child and its dropdown submenu are also
destroyed. But LTL.destroy does *not* call the close method of the
EditorWindow instance (which is *not* a widget). Without a reference, it
cannot.
Registry.delete, which is called for each ListedTopLevel *calls all the
callbacks*, which it exactly should not do at shutdown. It does not unregister
the associated callback. That is part of editor.close.
In IDLE's normal operation, editor.close must somehow get called. In test
setups and teardowns, I am careful to undo things in reverse order of creation.
It is, in a sense, a bug, as things now stand, to create an OutputWindow(root)
without calling its close method before destroying root.
In configdialog, the callbacks are the Var tracers. The configdialog test
teardown removes them all. Closing editorwindows should do the same. This is
not to deny that making shutdown less fragile would be a good thing.
I think having separate EditorWindow and EditorFrame classes that *are* widgets
would help, as then better auxilliary shutdowns could be either part of or
called from the destroy methods that get called when root.destroy is called.
Aside from the ".!menu.windows" message in the idle shell, messages like the
following appear in the command window if there is one, with or without the
editor.close() call.
invalid command name "96611576font_timer_event"
while executing
"96611576font_timer_event"
("after" script)
"89887864font_timer_event"
("after" script)
invalid command name "89718392timer_event"
while executing
Functions timer_event and font_timer_event are CodeContext methods. The
messages don't appear if code_context is not enabled. I don't know how the
messages are prevented (normally) when CondContext is enabled. The is no
obvious graceful shutdown of the loops. They seem to end when self.text no
longer exists so that self.text.after must fail. I already knew that this
class needs work ;-).
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31284>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
