Why do you not process all of the characters in the event? In
other words, [[even characters] length] may be greater than 1.
There should be a COMBINING ACUTE ACCENT (u0301) character
following the "e".
If the game engine needs precomposed characters, then you can call -
[NSString precomposedStringWithCanonicalMapping] on the string,
first. Note that this is orthogonal to my previous point. It is
_not_ guaranteed to reduce the length to 1.
Sorry, I forgot to mention that my event handler prints [event
characters] and its length (using [[event characters] length]) to
the console. The length is always 1 or 0, even for composite key
events. ie, the keydown event for option-e results in "" (blank) and
a length of 0. The next key press (the e) just returns "e" and 1.
So if I could get a longer character string that would be a start,
but [event characters] is never longer than 1 character.
In theory, your class would adopt the NSTextInput protocol and then
interact with NSInputManager and NSInputServer objects. However,
there seems to be a significant chunk missing from the conceptual
documentation: how do you tell the framework that your NSTextInput-
conforming object is the current text view.
It seems that your class may still need to be a subclass of NSView,
and the framework would set up the proper relationships behind the
scenes.
In Carbon this is all a lot clearer. There are text input events that
get delivered, and you can handle them at the application level
without requiring a window. :-/
You might be able to accomplish what you need in a truly hackish way:
create an invisible window that accepts first responder and can become
key. Put a custom (maybe NSTextInput-adopting?) NSView subclass in
it, and have it accept the text and pass it to your controller.
