Re: keyDown: and Japanese input methods
Re: keyDown: and Japanese input methods
- Subject: Re: keyDown: and Japanese input methods
- From: Douglas Davidson <email@hidden>
- Date: Tue, 14 Feb 2006 15:45:37 -0800
On Feb 14, 2006, at 3:32 PM, Mark Alldritt wrote:
In my NSTextView sub-class I override keyDown: to intercept the \n
and \r
characters which have a special meaning for my application. The
problem is
that my handling of these return characters is interfering with
Japanese
Input methods which rely on the return character to conclude
certain editing
operations.
How do I determine when an input method is in the middle of entering a
sequence of Japanese characters and when its not?
I'll cut and paste from some of my previous posts to answer this:
Let me review again the path that keystrokes take in the text
system. First, generally speaking you do not want to override -
[NSTextView keyDown:] in most cases; keyDown: is the entry point for
raw keystrokes before they have been interpreted by input methods or
anything else, and if you are not careful in modifying it you can
easily break e.g. Japanese input.
NSTextView takes keystrokes as they come in to keyDown: and passes
them to the key binding system, from which they come back to the text
view either as insertText: (for ordinary keys) or as
doCommandBySelector: (for keys bound to various commands, such as
arrow keys, return, tab, etc.). At this point you can intervene,
either in a subclass, or with the delegate's
textView:doCommandBySelector:. Bear in mind that insertText: can
receive either an NSString (in the usual case) or an
NSAttributedString (for some input methods).
In particular, an enter or return will (with the standard key
bindings) end up using doCommandBySelector: to call insertNewline: on
the NSTextView. If the textview is not a field editor, this will
call insertText: to insert a newline character. If it is a field
editor (for example, when editing a textfield) this will end editing
instead. An arbitrary text view can be made to act in either of
these ways by calling setFieldEditor:.
To do something special for an enter vs. a return, you should be able
to implement the text view delegate method
- (BOOL)textView:(NSTextView *)aTextView doCommandBySelector:(SEL)
aSelector;
and, if aSelector == @selector(insertNewline:), examine [NSApp
currentEvent] to make sure that it is a key event (it should be,
unless someone is calling doCommandBySelector: directly), and if so
what key was pressed.
Alternatively, if you wished to do this in a text view subclass--as
it seems you do--rather than in the delegate, you could override
doCommandBySelector:, or just insertNewline:, in a similar way and
with a similar effect. .
Now, to answer your original question: you can determine whether an
input method has uncommitted ("marked") text via the NSTextInput
protocol method -hasMarkedText. I often hesitate to point out the
NSTextInput protocol, because developers are occasionally tempted to
use some of its methods for purposes unrelated to text input, but
determining whether there is marked text is definitely an appropriate
use for this protocol--provided you still wish to do so after reading
the beginning of this post.
Douglas Davidson
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden