Question

How can I navigate through my table view with the arrow keys. Much like setAction: or setDoubleAction, but instead of reacting to clicks, react with the arrow keys moving up or down through the table.

Was it helpful?

Solution

In your table view delegate, implement tableView:shouldSelectRow:. Do whatever you want, then return YES. It'll get triggered as you select items in the table view.

OTHER TIPS

I'm not sure what you mean because when I select something in a table I can move up and down in the table using the arrow keys. But if you want to customize the behavior more I have a solution. In one of my apps I wanted to detect when the return or enter key was pressed and then perform some action accordingly. I created a new class and made it a subclass of NSWindow. In interface builder I set the main window to be this class. Then I override the keyDown: method of NSWindow in that subclass. So whenever my main window is frontmost (first responder) then key presses are detected and filtered through the method. I'm sure you could do something similar for arrow presses. You might want to make your class a subclass of NSTableView instead of NSWindow depending on how you want to catch the key presses. I wanted it to work for the entire application but you may want it to work only when the table view is first responder.

- (void)keyDown:(NSEvent *)theEvent {
    if ([theEvent type] == NSKeyDown) {
        NSString* characters = [theEvent characters];
        if (([characters length] > 0) && (([characters characterAtIndex:0] == NSCarriageReturnCharacter) || ([characters characterAtIndex:0] == NSEnterCharacter))) {
            // do something here when return or enter is pressed
        }
    }
}

aha! Did you accidentally BREAK NSTableView by doing this?

@implementation NSTableView ( DeleteKeyCategory )
-( void ) keyDown: ( NSEvent * ) event
{
   // ... do something ...

   [super keyDown:event];
}
@end

For me, this had the nefarious side effect of REPLACING NSTableView's keyDown: routine, and it broke the cursor keys. (kind of like swizzling)

Lessons I've learned: - avoid the keyDown: routine altogether. - subclassing Apple NSControls will save work in the long run.

This is the type of mistake that makes using NSTableView very frustrating. Maybe Apple could detect this kind of thing in the static analyzer?

Arrows are used for selection, not for performing any Action. The action that will be applied to the selected item will usually be set by the "action" or "doubleAction" property of the TableView.

Clicking on a table-row does two different things.

  1. TRIES to select the table row (sometimes the table-row can REFUSE to be selected, that's why there is a "shouldSelect" delegate method).

  2. If new selection took place, then the action is performed (with the tableView as the sender). There you can ask the table about the current selection and do whatever you need with it.

Please consider the situation when there are SEVERAL selected rows, or selected columns, or many other complicated situations.

In your case --- what I would recommend, is that you implement the

selectionDidChange:(NSNotigivation)notification;

NSTableView delegate call. This is called AFTER selection has changed, and you know by then the new current selection, and do whatever you want with the selected items.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top