dce@Solbourne.COM (David Elliott) (06/06/89)
In reading IM, I've noticed that the menu manager seems to fall
short on a couple of points.
The idea of putting the menu information in a resource seems
quite useful, but it also gives a false sense of configurability.
I would think that each menu item would have a unique identifier
associated with it, and that the menu selection mechanism would return
that identifier. That way, you could modify the menu during
development without having to recompile. Instead, what you get back is
a packed pair of values giving you the menu choice by position.
Also, the menu key mechanism doesn't seem to be as useful as it
might be. I don't understand why it is necessary to call MenuKey
to find out which menu item was requested. Why doesn't the
keyboard input mechanism handle this?
--
David Elliott dce@Solbourne.COM
...!{boulder,nbires,sun}!stan!dcecep@apple.com (Christopher Pettus) (06/06/89)
In article <1378@marvin.Solbourne.COM> dce@Solbourne.COM (David Elliott) writes: > The idea of putting the menu information in a resource seems > quite useful, but it also gives a false sense of configurability. > > I would think that each menu item would have a unique identifier > associated with it, and that the menu selection mechanism would return > that identifier. In fact, that is effectively what MacApp does as a post-pass in the compilation process; it breaks a MacApp defined resource of the cmnu (which contains both menu definitions and an integer identifier) into two resources, one for the menu manager and one for the MacApp internals. The integer identifier is what the MacApp objects then deal with. In fairness, the main use of menu resources in their current form is localization. > I don't understand why it is necessary to call MenuKey > to find out which menu item was requested. Why doesn't the > keyboard input mechanism handle this? It could, but this seems to be a six-of-one, half-a-dozen-of-another type decision; the call has to be made either way. The current scheme, as it happens, allows for command key equivalents which do things besides abbreviate menu selections. -- Christopher Pettus | "Ganesha Said: 'Done! The very Network Systems Development | day I was born I made my first Apple Computer, Inc. | mistake, and by that path have cep@apple.com {nsc, sun}!apple!cep | I sought wisdom ever since.'" AppleLink: PETTUS.C | - The Mahabharata (408) 974-0004 | I: A Mine of Jewels and Gems
siegel@endor.harvard.edu (Rich Siegel) (06/06/89)
In article <1378@marvin.Solbourne.COM> dce@Solbourne.com (David Elliott) writes: > >I would think that each menu item would have a unique identifier >associated with it, and that the menu selection mechanism would return >that identifier. That way, you could modify the menu during >development without having to recompile. Instead, what you get back is Actually, that's how MacApp does it for you. I think. :-) > >Also, the menu key mechanism doesn't seem to be as useful as it >might be. I don't understand why it is necessary to call MenuKey >to find out which menu item was requested. Why doesn't the >keyboard input mechanism handle this? It's conceivable that you may not want Command-key keystrokes to be equivalenced to menu commands, but instead stand for something else. One such example is Suitcase II, which uses command-key equivalents for dialog box controls; or the Standard File package, which uses Command-Period to put away the dialog... --Rich ~~~~~~~~~~~~~~~ Rich Siegel Staff Software Developer Symantec Corporation, Language Products Group Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel "She told me to make myself comfortable, so I pulled down my pants and sat in the pudding." -Emo Phillips ~~~~~~~~~~~~~~~
mnkonar@manyjars.SRC.Honeywell.COM (Murat N. Konar) (06/07/89)
In article <2005@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: [in reference to a previous posting suggesting that the keyboard input mechanism handle MenuKey equivalents] > It's conceivable that you may not want Command-key keystrokes to be >equivalenced to menu commands, but instead stand for something else. One such >example is Suitcase II, which uses command-key equivalents for dialog box >controls; or the Standard File package, which uses Command-Period to >put away the dialog... Implementing the keyboard input mechanism as suggested (so that a menu key equivalent causes a mouse down in menu bar/menu select returns appropriate values) wouldn't prevent using command keys as you suggest. The menu data structures could be searched when a command key press is detected by the system. If the key is found in a menu, treat it as a menu key equivalent, otherwise report the key down event to the application (or DA or whatever). ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
zben@umd5.umd.edu (Ben Cranston) (06/07/89)
As currently implemented the program gets the command-keystroke BEFORE it is actually executed. This allows the program to bring lazy data structures up-to-date and make other preparations. For example, some years ago I hacked a Mac version of the Unix TALK stuff, using multi-panel windows a la user interface guidelines. Since whatever was pasted into the outgoing window was also being sent out, I went into great pains to force the selection of that window to the end of the text before allowing a paste into the window. If the command key stuff just did the paste, I would not have gotten control in time to force the selection to the end of text. A lot of the gore in Mac programming is just this way - it allows the program to get control and do what it has to do in various weird cases that, quite unfortunately, make the rest of us either memorize baroque standard handling sequences or go to skeletons like MacAPP... -- Ben Cranston <zben@umd2.UMD.EDU> (Kingdom of Merryland UniSys 1100/92) Copyright 1989 (you may redistribute ONLY if your recipients can).
rang@cpsin3.cps.msu.edu (Anton Rang) (06/07/89)
In article <23163@srcsip.UUCP> mnkonar@manyjars.SRC.Honeywell.COM (Murat N. Konar) writes: In article <2005@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: [in reference to a previous posting suggesting that the keyboard input mechanism handle MenuKey equivalents] > It's conceivable that you may not want Command-key keystrokes to be >equivalenced to menu commands, but instead stand for something else. Implementing the keyboard input mechanism as suggested (so that a menu key equivalent causes a mouse down in menu bar/menu select returns appropriate values) wouldn't prevent using command keys as you suggest. The menu data structures could be searched when a command key press is detected by the system. If the key is found in a menu, treat it as a menu key equivalent, otherwise report the key down event to the application (or DA or whatever). No, still wouldn't work. Suppose I have SuitCase II open. I hit command-O (or whatever, I think that's one of the command-key combinations). That's in the menu bar 'cause it means "Open". Now the DA gets very confused because it was running in a modal dialog. You could try to hack this by checking the window list, but it gets awfully complicated.... +---------------------------+------------------------+ | Anton Rang (grad student) | "VMS Forever!" | | Michigan State University | rang@cpswh.cps.msu.edu | +---------------------------+------------------------+
mnkonar@manyjars.SRC.Honeywell.COM (Murat N. Konar) (06/21/89)
In article <3322@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes: <In article <23163@srcsip.UUCP< mnkonar@manyjars.SRC.Honeywell.COM (Murat N. Konar) writes: < < In article <2005@husc6.harvard.edu< siegel@endor.UUCP (Rich Siegel) writes: < [in reference to a previous posting suggesting that the keyboard input < mechanism handle MenuKey equivalents] < < It's conceivable that you may not want Command-key keystrokes to be < <equivalenced to menu commands, but instead stand for something else. < < Implementing the keyboard input mechanism as suggested (so that a menu key < equivalent causes a mouse down in menu bar/menu select returns appropriate < values) wouldn't prevent using command keys as you suggest. The menu data < structures could be searched when a command key press is detected by the < system. If the key is found in a menu, treat it as a menu key equivalent, < otherwise report the key down event to the application (or DA or whatever). < <No, still wouldn't work. Suppose I have SuitCase II open. I hit <command-O (or whatever, I think that's one of the command-key If a list were maintained that contained the command key equivalents for a window or dialog, the solution is to search the front window or dialog command key equivalent list THEN the menu data structures. ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)