Leopard NSTableView Cell and single click editing

  • Hi,

    as we can read here, Leopard introduced "single click editing" in
    NSTableViews:

    http://developer.apple.com/releasenotes/Cocoa/AppKit.html#NSTableView

    My problem is:
    I have a custom NSTextFieldCell in my tableview that has additional
    elements (e.g. icons that can appear depending on some state). Now I
    don't want to enter edit mode when clicking on those additional
    elements! (It's ok when clicking on the text; but no must-have.)
    I saw that there is a new method that should solve this:

    - (NSUInteger)hitTestForEvent:(NSEvent *)event inRect:
    (NSRect)cellFrame ofView:(NSView *)controlView

    Problem is: it is not called! It seems to depend on the SDK I link to;
    not the system where to app runs on (why?). For various reasons I can
    not link against the 10.5 SDK, nor can I use Xcode 3. I am using Xcode
    2.5 and using 10.4u SDK. I implemented the above method (having to
    define NSUInteger, but that's not a big problem) in my NSTextFieldCell
    subclass, but it never gets called.

    Any ideas how to solve that? Or can the single click editing generally
    be turned off somehow?

    Regards,
    Mani
    --
    http://www.mani.de
    iVolume - Loudness adjustment for iTunes.
    LittleSecrets - The encrypted notepad.
  • On Nov 26, 2007, at 7:00 AM, Manfred Schwind wrote:

    > Problem is: it is not called! It seems to depend on the SDK I link
    > to; not the system where to app runs on (why?). For various reasons
    > I can not link against the 10.5 SDK, nor can I use Xcode 3. I am
    > using Xcode 2.5 and using 10.4u SDK.

    This is a commonly used technique for ensuring compatibility with
    existing apps that might depend on the old behaviour. For more info,
    see the "Backward Compatibility" comments at the top of that same
    release note.

    j o a r
  • On 26 nov. 07, at 16:47, j o a r wrote:

    >
    > On Nov 26, 2007, at 7:00 AM, Manfred Schwind wrote:
    >
    >> Problem is: it is not called! It seems to depend on the SDK I link
    >> to; not the system where to app runs on (why?). For various reasons I
    >> can not link against the 10.5 SDK, nor can I use Xcode 3. I am using
    >> Xcode 2.5 and using 10.4u SDK.
    >
    >
    > This is a commonly used technique for ensuring compatibility with
    > existing apps that might depend on the old behaviour. For more info,
    > see the "Backward Compatibility" comments at the top of that same
    > release note.

    Actually, it looks more like a bug in this case.

    If the single edit click is enabled on applications linked with the
    10.4 SDK (and I tend to believe they are from what I can see), then -
    (NSUInteger)hitTestForEvent:(NSEvent *)event inRect:(NSRect)cellFrame
    ofView:(NSView *)controlView should be called in this case too.

    If it's not, then it's a bug.
  • On Nov 26, 2007, at 9:13 AM, Stephane Sudre wrote:

    >
    > On 26 nov. 07, at 16:47, j o a r wrote:
    >
    >>
    >> On Nov 26, 2007, at 7:00 AM, Manfred Schwind wrote:
    >>
    >>> Problem is: it is not called! It seems to depend on the SDK I link
    >>> to; not the system where to app runs on (why?). For various
    >>> reasons I can not link against the 10.5 SDK, nor can I use Xcode
    >>> 3. I am using Xcode 2.5 and using 10.4u SDK.
    >>
    >>
    >> This is a commonly used technique for ensuring compatibility with
    >> existing apps that might depend on the old behaviour. For more
    >> info, see the "Backward Compatibility" comments at the top of that
    >> same release note.
    >
    > Actually, it looks more like a bug in this case.
    >
    > If the single edit click is enabled on applications linked with the
    > 10.4 SDK (and I tend to believe they are from what I can see), then
    > - (NSUInteger)hitTestForEvent:(NSEvent *)event inRect:
    > (NSRect)cellFrame ofView:(NSView *)controlView should be called in
    > this case too.
    >
    > If it's not, then it's a bug.

    Well, it technically isn't a bug, and what you are saying won't work.
    Let me explain:

    hitTestForEvent:inRect:ofView: is correctly implemented in the base
    AppKit cell classes: NSCell, NSTextFieldCell, etc.

    So, there is no way to know that the method is correctly implemented
    for a given cell subclass just by it checking if it is present (since
    it is always present). Because of that, we have to check for the app
    to be linked against Leopard.

    Mani, in regard to your original problem -- how did you limit an
    editing session on Tiger? I'm guessing you would have overridden this
    method:

    - (void)editColumn:(NSInteger)column row:(NSInteger)row withEvent:
    (NSEvent *)theEvent select:(BOOL)select

    and not called super if the particular area clicked (based on
    theEvent's mouse location) wasn't in your text area. However, you must
    have been doing something else, since you are having a problem.

    Side note: there is a way to disable the single-click editing
    behavior, however, it should be considered a last resort. Single-click
    editing is nice for consistency on Leopard, and apps that move away
    from that will make it more difficult for users to use that particular
    app (ie: your app). Having said that, you can do this type of code,
    which is very unsupported and may break in future releases: if ([table
    respondsToSelector:@selector(_setEditOnSingleClick:)]) { [table
    _setEditOnSingleClick:NO]; }. If for some reason you really need this
    code, please do file a bug requesting that such a method be made public.

    --corbin
  • > So, there is no way to know that the method is correctly implemented
    > for a given cell subclass just by it checking if it is present
    > (since it is always present). Because of that, we have to check for
    > the app to be linked against Leopard.

    OK, I see, that makes sense.

    > 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).

    Regards,
    Mani
    --
    http://www.mani.de
    iVolume - Loudness adjustment for iTunes.
    LittleSecrets - The encrypted notepad.
  • >
    >
    >> 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.

    --corbin
  • > 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.
    > 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.
    >
    > --corbin

    Too bad I didn’t have this Xcode trick while I was on Tiger!!

    Anyway, I find the single-click editing very slow: there is a
    quite long delay before the single click actually has an effect
    which is confusing for the user that might be tempted to double-click
    instead! I guess this is to allow for an eventual drag operation start…?

    > Side note: there is a way to disable the single-click editing
    > behavior, however, it should be considered a last resort. Single-click
    > editing is nice for consistency on Leopard, and apps that move away
    > from that will make it more difficult for users to use that particular
    > app (ie: your app).
    >
    > --corbin

    I don’t agree completely: the users are big guys, many things behave
    differently
    in different apps.

    For example, back in Tiger, the Finder’s and iTunes’ single-click were
    the "inconsistent" behavior
    and I found it confusing, especially in iTunes (as I mostly use a tab/
    arrow-return sequence
    to begin editing an item’s title in the Finder…).

    For people coming from Tiger (not everyone is a msft switcher…) this
    new feature is confusing,
    especially as it is enforced in every Cocoa app, changing, without the
    developer’s agreement,
    the traditional behavior of apps they were used to.

    The new inter-cell navigation is also quite confusing, I’ll probably
    post about it, yelling for help.

    Flofl.
  • >>
    >
    > Too bad I didn’t have this Xcode trick while I was on Tiger!!
    >
    > Anyway, I find the single-click editing very slow: there is a
    > quite long delay before the single click actually has an effect
    > which is confusing for the user that might be tempted to double-click
    > instead! I guess this is to allow for an eventual drag operation
    > start…?

    It isn't a long delay -- it is a specific one. The double click
    interval. If a double click doesn't come in before that interval, then
    it begins editing. Finder works exactly the same way, FWIW. Drag and
    drop is another whole ball game, and depends on various settings
    (allowsVerticalDrag, etc), but if you click + hold the mouse down, it
    won't start editing, so it doesn't conflict.

    >
    >
    >> Side note: there is a way to disable the single-click editing
    >> behavior, however, it should be considered a last resort. Single-
    >> click
    >> editing is nice for consistency on Leopard, and apps that move away
    >> from that will make it more difficult for users to use that
    >> particular
    >> app (ie: your app).
    >>
    >> --corbin
    >
    > I don’t agree completely: the users are big guys, many things behave
    > differently
    > in different apps.

    This part of the thread is starting to get off topic. My only
    suggestion is to attempt to use the feature as it breeds consistency
    for users so they don't get confused why one app does one thing and
    another a different thing. But, like I said before, if you want public
    API to turn on/off the feature *please* log bugs requesting this.

    > The new inter-cell navigation is also quite confusing, I’ll probably
    > post about it, yelling for help.

    If you are having problems with the way it behaves or looks, I'd
    suggest logging bugs. If you have a question for how to do something
    in code with regards to it, feel free to post to the group.

    thanks,

    --corbin
  • 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/
  • >>
    >> 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
  • 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 <corbind...> 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
    >
  • 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 <johnchen202...> 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 <corbind...> 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
    >>
    >
    >
previous month november 2007 next month
MTWTFSS
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    
Go to today