Option-Key "alternative" application behavior == mnemonics?
Option-Key "alternative" application behavior == mnemonics?
- Subject: Option-Key "alternative" application behavior == mnemonics?
- From: John Blackburn <email@hidden>
- Date: Wed, 13 Mar 2002 17:31:16 -0800
Hello,
What's the usual way to handle Option-Key "alternative" application
behavior? For example, when the user chooses the Move To Trash menu
item (Command-Delete) in my application, I show a confirm sheet. I wish
to bypass that sheet if the user's holding down the Option key
(Command-Option-Delete).
This sounds like a job for performMnemonic:, but I can't figure out how
to set the mnemonic for this behavior. I see the spot in IB where you
set the keyboard equivalents, but that's just for the standard
behavior. In this list's and Omni's archives, some writers use
"mnemonic" as a synonym for "keyboard shortcut" (Command-Delete), but
others seem to imply it can also be used for the special behavior I seek
(Command-Option-Delete). But where's the Command-Option-Delete
specified?
In NSResponder.html, I see this:
- (BOOL)performMnemonic:(NSString *)aString
Overridden by subclasses to handle a mnemonic. If the character code or
codes in aString match the receiver's mnemonic, the receiver should
perform
the mnemonic and return YES. NSResponder's implementation does nothing
and returns NO.
Where does "the receiver's mnemonic" get set? When the normal action
handler gets called (Command-Delete), I don't receive an event I can
check for optionKeyDown, as I'd do in a classic app, so I assume there's
a different approach.
Thanks for the time and effort spent reading and answering these
questions. The answers I've received thus far have been wonderful.
John Blackburn
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.