Re: Leopard NSTableView Cell and single click editing
Re: Leopard NSTableView Cell and single click editing
- Subject: Re: Leopard NSTableView Cell and single click editing
- From: Mike Wright <email@hidden>
- Date: Sat, 1 Dec 2007 06:47:13 -0500
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/
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden