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.
Yeah, I read that doc and drew the same conclusion. My guess is its
private.
It's just simple. The first responder in key window gets to talk to
the input methods. You don't have separate API (ActivateTSMDocument)
for making your object "current" for the text input.
As Ken mentions below, you can do it in carbon.
It's jus that the two frameworks are based on different design models
8-). Unlike Carbon that didn't have the view model back when TSM was
designed, the input management interface is integrated into the view
model from the beginning.
Hasn't anyone attempted to implement unicode input in a Cocoa
application where the content display is not necessarily attached to
the NSView system (ie, an OpenGL game or other 3D application). I
seem to recall that World of Warcraft implemented unicode input, but
I can't remember if its Mac OS X layer is written in Cocoa or Carbon.
Sure. All Cocoa-based iApps and Pro Apps that does full-screen
support Unicode input.
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.
I'll try this, but I have a sneaky suspicion that it won't work for
fullscreen. And I'll probably have to override a whole bunch of
other things to prevent the invisible window from loosing focus.
This is one way to approach this. This is a technique used by Apple
apps.
Aki
_______________________________________________
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
