#874 -command option doesn't seem to work for cascade menu items on unix

[Brent B. Welch]

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.

[Jeffrey Hobbs]

Logged In: YES
user_id=72656

This still appears to be the case in 8.3.4.

[Todd Helfter]

Logged In: YES
user_id=92123
Originator: NO

This still exists as of Tk 8.6a2