 |
 |
Intercepting Keys in NSOutlineView Cell Editing
|
 |
|
 |
|
Forum Regular
Join Date: Apr 1999
Location: London, UK
Status:
Offline
|
|
I'm trying to create an OutlineView where after editing a cell, I intercept the Cancel, Return and Enter keys to add custom behaviour.
Is this difficult to do? The only way I can think of is to create a subclass of NSOutlineView that uses a custom subclass of NSTextView for cell editing.
Any help appreciated!
Amar
|
|
|
| |
|
|
|
 |
|
 |
|
Mac Elite
Join Date: Feb 2001
Location: Vancouver, WA
Status:
Offline
|
|
Well, there are two general ways you could do this. Which one is easier or cleaner depends on what keys you want to catch.
If you just want to intercept every keypress, you'll have to use a custom NSText subclass that implements -keyDown: instead of the normal field editor. Getting this subclass to be used requires either setting a special NSCell subclass as the cell for the table column, or implementing the NSWindow delegate method -windowWillReturnFieldEditor:toObject:. The latter is probably a better approach.
If you want to catch keys which have special UI functions (Esc = cancel, Return/Enter = newline, arrows = move cursor, etc.) and care more about the functions than the keys, it's probably easiest to catch those events in the delegate method -control:textView:doCommandBySelector:. By examining the selector you're passed, you can do different things for different standard key actions (like -insertNewline  , even if the user has changed their key bindings.
However, it sounds like none of the above may be necessary. If all you want to do is hook into the text field's behavior when the user either confirms or rejects their changes to its contents, there are simpler hooks into that process. See the various didEndEditing, willEndEditing, etc. delegate methods on NSControl for that.
|
|
|
| |
|
|
|
 |
|
 |
|
Forum Regular
Join Date: Apr 1999
Location: London, UK
Status:
Offline
|
|
Thanks a lot, Rick!
Sounds like returning a custom editor in -windowWillReturnFieldEditor:toObject: is what I need, as I would like to distinguish between return and enter, for instance. I will have a go at this.
Cheers
Amar
|
|
|
| |
|
|
|
 |
|
 |
|
Mac Elite
Join Date: Feb 2001
Location: Vancouver, WA
Status:
Offline
|
|
Sounds like returning a custom editor in -windowWillReturnFieldEditor:toObject: is what I need, as I would like to distinguish between return and enter, for instance. I will have a go at this.
Not necessarily. In a method that uses -insertNewline: to identify a Return/Enter event, you could test [NSApp currentEvent] to figure out which of the two keys that generate that event it is. (We've done that in a few places.)
|
|
|
| |
|
|
|
 |
|
 |
|
Forum Regular
Join Date: Apr 1999
Location: London, UK
Status:
Offline
|
|
Great, even better!
This is the kind of thing that I think makes Cocoa a bit hard to learn, especially if you come from a more subclassing-based OOP background.
The class structure is "wide" rather than "deep", and classes interact more, which makes finding ways of doing things very hard as a beginner.
Thanks
Amar
|
|
|
| |
|
|
|
 |
 |
|
 |
|
|
|
|
|

|
|
 |
Forum Rules
|
 |
 |
|
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is Off
|
|
|
|
|
|
 |
 |
 |
 |
|
 |
|