[Tkinter-discuss] Doing things on Tkinter termination

[Michael Lange]

Hi,

On Tue, 26 Jan 2010 20:00:56 +0100
Geoff Bache <geoff.bache at gmail.com> wrote:

> Hi again Michael,
> 
> >> Why doesn't it work to bind to "<Destroy>" like I did? That seemed
> >> the intuitive way to go, and it seems to work on Linux...
> >>
> >
> > I don't have a windows box at hand, so I cannot tell. On my linux
> > box it works, but when I bind the callback to the root tk window the
> > callback is triggered once for every child widget of root.
> 
> Yes, that's true. It's easy to fix that though of course.
> 
> Maybe I should report this as a Python bug? It presumably shouldn't be
> possible to crash Python like this just by writing Python code.

I guess this is rather the way Tk handles the Destroy event than a
python bug. At least the way the Destroy event from child widgets is
propagated to the parent is the same in pure  Tk. And from the "bind"
man page:

    Destroy
        A Destroy event is delivered to a window when it is destroyed.

        When the Destroy event is delivered to a widget, it is in a
        ``half-dead'' state: the widget still exists, but most
        operations on it will fail.

Though I don't know details, this seems to say that <Destroy> callbacks
may be delicate and should be used with care.

Regards

Michael

> 
> >
> >> (To explain some more, I'm still on my GUI testing effort from my
> >> previous question
> >> and am trying to handle window closures. So another potential
> >> solution would be if
> >> there was some way to simulate the actual window closure and
> >> programmatically trigger the window to be closed in the window
> >> manager. But I couldn't see a way to
> >> do that. So the next best thing for me was to use <Destroy> and
> >> exclude programmatic
> >> calls via interception.)
> >>
> >
> > Just a thought... IIRC last time I suggested to override mainloop
> > (); if this is an option you could put your "destroy" callback into
> > the custom mainloop() function, below self.tk.mainloop(n).
> 
> Yes, maybe something like that could work. It feels a bit convoluted
> but I guess there aren't too many other options available that I can
> see.
> 
> Thanks,
> Geoff