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: Corbin Dunn <email@hidden>
- Date: Mon, 03 Dec 2007 12:55:29 -0800
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.
Are these things only happening in your app? Can you try them with the
DragNDropOutlineView demo app? I don't see these things happening there.
Leopard: Single clicking on *text* will begin editing if: that row was
the only row selected.
Tiger: Single clicking on the cell will begin editing if: that row was
the only row selected.
If the row wasn't selected, single clicking will first select it. You
have to then wait at least until the double click delay to avoid
sending the doubleAction (if set -- if not set, then it doesn't matter).
If more than one row was selected, and you single click on a row, that
single row becomes selected after the double click delay; this allows
the double click action to be applied to the entire selection (Finder
also works this way).
Before Leopard, the behavior was the same in both selected and
unselected rows.
Before Leopard, the last item was never a factor; single clicking a
row would *always* immediately select just that row, and not allow you
to apply a "doubleAction" to a group of selected rows. This was an
explicit bug fix, and hopefully people will see the benefit that it
adds to applications.
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.
Before Leopard, a double click was required to begin editing. The
first click selected that row, and the second click was the double
click that began editing.
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?
Possibly; the problems you are listing sound different than what I've
seen before. It is strange that single clicking on a non-selected row
would begin editing. It must first be selected before editing can
begin. So, something strange is happening in your app (maybe you
manually begin editing at some point?)
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.
Make the delegate method"tableView:shouldEditTableColumn:.." always
return NO. This refuses normal editing behavior. Then, in the
doubleAction, if the clickedRow/clickedColumn's are valid, begin
editing manually by calling editColumn:row:...
Let me know if this works well for you. Hopefully it is easy to do.
thanks,
--corbin
_______________________________________________
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