Re: WM_KEYDOWN
Re: WM_KEYDOWN
- Subject: Re: WM_KEYDOWN
- From: Douglas Davidson <email@hidden>
- Date: Thu, 12 Apr 2007 08:43:02 -0700
On Apr 12, 2007, at 3:31 AM, Alastair Houghton wrote:
2. Subclass NSTextView and create a variant that has custom
processing for -keyDown:, then in your NSWindow delegate, implement
-windowWillReturnFieldEditor:toObject: to return your custom field
editor. (You could instead subclass NSWindow and override -
fieldEditor:forObject:, though generally speaking it's better to
use delegation unless you need to subclass for some other reason.)
3. As above, but instead of implementing -keyDown:, implement some
of the NSTextInput methods instead.
At this point, it's time for me to insert my usual rant against using
keyDown: in most cases (for reasons that you and others have clearly
stated) and to discuss some of the alternatives. A formatter is the
most elegant way to implement input validation, but if you need more
detailed information, NSTextView is ready to provide it.
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).
The delegate will also receive
textView:shouldChangeTextInRanges:replacementStrings: when the user
alters the text in any way--by ordinary keystrokes, by special
keystrokes that modify the text (e.g. return), by menu commands, by
pasting, by drag and drop, etc. This is the point to intervene if
you are not concerned about typing specifically, but about all user
modifications to the text. After the change has been made, there
will be an NSTextDidChange notification and a corresponding
textDidChange: message sent to the delegate.
In addition, there are other delegate methods such as
textView:willChangeSelectionFromCharacterRanges:toCharacterRanges:
and textView:shouldChangeTypingAttributes:toAttributes: that deal
with other consequences of user actions, such as changes in selection
or changes in the attributes that will be applied to subsequently
typed text. For example, arrow keys will modify the selection but
not the text; likewise, picking "bold" from a menu when there is no
text selected will modify the typing attributes but not the text.
If you are working with a text field or other control rather than
with a text view directly, then the text view in question will be the
field editor, and the control will usually be the field editor's
delegate. You can subclass the control and work with delegate
methods, or you can use a custom field editor by subclassing
NSTextView and using the NSWindow method for providing a custom field
editor to the controls in your window.
Douglas Davidson
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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