Hi Corbin and all,
Sorry, I figured out that Corbin's solution did work, there was some other
code in my project that cause problems. But I still suggest Apple should
provide an open API for this double/single click feature if people like the
behavior it was in tiger.
Thanks & best regards,
John
On Thu, Mar 20, 2008 at 4:32 PM, john chen <[EMAIL PROTECTED]> wrote:
> 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 PROTECTED]> 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 (Cocoa-dev@lists.apple.com)
> >
> > 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:
> > http://lists.apple.com/mailman/options/cocoa-dev/johnchen202%40gmail.com
> >
> > This email sent to [EMAIL PROTECTED]
> >
>
>
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
