On Tue, Mar 4, 2014, at 12:18 PM, Mills, Steve wrote: > On Mar 4, 2014, at 13:51:31, Eric Schlegel <[email protected]> wrote: > > > A little architectural background first: normally, when a keyboard event > > first arrives in the HIToolbox event queue from the window server, the > > initial contents are just as you saw - a keycode and key modifiers, but no > > unicode values. The unicode text doesn’t get added until later when the key > > event is put into the event queue and the Text Services Manager takes a > > look at it and processes the key event through the active input method. > > > > In this case, if the NSEvent needs to cons up an EventRef from its own > > data, it probably just creates a kEventRawKeyDown with keycode but nothing > > else. No unicode text is added because the event isn’t seen by TSM. > > Huh, weird. Too bad the docs don't say anything about this peculiarity. > Guess I'll just look at the key code.
That doesn't seem right… if I press a dead key (like Option-e), then the next unmodified space should insert an acute accent in whatever field editor is first responder. If your code is triggered solely by virtual key code, the user will be prohibited from entering an acute accent, and their transport controls will unexpectedly change. --Kyle Sluder _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
