I’ve been experimenting with menu structures (i.e. a tree of menus and submenus) installed either on the menu bar or as context menus, but I’ve been finding strange behaviour using the same structures as popup menus attached to form buttons.
popup
, popupclick
, popupbutton
, etc., all seem to do much the same thing, just placing the menu in a different position. The first parameter is the menu definition. The help for popup
states, ‘If you want to create a more complex menu (colors, styles, fonts, submenus, etc.) you can create the menu with the menu(
and menuitem(
functions (see Custom Menus).’ A post by Jim 3½ years ago states that ‘Using submenus with popupclick
is not documented to work’ but the text above would seem to supersede that.
The example given in the help text for popupclick
:
local colorChoice
popupclick "Red"+cr()+"Green"+cr()+"Blue","Red",colorChoice
// colorChoice now contains the color name
may be extended to use LMSL with menu identifiers in the suffix of each item, e.g.
local colorChoice,MenuText
MenuText="(Colours)"+cr()+
tab()+"Red"+tab()+"$1ɜ"+cr()+
tab()+"Green"+tab()+"$2ɜ"+cr()+
tab()+"Blue"+tab()+"$3ɜ"
popupbutton MenuText,"",colorChoice
message colorChoice+cr()+info("menuidentifier")
By selecting ‘Green’, this displays the expected menu text (‘Green’) and identifier (‘2’).
However, if I extend that structure to include two levels of submenus . . .
local colorChoice,MenuText
MenuText="(YellowSubmenu)"+tab()+"*S"+cr()+
tab()+"White"+tab()+"$1.1.1ɜ"+cr()+
tab()+"Magenta"+tab()+"$1.1.2ɜ"+cr()+
"(RedSubmenu)"+tab()+"*S"+cr()+
tab()+"Yellow"+tab()+"(YellowSubmenu)$1.1ɜ"+cr()+
tab()+"Cyan"+tab()+"$1.2ɜ"+cr()+
"(Colours)"+cr()+
tab()+"Red"+tab()+"(RedSubmenu)$1ɜ"+cr()+
tab()+"Green"+tab()+"$2ɜ"+cr()+
tab()+"Blue"+tab()+"$3ɜ"
popupbutton MenuText,"",colorChoice
message colorChoice+cr()+info("menuidentifier")
. . . the leaves of the first menu level (Green and Blue), and the first item in the next level (Yellow, which itself has a submenu) display correctly and report the appropriate menu identifier. Those in the first level (Red, Green and Blue) also report the menu text. The remaining leaves (Cyan in the second level, and White and Magenta in the third) are greyed out, therefore can’t be selected and return neither menu text nor identifier.
(I only realised that they were greyed-out at a late stage of investigating this, because my original menus all contained @#RichText;
in the header to enable RTML, which — as previously discussed — has the side-effect of making the foreground colour black unless explcitly changed using the <color>
tag.)
So I wondered what might force them to be considered valid menu items, and tried adding a procedure name, {Test}
, to those three leaf items beyond the first level:
local colorChoice,MenuText
MenuText="(YellowSubmenu)"+tab()+"*S"+cr()+
tab()+"White"+tab()+"$1.1.1ɜ{Test}"+cr()+
tab()+"Magenta"+tab()+"$1.1.2ɜ{Test}"+cr()+
"(RedSubmenu)"+tab()+"*S"+cr()+
tab()+"Yellow"+tab()+"(YellowSubmenu)$1.1ɜ"+cr()+
tab()+"Cyan"+tab()+"$1.2ɜ{Test}"+cr()+
"(Colours)"+cr()+
tab()+"Red"+tab()+"(RedSubmenu)$1ɜ"+cr()+
tab()+"Green"+tab()+"$2ɜ"+cr()+
tab()+"Blue"+tab()+"$3ɜ"
popupbutton MenuText,"",colorChoice
message colorChoice+cr()+info("menuidentifier")
That did the trick. The procedure may be empty or even non-existent: it doesn’t need to do anything and, as far as I can tell, is never executed. There is no need to add the procedure name to items in the first level nor to any item with a submenu. By this means a click on any item in the menu tree will report its correct identifier to the procedure associated with the button, which is what I needed it to do. Note that it still doesn’t report the menu text for items beyond the first level, but that’s not a problem for me.
It seems odd, however, that items in the first level are treated differently from those further up the tree, and that the kludge of using a dummy procedure name seems to be the solution to my problem. Is this a feature or a bug?