Re: How to trap for the delete key in NSOutlineView?
Re: How to trap for the delete key in NSOutlineView?
- Subject: Re: How to trap for the delete key in NSOutlineView?
- From: "Theodore H. Smith" <email@hidden>
- Date: Mon, 20 Jun 2005 19:24:57 +0100
On 20 Jun 2005, at 15:12, Fritz Anderson wrote:
On 20 Jun 2005, at 8:12 AM, Theodore H. Smith wrote:
I'm trying to trap for the delete key in my NSOutlineView.
...
In IB, I defined an NSResponder subclass. I instantiated this
object in IB. This NSResponde subclass has an outlet which is the
outlineview whose keyboard events I want to handle. Then in the
loading code for this NSResponder, do this:
if ([MyOutline nextResponder] != self ) {
[MyOutline setNextResponder:self];
}
...
Within my NSResponder subclass I have this code:
- (void)interpretKeyEvents:(NSArray *)eventArray {
[super interpretKeyEvents:eventArray]; //set a breakpoint here
}
This doesn't work.
You're assuming that NSOutlineView, before or after it does its
processing in interpretKeyEvents:, passes events up the responder
chain for additional processing. The documentation does not lead me
to believe this is so.
What prevents you from subclassing NSOutlineView, overriding
keyDown: so it responds to <delete>, and passes everything else to
super?
Oh, that was it, I read it from "Cocoa Programming for Mac OS X",
where it tells us we'll rarely need to subclass anything. I am sure
I've heard it from people posting on the lists also.
But what I'm finding, is that for me to do just about any totally
basic trivial thing, like detecting when I get a focus set to my
control, or making the delete key actually delete the current row, I
must subclass something. It's almost as bad as Java where you end up
with a billion classes before you end up getting out of the door.
_______________________________________________
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