warack@aero.ARPA (Chris Warack ) (10/14/85)
[Take this line-eater] I have received messages informing me that my recent article on sub-menus has met with the line-eater and lost. I will attempt again to post this article. Unfortunately, I do not have the original; I'll be saying pretty much the same thing though. Recent articles have talked about sub-menus and their problems. From the concept of 'sub-menu,' I thought of a relatively easy and elegant way to support them on the Mac. First, sub-menus are desirable because they allow extra levels of nesting commands. For instance, instead of having FONT and STYLE menus on the menu bar, FONT and STYLE could be sub-menus on a more general FORMAT menu on the menu bar. This would allow the menu bar to be used more economically by applications which would like to use a lot of menus. Menus are better than dialog boxes (like MS Word uses a lot) because they are quicker and easy to explore. A sub-menu would work identical to a main menu. (A main menu is a menu on the menu bar.) A main menu drops when the user clicks on its name on the menu bar. The user can then drag through the items listed below; each 'high-lights' as the user points at it. A sub-menu is the same as any other item, except when it 'high-lights' it also drops ITS menu down under its name but offset to the right/left. The user now has a choice: He can continue down the main menu; the sub-menu disappears as soon as the mouse moves off its name. Or, he can now drag down the sub-menu. The sub-menu acts like any other menu while the user drags on it (even including other sub-menus?!?!) From the applications programmer's viewpoint, a sub-menu is just another type of menu item. It is specified by a resource ID that corresponds to the sub-menu (a resource of type MENU). MenuClick, etc. still act the same; when a user selects a sub-menu item, the sub-menu ID and item number are returned. In other words, a sub-menu is a menubar menu that isn't on the menu bar (it has to have a unique ID, etc.) From Apple's point of view, it's a bit more complicated. They have to fix the menu handling routines to deal with displaying and understanding sub-menus. They also have to determine a representation for it. The best thing would be to expand the menu-record type, but this is an incompatable change and therefore not acceptable. Creating a new resource is the second best (MEN2) which can be used interchangeably, but this still causes compatability problems unless new and separate routines are defined as well. Probably the easiest/best thing to do would be use the ICON # reference in the menu item description. Numbers of 0-127 refer to icons and 128-255 to sub-menus or vice versa. This is still less than optimal but would cause the fewest heart aches and least amount of work (in my point of view.) Another possibility is escaping the menu name. A menu name of ASCII null followed by a byte would mean a sub-menu in MENU resource <value of byte>. This is allowed since the menu name is part of the menu record anyways. I haven't seen an Amiga, but I'm told that it sub-menus appear to the side. They might work like I described, I don't know. So here it is again. This time I am keeping a copy, so if it is eaten, I'll MAIL it to anyone interested. I am already mailing this to the people who notified me of the last line-eater attack. Thanks for your patience, Chris -- _______ |/-----\| Chris Warack (213) 648-6616 ||hello|| || || warack@aerospace.ARPA |-------| warack@aero.UUCP |@ ___ | {seismo!hao | tektronix}!hplabs \ |_______| !sdcsvax - !sdcrdcf!trwrb!trwrba!aero!warack || || \ Aerospace Corporation, PO Box 92957, LA, 90009, Station M1-117 ^^^ ^^^ `---------(|=