• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
RE: Bug in setKeyEquivalentMask:?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Bug in setKeyEquivalentMask:?


  • Subject: RE: Bug in setKeyEquivalentMask:?
  • From: "Bell, Carl" <email@hidden>
  • Date: Tue, 6 Nov 2001 14:00:48 -0600
  • Thread-topic: Bug in setKeyEquivalentMask:?

Andrew,

Thanks for the response. I puttered with this a bit, and it appears
that what you say is the case. When I print out the keyEquivalent
for each menu, it says "n" and "N". I tried changing it in IB's
info/attribute window rather than IB's pseudo-menu, but if I check
the "Shift" checkbox, it translates the key equivalent to "N". I
thought it interesting that although IB displays the character (for
the non-shift menu item) in uppercase, it is still lowercase. I guess
that calling [aMenuItem setKeyEquivalent:@"N"] implictly sets the
shiftKeyMask as well. I'd have thought that for menu key equivalents
it would keep the modifier keys and character keys completely separate
(even though N really is a shift-N) perhaps using key codes instead of
the character itself. Oh, well.

Since I'm changing the menus anyway, I'll just set them to cmd-n in
IB and maybe call [aMenuItem setKeyEquivalent:@"n"] in the code (just
in case) and leave it at that.

Again, thanks for your help.

-cb

________________________________________________________________________
Carl W. Bell <http://www.baylor.edu/~Carl_Bell/index.html>
Sr. Analyst/Programmer Baylor University Academic Technology Center


> -----Original Message-----
> From: Andrew Platzer [mailto:email@hidden]
> Sent: Tue, November 06, 2001 12:31 PM
> To: Bell, Carl
> Cc: Cocoa-Dev (E-mail)
> Subject: Re: Bug in setKeyEquivalentMask:?
>
>
> On Tuesday, November 6, 2001, at 07:31 , Bell, Carl wrote:
>
> [snip]
>
> 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


  • Prev by Date: Re: Restoring Dock Icon
  • Next by Date: Re: NSDocument
  • Previous by thread: Re: Bug in setKeyEquivalentMask:?
  • Next by thread: connecting objects from different NIB files?
  • Index(es):
    • Date
    • Thread