Toplevels may be closed by several means, including with the X button on top or Alt-F4. Here's example code how to react to this event and have it confirmed. Code for saving files, status, etc. could also go in there (before the exit, of course ;-) wm protocol . WM_DELETE_WINDOW { if {[tk_messageBox \ -icon question \ -type yesno \ -default no \ -message "Do you want to go?" \ -title "Quit Application?"] == "yes"} { exit } } ;# DKF - brought here by RS. Jeffrey Hobbs writes: However, you can do the usual: bind . { puts "away I go" } The advantage with the first ([wm protocol] .. [http://www.tcl.tk/man/tcl8.4/TkCmd/wm.htm#M25]) is just that you get it before the window goes away (in fact, you have to explicitly have that destroy or it will stay), which means it still exists and you can save info that might still be in the widgets. With the latter, you are already on the way down, but it still works. In the latter you also have to ensure you check on the %W, because will otherwise trigger for all the widgets in .top (bindtags). [DKF] - This illustrates quite nicely the difference between trapping a request (what [[wm protocol]] handles) and a notification (what notices.) By the time the arrives it is too late to veto it - the window in question has already gone the way of the dodo - whereas WM_DELETE_WINDOW is really the window manager saying "Would you mind deleting this window, please?" and as such you can do whatever you want with it. Making it pop up 30 new windows in response is probably not a good move though... :^) [NEM] - One point to remember with WM_DELETE_WINDOW though, is to make certain that your code for the handler is completely bug free (or you catch all errors). Otherwise, you can be left with a window that is impossible to close, without forcibly killing the process. [Brian Theado] 19Mar05 - One thing to watch out for with binding the event to "." is that the binding fires for all destroyed windows. For [Tk Game Pack], I was using code like the following to ensure the slave interpreter exits when the toplevel goes away (not shown - exit is aliased to just delete the slave interpreter): bind . +exit This was causing an exit upon any destroyed windows. I changed it to bind . +[list if {"%W" == "."} exit] and now it behaves the way I want. ---- Donal explain that, in such usages as wm protocol WM_DELETE_WINDOW {#} "An empty string is taken as asking for the default behaviour (to destroy the appropriate toplevel.) Workaround is to set the protocol handler to a non-empty do-nothing script (comments are a favourite...)" ---- The syntax is wm protocol window ?name? ?command? '''?name?''' here names "an atom corresponding to a window manager protocol ..." These atoms therefore are dependent on the governing window managers. Among those generally available are * WM_SAVE_YOURSELF * WM_DELETE_WINDOW * WM_TAKE_FOCUS * ... The first three have a historical association with [Motif], or [ICCCM] more specifically. WM_SAVE_YOURSELF handlers ''must'' call "[wm command] ...". This will update the WM_COMMAND property on the top-level window, notifying the session manager (or whoever sent the message) that the message has been handled. [LV]: Does anyone have a sample application which makes use of WM_SAVE_YOURSELF to save off options and then restore them at next execution of the application? In particular, I'd like to find someone with such an application that [GNOME] can identify and make a part of the current session upon request, without the user having to manually add to the session. Tk applications should ''not'' register a protocol handler for WM_TAKE_FOCUS: the proper handling of WM_TAKE_FOCUS is very complicated and should be left to the toolkit. WM_TAKE_FOCUS is there to support a seldom-used keyboard focus model, which doesn't apply to Tk programs. There apparently are not recognized WM_ICONIFY and such; instead, study "[How I catch iconification and such]". "[wm transient] ..." can also help with some [window manager]s ... ---- Also see the FAQ [http://tcl.sourceforge.net/faqs/tk/#wm/delete].