Re: Intercepting Some Keyboard Events for NSTextView
Re: Intercepting Some Keyboard Events for NSTextView
- Subject: Re: Intercepting Some Keyboard Events for NSTextView
- From: John Nairn <email@hidden>
- Date: Mon, 15 Jul 2002 11:26:50 -0600
I will try the NSApp method, although I also found another solution.
Although I could not create a custom class for NSTextView in Interface
Builder, I found an example in "Cocoa Programming for Mac OS X
(Hillegass) of subclassing NSTextView when the nib file opens. It has
some nice features such as I can override commands (which after some
testing) worked with
- (void)cancel:(id)sender
- (void)insertNewline:(id)sender
and so on. I can also insert a keyDown method here and act on keys or
pass on to super if needed. I can do all I need, but will this have the
same problems you mentioned below (i.e. swallowing something the input
manager wants)?
Finally, if subclassing NSTextView is a good idea, how come it can not
be done in Interface Builder?
On Monday, July 15, 2002, at 11:13 AM, Douglas Davidson wrote:
On Monday, July 15, 2002, at 08:12 AM, John Nairn wrote:
both have the same problem. They both consider "Return" and "Enter" to
be the same thing which is to insert a new line. I was trying to
intercept keyboard events before the NSTextView processes them so I
can pick out Return and Enter as separate events. For now, just
distinguishing "Return" and "Enter" will solve my problem, but it
would nice to know a general way to intercept keyboard events before
the first responder for future needs that might want to trap more. For
example, the doCommandBySelector approach does not even see ordinary
key presses. The custom classes I tried (following examples in books)
relied on the window being the first responder which seemed to disrupt
Cocoa's automatic handling of responders with features like focus
rings, selections coloring, etc.
You can look at [NSApp currentEvent] to distinguish return vs. enter.
Ordinary key presses can be obtained using other delegate methods, e.g.
textView:shouldChangeTextInRange:replacementString:.
I highly recommend using the delegate methods rather than trying to
override keyDown:, if at all possible. You should not override
NSTextView's keyDown: unless you know exactly what you are doing,
because it intervenes in the event stream before any input management
or key binding occurs. Many keys have special meanings to special
input methods, so you need to be careful not to e.g. swallow a return
that an input manager needs. At a minimum you would need to test such
an override using Japanese, Chinese, Korean, etc.
Douglas Davidson
-----------------------
John Nairn
email@hidden
http://www.geditcom.com
-----------------------
_______________________________________________
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.