Re: Leopard NSTableView Cell and single click editing

FROM : Mike Wright
DATE : Sat Dec 01 12:47:13 2007

On Nov 29, 2007, at 2:38 PM, Corbin Dunn wrote:

>>> Mani, in regard to your original problem -- how did you limit an
>>> editing session on Tiger?

>>
>> If I remember correct, I overwrote the trackMouse:... routine of the
>> cell. If the user clicks on the special area of my NSTextFieldCell
>> subclass, I am doing something else. But the single click editing
>> seems to happen at another level (most probably in the NSTableView
>> mouseDown code, I think).
>>
>> But I was able to solve my problem. I found a way to disable the
>> single click editing on Leopard, so the app behaves exactly like on
>> Tiger. (I did not find a solution to get the desired behaviour plus
>> single click editing on Leopard. But that's not so critical in my
>> case and I spent no more time into that.)
>>

>>> Side note: there is a way to disable the single-click editing
>>> behavior

>>
>> There is: I just always return NO in the tableview delegate method
>> tableView:shouldEditTableColumn:row:.
>> I still can start an editing session programmatically
>> (editColumn:...), if I want to. In my case editing is only available
>> through a contextual menu. Double clicking is overwritten with
>> another action that makes more sense in my app (but I think it must
>> be possible to start an editing session here if I would have wanted
>> that, too).

>
>
> Yes -- that will work, it just removes the ability for the editing to
> automatically happen without a right click.
>
> What you are referring to is one of the primary reasons why single-
> click to edit is so beneficial for apps and users. You have some
> particular text in a cell that you want to be editable, yet at the
> same time you also want a doubleAction to do something else.
> Previously, on Tiger, there was no way to differentiate them; a double
> click would *always* begin editing (unless you did some additional
> work). Now, with "hitTestForEvent:", you can have finer grained
> control, and still all double clicking on text to perform the
> doubleAction, while single-clicking on text will begin editing. IMHO,
> this is an ideal solution. Take Xcode for example; the project list
> supports a doubleAction (ie: open that file in a new window). Before
> Leopard, the only way to inline-edit was with a strange (and not
> easily discoverable) alt-click to begin editing the cell. On Leopard,
> it is much easier; you just single-click on the text (ala Finder) to
> begin editing.


There seems to be some inconsistency in how this works in NSTableView, 
depending on whether or not the cell you click is in a selected 
(highlighted) row. (I have a database application with an all-text 
table view.)

If you single-click on a cell in an unselected row, that cell becomes 
active, with the insertion point at the beginning of the text. If you 
double-click, or click and hold past the double-click interval, the 
same thing happens.

However, if you single-click in a different cell of a selected row, 
the clicked cell does not become active, although the previously 
active cell does become inactive. Once all cells in the row are 
inactive, single-clicking causes the clicked cell to become active, 
but with all of the cell text selected.

If you double-click (or click and hold past the double-click interval) 
on a different cell in the same row, it's the same as if you had 
performed two single clicks in a row; the current cell becomes 
inactive, then the clicked cell becomes active with all its text 
selected.

Before Leopard, the behavior was the same in both selected and 
unselected rows. The clicked cell became active and a single click 
resulted in the insertion point being at the beginning of the text, 
while a double-click resulted in all of the cell text being selected.

Is any of this inconsistency likely to be due to anything I'm doing in 
my NSTableView delegate methods? Or, is it strictly by design in 
Leopard?

What do you recommend as the best approach for getting cells in a 
Tiger-compatible database application to respond in a consistent way, 
regardless of whether the clicked cell is in a selected row or not? 
I'd prefer the Tiger behavior, for a variety of reasons.

Thanks,
Mike Wright
http://www.idata3.com/