Re: NSTextField behaviour
Re: NSTextField behaviour
- Subject: Re: NSTextField behaviour
- From: Douglas Davidson <email@hidden>
- Date: Wed, 20 Mar 2002 10:23:04 -0800
On Tuesday, March 19, 2002, at 11:52 PM, Daryn Sharp wrote:
First issue is that I want the NSTextField in the
window to always retain key focus. Seemed simple: I
made my subclass the first responder in IB, set
acceptsFirstResponder and becomeFirstResponder to
return YES, and set resignFirstResponder to return NO.
Now the field editor doesn't get keyDown, and
manually redispatching keyDown to [self fieldEditor]
doesn't send the event through to the input manager.
I get an infinite loop. How many I reconnect the
field editor?
I think that is probably not the best way to do this; I believe the
field editor wants to act as first responder itself while it is
editing. I would suggest implementing the delegate method
control:textShouldEndEditing: to return NO, but perhaps someone can
suggest something better.
Second issue is that I'd like to make keyDown: act as
a filter (I know from your many posts that you don't
seem to like people doing this). I'm already using
textView:doCommandBySelector: to handle keystrokes
that the input manager converts to selectors. I do
want to allow mapping almost any keycode (esp. fkeys
and numpad keys) to immediately executed macros that
don't disturb the input buffer.
There is no problem with overriding keyDown: if you really do want to
handle raw key events; the problem is that those who wish to modify text
view behavior often seem to have an immediate impulse to start working
with keyDown:, even when that is not really appropriate. Filtering out
tabs and returns at this point, for example, will play havoc with input
methods that need these keystrokes.
Douglas Davidson
_______________________________________________
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.