Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!world!bobsoron
From: bobsoron@world.std.com (Bob Soron)
Newsgroups: comp.sys.mac.hypercard
Subject: Is Command-Q Hardwired?
Keywords: commandChar menuMessage screwed up?
Message-ID: <1990Dec18.200407.7385@world.std.com>
Date: 18 Dec 90 20:04:07 GMT
Sender: bobsoron@world.std.com (Bob Soron)
Organization: The World @ Software Tool & Die
Lines: 35

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