Re: Bug in setKeyEquivalentMask:?
Re: Bug in setKeyEquivalentMask:?
- Subject: Re: Bug in setKeyEquivalentMask:?
- From: Andrew Platzer <email@hidden>
- Date: Tue, 6 Nov 2001 10:31:24 -0800
On Tuesday, November 6, 2001, at 07:31 , Bell, Carl wrote:\
I am trying to modify the key equivalents (actually, the modifier keys)
for two menus at runtime. Depending on a user setting, I want to be
able to use cmd-N and shift-cmd-N to create new default and secondary
document types. I'm using
[aMenuItem setKeyEquivalentMask:NSCommandKeyMask]
to set it to cmd-N and
[aMenuItem setKeyEquivalentMask:(NSCommandKeyMask|NSShiftKeyMask)]
to set it to shift-cmd-N.
One thing I've noticed is that if the shift key modifier is set for a
menu in IB, it "sticks" and the first line above doesn't set it to just
cmd. If I don't specify the shift key in IB, i.e., set both menu items
to cmd-N, it works just fine. Also, when I tried other modifier keys,
it worked. It seems that it's just the shift key.
Am I doing this right, or is the shift key special, or is this a bug? To
work around this I can just set both menus to cmd-N in IB.
What probably is happening is that the command key equivalent is set to @"
N" rather than @"n". It sees that it's uppercase and so automatically
assumes you meant shift-n. This comes from old OpenStep behaviour where it
would display "Command-n" and "Command-N" rather than "Command-N" and
"Command-Shift-N" in the items.
Andrew
__________________________________________________________________
A n d r e w P l a t z e r
A p p l i c a t i o n F r a m e w o r k s
A p p l e