doMenu, alas

[Richard Gaskin]

DunbarX wrote:

> This now seems like a minor sticking point, but;
> 
> send "menupick" && "card Inspector" to menu "object" 
> 
> works fine. However,
> 
> send "menupick" && "card Inspector" to button "object"
> 
> fails, (debugger states: "no such object") which is why I wrote in the first 
> place.

That's the subtle difference between "menu" and "button" I referred to 
earlier.

When referring to an object, any xTalk engine will need a little more 
context to find something that isn't in the current stack.  So you could 
say:

   send "menupick"&&"Card Inspector" to button "Object" \
     of stack "revMenuBar"

In HC there are no true menu objects, and there's only one menu bar 
anyway, so none of the normal context stuff is needed.

When MC added support for the "menu" token it was set up to find 
whatever menu button matches the name given in the current menu bar 
(which is either the menubar of the current stack, or the defaultMenuBar).

This is also why MenuDo is convenient:  it searches the menus of the 
current menubar to find a match of a menu item for the string passed to 
it, and then it provides the context when it sends the menuPick message 
for you.

So with MenuDo all you need to write it:

      MenuDo "card Inspector"

No "menu" or "button" reference needed at all with that. :)


> The fact that "doMenu" works only here and there annoys me, because then I 
> cannot use it at all. Which is why i wrote in the first place.
> 
> I will send "menuPick", and like it.
> 
> But I never got a simple straight answer from the community. Is this how 
> everyone does it?

Not so much.  It's somewhat rare that folks trigger scripts in menus 
they don't control.

For those they do control, it's more common that the menuPick handlers 
in their menus are calling routines stored in the stack script or a 
library, which could just as easily be called directly from any other 
object.

This becomes an increasingly useful thing to do when you later start 
adding contextual menus to your stack, something even Mac audiences are 
coming to expect more and more.  Keeping the heavy lifting for user 
actions in a central location lets you call 'em from any menu, in the 
menubar or in a context menu or even in a toolbar button, and they all 
call the same code with the greatest simplicity and efficiency.

That doesn't do much for those who want to manipulate the IDE menus from 
their own scripts, but since the IDE menus are all scripted themselves 
it's not hard to dive into their source to find the most efficient way 
to get at their guts, something not possible with HC's menus since they 
were hard-coded in compiled C in the engine.

--
  Richard Gaskin
  Fourth World
  Revolution training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com