bobsoron@world.std.com (Bob Soron) (12/19/90)
I have a custom File menu in one of my stacks; the last item is named Quit, with a menuMessage of "quitHC" and a commandChar of Q. The quitHC handler puts up an answer dialog box, asking if the user wants to cancel, quit to the Finder, or open another stack. Choosing the first option exits quitHC; the second option sends a doMenu "Quit HyperCard"; and the third presents an answer file dialog filtered to allow only stacks. When the user selects the Quit menu item from the File menu, the quitHC handler works exactly as expected: The answer dialog box appears, and the handlers execute whatever course of action the user selects. If the user presses Command-Q, however, the stack immediately quits to the Finder. The quitHC handler is never executed. I've confirmed this both with the Message Watcher window and by setting a debugging checkpoint on the first line of quitHC. When I changed the commandChar of the Quit menuItem to T, it worked exactly as it should have. Pressing Command-T sent the quitHC message, which activated the quitHC handler as it should have. Is Command-Q hardwired? I found that I could get around this behavior with a commandKeyDown handler that trapped for Q and sent the quitHC message, but it shouldn't be necessary -- the whole point of the commandChar is to send the menuMessage, as it does for every other menuItem in my stack, and as it does for the Quit menuItem with any other commandChar. Thanks for any info. Bob Soron bobsoron@world.std.com
jk3t+@andrew.cmu.edu (Jonathan King) (12/20/90)
bobsoron@world.std.com (Bob Soron) writes: > I have a custom File menu in one of my stacks; the last item is > named Quit, with a menuMessage of "quitHC" and a commandChar of > Q. The quitHC handler puts up an answer dialog box, asking if the > user wants to cancel, quit to the Finder, or open another stack. > Choosing the first option exits quitHC; the second option sends a > doMenu "Quit HyperCard"; and the third presents an answer file > dialog filtered to allow only stacks. This is fine. > When the user selects the Quit menu item from the File menu, the > quitHC handler works exactly as expected: The answer dialog box > appears, and the handlers execute whatever course of action the > user selects. Because your menumessage is being sent and you are handling it appropriately. > If the user presses Command-Q, however, the stack immediately > quits to the Finder. The quitHC handler is never executed. I've > confirmed this both with the Message Watcher window and by > setting a debugging checkpoint on the first line of quitHC. Exactly. This is because when you delete or alter one of HyperCard's standard menus, the menu actions can still be accomplished via domenu or the command keys as a default. You actually make use of this feature when you do a 'domenu "Quit HyperCard"' in your custom quitting handler. One possible fix is to write your own domenu handler, trap the "Quit HyperCard" message, do your special dance, and then quit. Note that there is a slightly subtle point here: since your specialquit wants to use 'domenu "Quit HyperCard"' in some cases, you have to make sure that it gets by your custom domenu handler. One way that may work is to use 'send "domenu Quit HyperCard" to HyperCard' in your specialquit handler, which will skip your handler entirely. This, however, is pretty crude, and rude to other handlers that may want to deal with this message. Another way is to have your specialquit handler set a global variable called reallyquit (or something) that your domenu handler will check, and if reallyquit is "true" then pass the domenu message. I prefer the second method, since this will allow some *other* domenu handler to do *its* little dance as the message passes along the message path and through any additional stack scripts that may be in use. In untested Hypertalk, the second method would look like: on domenu whatever global reallyquit if whatever is "Quit HyperCard" then if reallyquit is "true" then pass domenu whatever else specialquit --your custom handler end if else if --whatever else you need to trap-- end if end domenu. A second possible way to handle this is to write a commandkey handler that checks for command-Q, and does the right thing. You have your own objection to this, and I have another one. My objection to this method is that what you really want to do is make sure that the user can't accidentally "Quit HyperCard", and command-Q is just one way of doing this; there might be a button that will do the same thing, for instance (not necessarily a great idea). > When I changed the commandChar of the Quit menuItem to T, it > worked exactly as it should have. Pressing Command-T sent the > quitHC message, which activated the quitHC handler as it should > have. This works because no domenu "Quit HyperCard" message gets sent. > Is Command-Q hardwired? I found that I could get around this > behavior with a commandKeyDown handler that trapped for Q and > sent the quitHC message, but it shouldn't be necessary -- the > whole point of the commandChar is to send the menuMessage, as it > does for every other menuItem in my stack, and as it does for the > Quit menuItem with any other commandChar. It may be annoying to have Hypercard's standard menu actions work when you have your own custom menu items, but somebody could argue that it is necessary to have them around because they might be typed in the message box, or whatever. It seems to me that the *real* problem is that an action like quitting hypercard should not have its semantics tied to something as ephemeral as a domenu command. Having to say "domenu X" when you really mean "X" is a hack, pure and simple. Maybe this might change in the future? > Thanks for any info. > Bob Soron > bobsoron@world.std.com jking
jkc@Apple.COM (John Kevin Calhoun) (01/04/91)
In article <1990Dec18.200407.7385@world.std.com> bobsoron@world.std.com (Bob Soron) writes: >Is Command-Q hardwired? Yes. Command-Q always causes the message doMenu "Quit HyperCard" to be sent to the current card. We did this so that command-Q will work even when the quit item or the entire File menu has been deleted. No other menu key combination is hard-wired in this way. Kevin Calhoun HyperCard Team Apple Computer, Inc.