Re: International keyboard input/interpretKeyEvents questions
Re: International keyboard input/interpretKeyEvents questions
- Subject: Re: International keyboard input/interpretKeyEvents questions
- From: Aki Inoue <email@hidden>
- Date: Sat, 8 Feb 2003 23:42:17 -0800
Ed,
You need to have an NSView subclass conforming to NSTextInput protocol
being the first responder in order to get it work.
Aki
On 2003.2.8, at 06:32 PM, Edward Peterlin wrote:
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.
_______________________________________________
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.