Disabling edit on single-click in view-based NSTableView?

Update: Weirdly, this seems to be *caused* by -setDoubleAction:. If I comment that out, then selection doesn't cause editing to begin. Even so, this only happens in two tables, as I say - the other tables have -setDoubleAction: set up an action on them, and they do not exhibit this strange behaviour, so I have no idea what is going on. I can just override -mouseDown: in my NSTableView subclass and start editing on the text field for the NSTableCellView at the mouse point if clickCount==2, which works fine and fixes the issue, but I'd love to understand the underlying cause...

Do you use a trackpad? Do you have it configured that a tap does a click? (That is, you can click without actually pushing the trackpad down.) I've encountered a bug where using that feature caused a table view to start editing the row on first "click".

Unfortunately not, no - I'm using a regular mouse, left-clicking. And the problem is only exhibited when -setDoubleAction: is on, and only in two tables - others are working fine, as I say. It's very bizarre.

I managed to reproduce this in a test project, so I'm now wondering if this is intended behaviour and all of my other table views are somehow preventing it becuase of the various custom classes I use (even though I'm using the same custom classes in my app for the tables affected). Anyway, here's a sample project showing the issue if anyone has time to take a look:

http://literatureandlatte.com/misc/TableEditBugTest.zip

Simply download, build and run, then click into the rows. Clicking on the text area of a row causes editing to start immediately, regardless of whether row was already selected or not; clicking to the right of the text causes expected behaviour, with the row just being selected. This behaviour only occurs when -setDoubleAction: is set and the text field in the table cell is set to be editable.

I just posted a reply with a sample project showing the issue, but of course, now that posts with links in them are moderated, that may not show up for a day or so. But essentially, it seems easy to reproduce this behaviour in a sample project as follows:

1. Create a view-based NSTableView and hook it up to an NSArrayController (arrangedObjects and selectionIndexes bound to the array controller, the objectValue.key of the cell view text field bound to the cell view etc).

2. Set the cell view's text field to be editable.

3. In code, set the content of the array controller to an array of dictionaries simply containing e.g. @[@{"key": @"Foo"}, @{@"key": @"Bar"}] (but with a mutable array and dictionaries, of course).

4. Set a -doubleAction on the table view (a dummy action will do).

Once you've done all of the above, simply clicking on in the text area of a row causes it to be edited (after a slight delay) without needing to select it first and then click again. (2) and (4) are clearly the key culprits here. Back with cell-based views, I think that a column had to be set not to be editable in order for doubleAction to work properly. But that was fine, because (a) you didn't need to use -doubleAction: to get editing to work on double-clicking - that was standard behaviour; (b) if you did need to use -setDoubleAction:, -editColumn:... would work regardless of whether or not the column was set to be editable. I'm not sure why you would ever want editing to kick in with a single-click on a row that hasn't even been selected.

So I'm now thinking that:

A. This is either intended behaviour or a bug in AppKit. Presumably the latter - I can't see why it would be intended behaviour. My expectation would be that edit-after-delay-after-click would only happen with an already selected row, not one you have just clicked on to select. (Alternatively, I may well just be missing something stupidly obvious, in which case I welcome someone pointing out my ineptitude!)

B. Something in my other table views is preventing this behaviour somehow (which is fortunate).

Many thanks,

Keith

My solution to this problem has (for a long time) been to make the columns of the table not editable. But, in my case, I'm using the double click action as a means of getting to an editor to edit the whole row, as the row is only a very limited representation of some aspects of the underlying object.

Rod

Thanks for the reply. Making the columns uneditable makes no difference, I'm afraid. Are you using cell-based tables by any chance? I used to take that approach with cell-based tables, but with view-based tables you disable editing at the text field level. But if the text fields aren't set to editable, then click-after-delay doesn't work (for when you want to click and then click again instead of triggering the double-click action).

Okay, I discovered the difference between the table views that weren't having this issue and the ones that were: the ones that are fine implement drag-and-drop via a data source. So, the work around is to set a data source on any table views that have a doubleAction set, and implement -tableView:pasteboardWriterForRow:, returning nil if you don't want to write anything. I've reported the issue as #21562075, as this is clearly an AppKit bug with view-based tables using doubleAction.

I'm still having this problem in an outline table with no action or double action and with an implementation of outlineView:pasteboardWriterForItem:.