Rafael Bugajewski
Rafael Bugajewski

Reputation: 1712

NSTableView, NSArrayController and reload only after key press?

I have the following situation:

  1. There is one custom view inside of the first window that contains a NSTableView.
  2. There is a second window which acts as a form for the current object behind the selection of the table view inside the first window.

Some more details:

At first I changed addObject: (or add:, this doesn’t really matter):

- (void)addObject:(id)object
{
    [super addObject:object];
    [self saveTemplatesToDisk];
}

Then I changed remove:

- (void)remove:(id)sender
{
    [super remove:sender];
    [self saveTemplatesToDisk];
}

It just saves the current content of the array controller to disk and closes the second window:

- (IBAction)endPreferenceSheet:(id)sender
{
    [templateArrayController saveTemplatesToDisk];

    [NSApp endSheet:preferenceWindow];
    [preferenceWindow orderOut:nil];
}

Finally here’s my problem / question

When I press the return key in the second window, the window closes, the data gets saved and the NSTableView gets properly reloaded without any further interaction. But when I press on the OK button with the mouse, nothing seems to happen. Here’s the interesting part: when I now select another row in the table view in the first window after the second window disappeared, the previously selected row (read: the updated object) gets properly reloaded and displays the content I’ve edited in the second window that has interface elements bound to the selection.

Basically my implementation works, but not when the user uses the mouse to close the window.

The only difference I can spot is the currentEvent, but I can’t imagine how this could change the behavior of this simple application.

Any ideas how I can solve my problem?

Upvotes: 0

Views: 1126

Answers (1)

Peter Hosey
Peter Hosey

Reputation: 96353

Remember the responder chain: The keyboard event starts at the first responder, which will be the field editor, then (if that doesn't handle it) goes to the next responder, which will be the table view. The mouse event goes directly to the view that the user clicked on, which is the button.

So, the difference is that the table view handles the return event, but it never sees the mouse event. When the user clicks, you simply get an action message from the button—the table view remains in in editing mode.

The solution is to have the action method tell the controller to commit editing before proceeding with the actual action.

Upvotes: 2

Related Questions