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: Quincey Morris <email@hidden>
- Date: Fri, 01 Jul 2011 19:47:38 -0700
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.
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.
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.
_______________________________________________
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