Closing a tcl window - wish84 problem

[godatguitar]

Hey all

I have a problem, which i understand is quite common amongst tcl programmers....

When i close a tcl window using the 'X' in the top right corner, wish84 is still active and using memory resources. I need to do either of the following:

a) disable the 'X' command so that when pressed, the button does nothing.

b) remove the 'X' button altogether

c) stop wish84.exe running when the button is pressed so that it free's up the resources and my program can continue once more.


Any help on this would be appreciated as i am unsure of how to do this.

Many thanks in advance.

 

[smugindividual]

wm protocol . WM_DELETE_WINDOW { }

this will make the 'X' in the corner do nothing. Add function call or code in the {} if needed.

And . is the name of the toplevel

 

[Bong]

I don't know why you should be experiencing this problem. What OS are you using?
I just ran some scripts on Windows2k. I certainly did nothing special in the installation or the script. When I hit the X, wish goes away.

Bob Rashkin
rrashkin@csc.com

 

[godatguitar]

Hi


I am running windows 2k. Basically, if i have pressed the X, and i check out my task manager i have wish84.exe still using approx 3meg of memory. So, when i was doing lots of work the other day, i had 120instances of wish84.exe in the list and it froze my computer!!!!


Cheers

 

[DickEp]

Also, how can you remove the maxumize/minumize buttons on the window? I do not want someone to resize the window but do not want the to max/min the window either.

Thanks
Ep

 

[ulis]

Maybe

wm protocol . WM_DELETE_WINDOW { exit }

could help you?

HTH

ulis

 

[smugindividual]

Dickep:
the following command will make it so that the user cannot resize the window, i dont know how to remove the icons from the widget though.

wm resizable . 0 0


(where . is the name of the widget)

 

[AviaTraining]

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&quot. 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,"

http://mini.net/tcl/1255,

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,

http://www.avia-training.com

866-TCL-HELP (866-825-4357) US Toll free
415-643-8692 Voice
415-643-8697 Fax

 

[AviaTraining]

As far as disabling the ability to resize a window, smugindividual was correct with his suggestion:

[tt]wm resizable . 0 0[/tt]

As far as actually removing the minimize and maximize buttons from the toolbar, it depends on what platform you're running and which version of Tcl you're using. The technique that works most widely is wm transient, which marks a toplevel as being a "transient" window working on behalf of a "master" window. Many window managers give transient windows a reduced set of decorations. For example, to mark [tt].d[/tt] as a transient on behalf of [tt].[/tt] (the main window):

[tt]wm transient .d .[/tt]

The drawback to this approach is that it works only if you have multiple toplevel windows, because technically a window can't be transient on behalf of itself. (Older versions of Tcl allowed "self-transient" windows, but many window managers didn't handle them correctly.)

Additionally, as of Tcl/Tk 8.4, a new wm attributes option allows you to query and set platform-specific toplevel attributes. On Windows, you can execute:

[tt]wm attributes . -toolwindow 1[/tt]

This marks a toplevel as a toolwindow, as defined in the MSDN, which has a reduced set of window decorations.

- Ken Jones, President, ken@avia-training.com
Avia Training and Consulting,

http://www.avia-training.com

866-TCL-HELP (866-825-4357) US Toll free
415-643-8692 Voice
415-643-8697 Fax

 

[ulis]

Ken, I'm curious:
Why do you think that the problem of godatguitar is a nested event loop?

ulis

 

[AviaTraining]

ulis,

I suspect that it's a nested event loop problem because I've encountered three different programming errors (yes, from personal experience) that can lead to the symptom of an active wish process consuming resources but not displaying a visible window:[ol][li]Inadvertently creating an endless loop. I discount this possibility because: if the script contained an endless loop before entering the event loop, Tcl would never get the opportunity to display the GUI (because that is deferred until entering the event loop for the first time); and if it occurred sometime after entering the event loop, the GUI would display, but freeze.[/li]
[li]Inadvertently using both pack and grid to manage widgets within the same manager widget. Once again, I discount this possibility because the geometry manager contention would result in Tcl never getting the opportunity to display the GUI.[/li]
[li]Inadvertently leaving a "dangling" nested event loop, as I described in my previous post. In this case, the application displays the GUI, and the user can successfully interact with it in most cases. But closing the window doesn't terminate the nested event loop, and the process continues running even after the GUI shuts down. I discovered this early in my Tcl programming career when I created a server on a Windows system which explictly entered the event loop with vwait, and then tried launching it by double-clicking the script's icon. When I closed the window, thinking that it would kill the application, and then tried re-launching the server, I got an error message saying that the listening port was still in use. Upon investigation, I discovered that the previous server instance was still running, and researching the cause led me to the information on nested event loops.[/li][/ol]Of course, I could be completely wrong about godatguitar's problem, but given the information he provided, I consider it by far the most likely root cause.

- Ken Jones, President, ken@avia-training.com
Avia Training and Consulting,

http://www.avia-training.com

866-TCL-HELP (866-825-4357) US Toll free
415-643-8692 Voice
415-643-8697 Fax

 

[ulis]

Thanks, Ken.

ulis