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: "john chen" <email@hidden>
- Date: Thu, 20 Mar 2008 16:32:58 -0500
Hi Corbin,
In my application, the table has several columns, some of them is editable,
some not. I defined a handleDoubleClick method when user double clicks on a
non-editable column. In Tiger, it works fine. When double click on a
editable column, it will start to editing. But in Leopard, not matter which
columns (editable or non-editable) when user double click, the
handleDoubleClick method is get called.
I understand Leopard introduce this 'Single click to edit' for some good
reasons. But in my application, it just causes trouble because the single
click has very significant delay that confuse users. So users really like to
use double click start edit. I strongly recommend Apple to provider an API
so people like me can make the application that works like it was in Tiger.
I tried the solution you hinted in the above,
make tableView:shouldEditTableColumn:.." always
return NO and in my handleDoubleClick, I check if the column is editable, if
yes, start the editing by ditColumn:row:... The code is shown below.
if([self isEditableColumn:sender shouldEditTableColumn:[[sender
tableColumns] objectAtIndex:[sender clickedColumn]] row:[sender
clickedRow]]){
[sender editColumn:[sender clickedColumn] row:[sender clickedRow]
withEvent:nil select:YES];
return;
}
But I find this solution has problem in my application. In my tests, when I
was in row1-field1 typing something, then click on row2-field1 quickly,
SOMETIMES, the data in row1-field1 is copied to row2-field1.
I am not sure if I missed something, but this solution doesn't work for me
:(
Thanks & best regards,
John
On Mon, Dec 3, 2007 at 3:55 PM, Corbin Dunn <email@hidden> wrote:
> >>
> >> 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
>
_______________________________________________
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