Figure 8-4. Three Toplevel windows with configurations
There are a few operational details worth noticing here, all of which are more obvious
if you run this script on your machine:
Intercepting closes: protocol
Because the window manager close event has been intercepted by this script using
the top-level widget protocol method, pressing the X in the top-right corner doesn’t
do anything in the three Toplevel pop ups. The name string WM_DELETE_WINDOW
identifies the close operation. You can use this interface to disallow closes apart
from the widgets your script creates. The function created by this script’s
lambda:None does nothing but return None.
Killing one window (and its children): destroy
Pressing the big black buttons in any one of the three pop ups kills that pop up
only, because the pop up runs the widget destroy method. The other windows live
on, much as you would expect of a pop-up dialog window. Technically, this call
destroys the subject widget and any other widgets for which it is a parent. For
windows, this includes all their content. For simpler widgets, the widget is erased.
Because Toplevel windows have parents, too, their relationships might matter on
a destroy—destroying a window, even the automatic or first-made Tk root which
is used as the default parent, also destroys all its child windows. Since Tk root
windows have no parents, they are unaffected by destroys of other windows.
Moreover, destroying the last Tk root window remaining (or the only Tk root cre-
ated) effectively ends the program. Toplevel windows, however, are always de-
stroyed with their parents, and their destruction doesn’t impact other windows to
which they are not ancestors. This makes them ideal for pop-up dialogs. Techni-
cally, a Toplevel can be a child of any type of widget and will be destroyed with it,
though they are usually children of an automatic or explicit Tk.
Top-Level Windows | 423