Re: key equivalents in Interface Builder Xcode 4
Re: key equivalents in Interface Builder Xcode 4
- Subject: Re: key equivalents in Interface Builder Xcode 4
- From: Christiaan Hofman <email@hidden>
- Date: Sat, 02 Jul 2011 11:57:08 +0200
On Jul 2, 2011, at 4:47, Quincey Morris wrote:
> On Jul 1, 2011, at 18:41, Brian Gardner wrote:
>
>> Puzzling. Maybe there's something I need to set, to steer the non-Command key equivalents
>> from the QTMovieView to the Menu?
>
> Oh, maybe you said this before and I missed it.
>
> There's more than a small chance that QTMovieView is eating all the keystrokes.
>
> Keyboard input that has the Command key modifier is handled specially *first*. Keyboard input that's really interpretable as text (which includes everything other modifier combination) must be capturable as text, so basically it's going to be offered to the menu system *last*, and only if no responder consumed it.
>
>>> guide ... which says that the base character must be able to be produced without any modifiers other than Shift.
>>
>> I didn't understand that, since it also says: may also include the masks for the Shift, Option, or other modifier keys.
>
> If you press the A key, you get "a". Shift-A gives you "A". Option-A gives you "å". Shift-Option-A gives you "Å". Control-A gives you some ASCII control character, 0x01 I think. Shift-Control-A gives you ... I don't know, but I'm guessing the same control character. Option-Control-A gives you ... again I don't know, but I guess either nothing or the same control character.
>
> So, if you looked at the events for all of these, you see one of these "base" characters:
>
> [a/A]
> [å/Å]
> 0x01
>
> but the actual modifiers would always be reported, regardless of which modifiers contributed to the base character. The document appears to be saying that only the first of these is allowable for a menu key equivalent. If you happened to be using a keyboard where Option-A produced "a", then you could use Option-A for a keyboard equivalent.
>
This is not correct. This is true for the /text system/ (i.e. NSTextView). Not for the key events. Key events (and hence key equivalents) are more primitive and have the character and modifier separately. This is also how IB interprets the events when you set the key equivalent there.
The only thing is that in key events the Shift key may already be interpreted, so "Shift" and "a" may already be interpreted as the character "A". This is most definitely *not* true for Option and Control. This is why for the keyEquivalent (the character without the modifier mask) for instance "a" and "A" are equivalent. However, you can still have "Shift" in the keyEquivalentModifierMask (this also means that "shift+a" and "Shift+A" are equivalent, but not equivalent to "A").
> I suppose the short way of saying it is that only modifiers that *don't* affect the base character can be used for a key equivalent.
>
No.
> OTOH, it's also possible that this isn't what the documentation means, and your Option-equivalents are just getting eaten by the QTMovieView too. :)
>
>> here's something interesting....
>> when I pull down the menu (click on "View" for example)
>> and then hit option-d it DOES work.
>
> That would be consistent with the above, if you think of the open menu as a kind of window (conceptually if not actually), so that a different responder chain is in effect.
The main problem you're probably having is that for many views, especially complex views, the view will eat up all kinds of key events before it reaches the menus. This is especially true for key events that have no Command modifier. This is why it is always recommended that you use Command equivalents for menu items.
Christiaan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden