Re: insertText: without a NSWindow/NSView (or: Unicode input without NSView/Window)
Re: insertText: without a NSWindow/NSView (or: Unicode input without NSView/Window)
- Subject: Re: insertText: without a NSWindow/NSView (or: Unicode input without NSView/Window)
- From: Aki Inoue <email@hidden>
- Date: Wed, 30 Jan 2008 10:38:06 -0800
The object that's interacting using NSTextInput protocol is the first
responder in key window.
When you're inputting complex scripts like Japanese or Chinese, the
input methods need to display supporting panels around the text input
object so you need to have visual representation closely tied to
NSWindow/NSView relationship anyway.
Once you implement NSTextInput protocol, you don't have to distinguish
printable characters by yourself.
The actual user input text comes in -insertText: and other non-
printable events in -doCommandBySelector:.
Aki
On 2008/01/30, at 3:02, Ken Thomases wrote:
On Jan 30, 2008, at 2:31 AM, Adam Zegelin wrote:
On 30/01/2008, at 7:21 PM, Ken Thomases wrote:
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.
Oh, oops. Right. I should have remembered that.
There's a document titled "Text Input Management" which sort of
describes this area: http://developer.apple.com/documentation/Cocoa/Conceptual/InputManager/index.html
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.
-Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden