I don't think I'd classify your original problem as being all that common. In fact, I think yours is the first post regarding it here on this forum.
Without seeing any code, I'd lay odds that the problem lies in the event loop. Specifically, I'd bet that the code manages to create nested event loops in some way, probably through the use of
update,
tkwait, or
vwait. Here's why I think so...
The
wish interpreter automatically goes into the event loop when it finishes evaluating the script. This makes sense, as all Tcl GUI programs are by their very nature event-driven. In most cases, the application terminates when it executes an
exit command in some event handler. The reason that closing the main window ([tt].[/tt]) -- for example, by clicking on the "X" in the titlebar -- kills the application is that: 1) the default handler that Tcl invokes in response to a WM_DELETE_WINDOW message destroys the toplevel window that received the message; and 2) when the main window is destroyed, the
wish interpreter automatically terminates the event loop and exits the application.
However, let's say that some callback in your application executes
update,
tkwait, or
vwait. This actually invokes a
second event loop, rather than "returning" to the currently-running event loop. This secondary event loop contines to handle queued events until it terminates (for example,
update returns once it has drained the event queue;
vwait returns once the specified variable is "touched"

. When the secondary event loop terminates, the handler that originally invoked it resumes execution. We return to the original event loop once the handler finally finishes execution.
Okay, now let's say that while your secondary event loop is running, you close the main window. This destroys the window, but does
not terminate the secondary event loop! The result is that you've now got an application with no GUI sitting around in its event loop waiting for events it will never receive. (If the secondary event loop were to terminate somehow, the application would return to the event handler that spawned the secondary event loop. When that event handler then eventually finished execution, it would return to the original event loop, which would then terminate the application.)
It is for reasons such as these that I caution people to be very, very careful when using
update,
tkwait, or
vwait. I also recommend that you go to the Tcl'ers Wiki (htpp://wiki.tcl.tk) and read the page "Update considered harmful,"
for more information on the dangers of event loop recursion.
Bottom line: if this is indeed the problem you're encountering, I'd advise restructuring your application to avoid nested event loops rather than playing games with
wm protocol bindings.
- Ken Jones, President, ken@avia-training.com
Avia Training and Consulting,
866-TCL-HELP (866-825-4357) US Toll free
415-643-8692 Voice
415-643-8697 Fax