Re: Getting the functionality of -command with tk_optionMenu (longish)

From: Bruce Hartweg (bruce-news_at_hartweg.us)
Date: 06/11/04 

Date: Fri, 11 Jun 2004 09:36:39 -0500

Gerry Snyder wrote:

> I am writing a Tcl/Tk program to display a small database. In one window
> I have a tk_optionMenu to choose the table, a scale to pick the row to
> display, and a text window for the display. Whenever a new selection is
> made on the optionMenu I want the scale and text to update, and when the
> scale is moved I want the text to update. Code samples are shown below.
>
> My first thought was to bind update commands to <ButtonRelease> events
> on the optionMenu and scale. It works fine with the scale, giving the
> expected result. Not so with the optionMenu, though. On W2k, Tcl 8.4,
> the update command gets called, but with the "before" value of the
> variable (menu0). Putting an after delay in the response command did
> no good at all. Adding an update (menu1) almost did it, but once in a
> while the old value is still used. Adding a vwait (menu2) on the
> variable to the response makes sure the new value of the variable is
> used, but that can hang up if the same value is selected again. Using
> bindtags (menu3) to get the menu stuff before the added binding executes
> did not help, but I could have used the wrong parameters.
>
> However, this is not too relevant, perhaps, because on linux (RH 9, Tcl
> 8.3), the bind commands do not get called at all.
>
> The way that does work on both platforms, is not using bind at all,
> and just having a continuous vwait loop (menu4) controlling the
> updates. The only problem with that in the current case is that if the
> program is closed by the x icon at the top of the window the window
> disappears but the program keeps running (Ctl-C kills it in linux, Task
> Manager in W2k).
>
> So, two questions:
>
> 1) Is there a way to do it using bind on both platforms? I prefer this
> method, since it is easily extended to any number of widgets in a window.
>
bind is not neccessarily universal for all widgets (i.e. different actions
trigger them, so you would have varying binds anyway).

The reason the bind isn;t always the best is that is what is already being
used to update the variable, so your bind fires *first* you use the old
variable, then the class bindings fire and the value is updated.

You have a few options (in order of what I would consider easiest)

1) just put a read variable trace on the variable - this insures that
        however it is changed - you get notified *after* the change.
2) tk_optionMenu is a pretty simple convenience routine, so instead of
        using it directly - build you own and then as you add each
        entry you can use the -command option directly to both update
        the variable *and* call your update routine.
3) the bindtags muckong should work, but can be trocky to get right
        (in your case the bindtags should be called during widget
        creation, not during the bind action (by then your already
        ooperating out of order).

> 2) Is there some modification of the vwait loop that will properly close
> down if a user does not use the File-Exit way of closing the program?
>

use wm protocol . WM_DELETE_WINDOW my_exit_routine

> eval "tk_optionMenu .menu4 var4 a b c d e f"

your use of eval here is unneeded and potentially dangerous

Good luck,
        Bruce