International keyboard input/interpretKeyEvents questions
International keyboard input/interpretKeyEvents questions
- Subject: International keyboard input/interpretKeyEvents questions
- From: Edward Peterlin <email@hidden>
- Date: Sat, 8 Feb 2003 18:32:58 -0800
Greetings. My name is Ed Peterlin, and I'm one of the developers on
the OpenOffice.org project. I've been searching for a way to do
processing of NSKeyDown events into unicode output for
internationalization. I apologize in advance if this is too
offtopic...NeoOffice (
http://www.neooffice.org for source code...vcl
module) is not using NSCell or any other Cocoa object for handling text
input. It is attempting to manually process keyboard input by
examining/handling the event stream and processing NSKey* events.
As an example, take the keysequence "Option-e" "e". The expected
behaviour of this should be to insert an "i" character (e-accent aigu).
The original approach of the code was to extract the character code
from the NSEvent's characters NSString array from the keyboard event.
For the keysequence above, this results in two NSKeyDown events, both
specifying the "e" key...one for the accent indicator, the second for
the actual keypress, not a single event with the unicode value of the
accented character.
I attempted to perform the translation through using the text input
handling mechanism as documented via the interpretKeyEvents: method.
Each time an NSKeyDown event was seen in my implementation of [NSApp
sendEvent:] I constructed an array of a single entry with the keydown
event and invoked the interpretKeyEvents method of the NSApp, expecting
valid Unicode character input to be passed to the insertText: method.
I expected to see no invocations for "meta" sequences, like option-e
for indicating an accent was about to be inserted, and then a string
with the appropriate unicode character for accented input on the next
keystroke that invoked interpretKeyEvents.
When presented with the keysequence above, however, there are two
invocations of insertText and not one; an "Option-e" NSKeyDown event
results in an empty string passed to insertText, and the subsequent "e"
results in a single charactrer string with an unaccented "e" character
being passed to insertText. So it seems interpretKeyEvents isn't
providing any type of preprocessing to detect accented or other complex
input.
To me, he above behaviour seems to imply that interpretKeyEvents does
not retain state between multiple invocations on individual members of
a sequence of related key events and that it would require both the
"Option-e" and "e" NSKeyDown events to be members of its input array.
This would imply Neo still requires knowledge of what potential
sequences of key events are associated with the input of a single
Unicode character to try and buffer them. I have found no references
on how to obtain such reserved input method keystrokes.
Anyone have ideas on either how I may be using interpretKeyEvents
incorrectly or how to interpret NSKeyDown events into their appropriate
output Unicode characters?
ed
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.