DoMenu

[Richard Gaskin]

dunbarx wrote:

 > I understand the exigencies of cross platform support. That said,
 > I miss most of all the menu handling in HC, as opposed to the button
 > group in LC.
 >
 > The creation of a custom menu with associated menuMessages was clean
 > and clear, and those menuMessages could be invoked via "doMenu", but
 > did not require it. The menuMessage handler references were loaded
 > upon menu creation, accessible like ordinary handlers with a simple
 > call.

The xTalk world has seen at least three methods for handling menus:

HyperCard:  text only, created entirely in scripts

SuperCard:  objects for both menus and items, created in the IDE
             or via scripts

LiveCode:   objects for menus, items are text, created in the IDE
             or via scripts


Creation
--------
HyperCard came with one set of menus, so if there was a menu you didn't 
want in your app you had to explicitly remove it, and then add any you 
did want.  All of this had to be done in scripts, as menus weren't 
persistent objects.

SuperCard uses persistent objects for both menus and menu items, so you 
can create them once using the UI provided in the IDE and be done with 
it.  In the olden days these were sometimes slow if you had to do a lot 
of updating, but I'd guess on modern machines there's no noticeable 
slowdown with those today.

LiveCode is sort of in the middle, with persistent objects for menus, 
which contain the strings that define menu items.  But unlike SuperCard, 
you can populate an entire menu with one chunk expression, and unlike 
HyperCard you don't need to write scripts to populate items.


Updates
-------
In addition to creating items, the other common task we face is updating 
them so that specific items are disabled or enabled appropriate to the 
current context state.

All three xTalk dialects provide ways to handle that, but the main 
difference is triggering:  when exactly do you handle that updating?

In HC and SC you had to keep track of state changes that might affect 
menu disabling throughout your code, modifying menus on the fly as 
actions are performed.

In LC you can just write your code to focus on the action it performs, 
and respond to a single mouseDown event in the menu group to handle menu 
updates discretely.

This seems like a small detail, and perhaps it is, but it's saved me 
many hours of tracking down update stuff to make sure the menus always 
reflect the appropriate state at the moment they're accessed.


Messaging
---------
HyperCard's menuMessage was indeed a godsend, something I missed with SC 
and for a long time with LC as well.  It let us assign a handler name to 
an item, so even if we change the item's name, or also call the routine 
from a context menu which may have a different name, it was easy to 
specify the handler that would be invoked.

In LC we don't have menuMessage, but we have something else which helps 
in many similar circumstance: items can have tags - e.g.:

   &Quit/Q|QuitItem

The tag is the trailing portion following the pipe ("|") - when present, 
that's the value that gets passed with the menuPick message.

With menu item tags we can change the name of an item (like "Quit" on 
Mac and Linux with "Exit" on Windows, or updating the "Paste" item to 
show things like "Paste Text" or "Paste Objects", etc.), and we need to 
write only one case statement to handle any of those variants.

While not quite as convenient as HC's menuMessage, it still lets us use 
centralized code to handle a wide range of menu commands, whether in the 
menu bar or a context menu, by using a single menuPick handler.


All in all, the middle-ground approach LC takes between fully textual 
menus (that have no persistence) and fully object menus (that are 
sometimes slower and less convenient to work with) strikes a balance 
that makes me a happy xTalker.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com