[Tkinter-discuss] Doing things on Tkinter termination

Geoff Bache geoff.bache at gmail.com
Tue Jan 26 13:45:49 CET 2010


On Tue, Jan 26, 2010 at 1:34 PM, Geoff Bache <geoff.bache at gmail.com> wrote:
> Hi Geoff,
>
> On Tue, 26 Jan 2010 10:11:31 +0100
> Geoff Bache <geoff.bache at gmail.com> wrote:
>
>> Hi all,
>>
>> How would you add some code that is called when the application is
>> terminated, that is independent of whether it was closed via the
>> window manager or via some programmatic call within the application,
>> such as a call from a "quit" button?
>
>    root.protocol("WM_DELETE_WINDOW", your_quit_method)
>
> This way, your_quit_method() will be called when the window manager
> closes the window through the window's "close" button (i.e. usually the
> cross in the upper right corner) or through Alt-F4 or so. In most cases
> it is a good idea to define a "WM_DELETE_WINDOW" callback even if it is
> only root.quit() to make sure you have control over what happens when
> the user clicks the "close" button.

Hi Michael,

Yes, I'd seen that, but it doesn't really fit the criteria of being
independent of how
it's closed. As far as I can see it will get called when the window's
close button
is pressed, and nothing else, so if the application itself calls "destroy",
it won't actually get called.

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...

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

Thanks,
Geoff


More information about the Tkinter-discuss mailing list