NSTableView: checking for mouse-driven selection changes on macOS 27

With gesture recognizers, NSApp.currentEvent is not reliable. Since you're just trying to get at the state of the modifier flags it should be sufficient to just change to the class function NSEvent.modifierFlags inside your table view delegate call.

Since you're just trying to get at the state of the modifier flags

I appreciate the answer and also that in retrospect I should have made my actual question clear sooner in my post, but my question was about how to check if the selection was changed by a mouse click, not about how to get the state of modifier flags. (I mentioned in my post that getting the modifier flags is not a problem and covered by the Tech Note.)

So how do I check if a table or outline view selection change was triggered by a mouse click (as opposed to e.g. keyboard navigation) without relying on currentEvent?

In my example, opening content in the other editor should happen only if the selection has changed because the user is pressing Option while mouse-clicking on a row. (We wouldn't want this behaviour while using the arrow keys to select while holding Option, for instance, because Option already has a meaning in this case: selecting the first or last item.) Option-click has a long tradition on macOS of providing alternative actions like this, and it's a handy trick that has been available in my app for years.

Note that using NSEvent.pressedMouseButtons doesn't work here, either, because the value of that will be 0 by the time tableViewSelectionDidChange is called.

So withoutcurrentEvent, how do I check to see if tableViewSelectionDidChange was triggered by a mouse click?

Thank you.

Actually, referring to the ancient DragNDropOutlineView code linked to from the documentation for NSTableView.clickedRow, it seems that although clickedRow has been reset to -1 by the time tableViewDidChangeSelection(_:) is called, it is available and correct in tableView(_:shouldSelectRow:) and its more modern equivalent, tableView(_:selectionIndexesForProposedSelection:).

So a simple solution is to check for clickedRow in one of these delegate methods to see if the selection is changing owing to a click, and then save the information in a property that can be used in the didChange delegate method, like this:

private var didClick = false
    
func tableView(_ tableView: NSTableView, selectionIndexesForProposedSelection proposedSelectionIndexes: IndexSet) -> IndexSet {
  didClick = tableView.clickedRow != -1 && proposedSelectionIndexes.contains(tableView.clickedRow)
  return proposedSelectionIndexes
}
    
func tableViewSelectionDidChange(_ notification: Notification) {

  // We must reset this because `tableViewSelectionDidChange` could be called without the `proposedSelection` delegate method being called first.
  defer {
    didClick = false
  }

  if didClick && NSEvent.modifierFlags.contains(.option) {
    openInOtherEditor()
    return
  }
  openInCurrentEditor()
}

I don't think you're supposed to read clickedRow in -tableView:selectionIndexesForProposedSelection:. Unless something has changed in macOS 27 the documentation for clickedRow states:

The value of this property is meaningful in the target object’s implementation of the action and double-action methods.

NSTableView is a subclass of NSControl. You should be able to pick up a click change by setting the table view's target-action instead of trying to do it in the delegate methods. Doing it in the delegate method like that might work but IMO this is cleaner and probably safer:

-(void)windowDidLoad
{
 [super windowDidLoad];
 self.tableView.target = self;
 self.tableView.action = @selector(tableViewAction:);
}

-(void)tableViewAction:(NSTableView*)sender
{
    NSLog(@"Clicked Column: %li Clicked row: %li",
          sender.clickedColumn,
          sender.clickedRow);
}

That will trigger on click. NSTableView does not invoke the action on keyboard navigation (at least not on macOS 26).

I'm a bit worried that these AppKit changes might break a bunch of stuff. Hope not. I guess touch screen Macs are coming soon.

Thanks for the reply.

I don't think you're supposed to read clickedRow in -tableView:selectionIndexesForProposedSelection:. Unless something has changed in macOS 27 the documentation for clickedRow states:

This is true, but in testing, clickedRow does work both in an override of selectRowIndexes(_:byExtendingSelection:) and in the delegate tableView(_:selectionIndexesForProposedSelection:). Also, Apple's own sample code for DragNDropOutlineView, which is linked to in the documentation for clickedRow, demonstrates using clickedRow in tableView(_:shouldSelectRow:), which was the older version of tableView(_:selectionIndexesForProposedSelection:). So if Apple's sample code uses it this way, I figure it should be fine.

You should be able to pick up a click change by setting the table view's target-action instead of trying to do it in the delegate methods

I mentioned in my original post that using an action in this case unfortunately isn't a good solution. I need to load content in response to a selection change, and an action won't be fired when the selection is changed in ways other than clicking (it won't be fired when you use keyboard navigation, for instance, as you note). And since the selection-did-change delegate method is called before the action is called, I can't implement both, either, because the selection-did-change method would load content in the main editor before I could check in the action that it should load in the other editor. So content would wrongly get loaded in both, or I'd have to revert content in the main editor when the action was clicked, which would not be pretty.

The only way for this to work is for me to know if the selection changed (in selection-did-change) because of both a mouse click and an Option press - something that has worked for years.

Fortunately, like I say, clickedIndex does seem to work for this - at the moment, at least. (The ideal solution would just be for Apple to make clickedIndex valid during selection-did-change calls.)

I'm a bit worried that these AppKit changes might break a bunch of stuff. Hope not. I guess touch screen Macs are coming soon.

That's my assumption for why these changes are being made too. It's odd that such sweeping changes were barely mentioned at WWDC, getting only a brief mention in the AppKit video and a tech note, since these changes require quite a lot of work in custom controls, tables and text views, and have broken behaviour that has worked for years. (For instance, in NSTextView, selectedRange now only updates after menuForEvent: and its delegate method are called, rather than before, breaking custom context menus in text views. Hopefully that's a bug, though - I've reported it as such.)