Tk Source Code

OriginalBugID: 2816 Bug
Version: 8.1
SubmitDate: '1999-09-16'
LastModified: '1999-10-29'
Severity: MED
Status: UnAssn
Submitter: techsupp
ChangedBy: hobbs
OS: Linux
OSVersion: based on debain 2.0, kernel is 2.0.34
Machine: Other


Name:
Phil Endecott

Extensions:
None in the demo above.  My real application uses [incr tcl].  Some of my code uses tclx.

CustomShell:
None in the demo above.  My real application integrates my own code using SWIG.

Comments:
I've had a brief look at the source and can't see anything obviously
    wrong, but I've never delved into tk innards before.  I've tried to
    check for changes in more recent versions but searching for "cascade" on
    the scriptics web site doesn't find anything.  I have a very slow modem
    (14k4!) so I don't want to download a whole new package just in the hope
    that you've fixed it!!!

ReproducibleScript:
ernie:~/incr_draw$ wish8.1 
    % menu .m
    .m
    % menu .m.c
    .m.c
    % .m add cascade -menu .m.c -label "foo" -command {puts foo}
    % .m add command -label "blah"
    % bind . <ButtonPress-3> {tk_popup .m %X %Y}

    Press button-3 on the main window.  Menu pops up with a cascade entry.
    Nothing causes the puts foo command to get executed.

ObservedBehavior:
Nothing causes the puts foo command to get executed.

DesiredBehavior:
The man page says:

           If a -command option is specified for a cascade entry then |
           it is evaluated as a Tcl command  whenever  the  entry  is |
           invoked. This is not supported on Windows.

    I'm not running on windows.

    I'm not quite sure what "invoked" means here - I hope that it means that
    the command should get executed just before the submenu is posted.  But
    I can't cause it to be executed at any time at all.

    The workaround is to use the -postcommand on the submenu, but this isn't
    very suitable in my application because I have the same submenu bound to
    more than one cascade entry in the parent menu.  I need the behaviour of
    the command to be specific to the cascade entry, not to the submenu.

Serhiy, many thanks! Merged into main, core-9-0-branch, and core-8-6-branch by commits [7b37ef1f], [aaa02032], and [ac9e2321].

The manual page was wrong.

The -command option of a cascade entry is not evaluated when the user selects the entry. No platform does this:

• On X11 ::tk::MenuInvoke posts the submenu of the active cascade entry and returns, so neither a click nor Return reaches TkInvokeMenu(). That branch has been there since the initial revision [2bf55ca9aa] of 1998, as has the sentence in the manual [8922a99ffb], so the documented behaviour never existed in 8.0 or later.
• On Windows the menus are drawn by the system and a cascade item never produces a WM_COMMAND; WM_INITMENUPOPUP is not used for this either.
• On macOS a cascade NSMenuItem only opens its submenu and never sends menuItemSelected, and tear-off menus are not supported there at all.

The sentence "This is not supported on Windows" was misleading as well: the invoke widget command does evaluate the command of a cascade entry on Windows, as it does everywhere else (checked with 9.1b1 on Windows 11). TkInvokeMenu() evaluates -command for every type of entry, so for cascade entries this may be a side effect rather than a decision; it does agree with the general description of invoke and -command in the manual, and it is the only way the option does anything at all, so I documented it as the current behaviour.

I first made the entry be invoked on X11 when the user selects it, but discarded that: it cannot work in the menus drawn by Windows and macOS, and a behaviour which exists on one platform only is worse than a documented limitation. For an action bound to the opening of a submenu, the -postcommand option of that submenu is the supported way, which is also what the reporter used as a workaround.

Fixed on branch doc-cascade-command, [311829db0b] and [6c701cbc15]: the documentation of cascade entries is corrected, and test menu-4.13 records that invoke evaluates the command of a cascade entry.

Logged In: YES 
user_id=92123
Originator: NO

This still exists as of Tk 8.6a2

Logged In: YES 
user_id=72656

This still appears to be the case in 8.3.4.