Outline view selection doesn't move when items are inserted?

  • I have an outline view and I've noticed some… interesting behavior.

    Imagine there are 5 items (no hierarchy, just a flat list) and I've
    selected the first one via -selectRow:byExpandingSelection:.

    Next, I modify my data source to insert an item at the very top of the
    list, so now there are 6 items. Then I call -reloadData to inform the
    outline view that I've changed the data.

    Finally, I call -selectedRowIndices and, bizarrely, the first row is
    still selected—even though that's the item I just inserted. The item I
    selected in the first step should have moved down to the second slot. I
    would have assumed that the selection tracks an /item/, and doesn't just
    sit on a particular row.

    Is this behavior to be expected? Seems kinda weird to me.
  • On 2008 Jan, 16, at 19:00, John Stiles wrote:

    > I would have assumed that the selection tracks an /item/, and
    > doesn't just sit on a particular row.

    >
    > Is this behavior to be expected? Seems kinda weird to me.

    Well, since you didn't expect it, it is "not expected".  However, I do
    believe that this is the way it has always worked.  Probably has
    something to do with the data source being a separate object.

    In my code, I get the 'selectedObjects' before -reloadData, then after
    -reloadData, restore it.  Here is some ugly old code I found while
    verifying my memory:

        // Restore selection
        e = [selectedObjects objectEnumerator] ;
        NSMutableIndexSet* selectionIndexes = [[NSMutableIndexSet alloc]
    init] ;
        while ((item = [e nextObject])) {
            int index = [outlineView rowForItem:item] ;
            if (index != NSNotFound) {
                [selectionIndexes addIndex:index] ;
            }
        }
        [outlineView selectRowIndexes:selectionIndexes
                  byExtendingSelection:NO] ;
        [selectionIndexes release] ;
  • OK, this is a little disappointing; fortunately it's not too hard to
    work around on my own. Thanks for confirming my hypothesis.

    Jerry Krinock wrote:
    >
    > On 2008 Jan, 16, at 19:00, John Stiles wrote:
    >
    >> I would have assumed that the selection tracks an /item/, and doesn't
    >> just sit on a particular row.
    >
    >>
    >> Is this behavior to be expected? Seems kinda weird to me.
    >
    > Well, since you didn't expect it, it is "not expected".  However, I do
    > believe that this is the way it has always worked.  Probably has
    > something to do with the data source being a separate object.
    >
    > In my code, I get the 'selectedObjects' before -reloadData, then after
    > -reloadData, restore it.  Here is some ugly old code I found while
    > verifying my memory:
    >
    > // Restore selection
    > e = [selectedObjects objectEnumerator] ;
    > NSMutableIndexSet* selectionIndexes = [[NSMutableIndexSet alloc]
    > init] ;
    > while ((item = [e nextObject])) {
    > int index = [outlineView rowForItem:item] ;
    > if (index != NSNotFound) {
    > [selectionIndexes addIndex:index] ;
    > }
    > }
    > [outlineView selectRowIndexes:selectionIndexes
    > byExtendingSelection:NO] ;
    > [selectionIndexes release] ;
  • Since this seems like a common operation, feel free to log this as a
    bug/feature request against NSOutlineView. Reply back with the bug
    number.

    The main problem: TableView keeps the selection on the same row, and
    doesn't know about 'items'. NSOutlineView knows about items, but has
    never had the smarts to restore the selected items. We could easily
    add this.

    thanks,
    corbin

    On Jan 17, 2008, at 8:22 AM, John Stiles wrote:

    > OK, this is a little disappointing; fortunately it's not too hard to
    > work around on my own. Thanks for confirming my hypothesis.
    >
    >
    > Jerry Krinock wrote:
    >>
    >> On 2008 Jan, 16, at 19:00, John Stiles wrote:
    >>
    >>> I would have assumed that the selection tracks an /item/, and
    >>> doesn't just sit on a particular row.
    >>
    >>>
    >>> Is this behavior to be expected? Seems kinda weird to me.
    >>
    >> Well, since you didn't expect it, it is "not expected".  However, I
    >> do believe that this is the way it has always worked.  Probably has
    >> something to do with the data source being a separate object.
    >>
    >> In my code, I get the 'selectedObjects' before -reloadData, then
    >> after -reloadData, restore it.  Here is some ugly old code I found
    >> while verifying my memory:
    >>
    >> // Restore selection
    >> e = [selectedObjects objectEnumerator] ;
    >> NSMutableIndexSet* selectionIndexes = [[NSMutableIndexSet alloc]
    >> init] ;
    >> while ((item = [e nextObject])) {
    >> int index = [outlineView rowForItem:item] ;
    >> if (index != NSNotFound) {
    >> [selectionIndexes addIndex:index] ;
    >> }
    >> }
    >> [outlineView selectRowIndexes:selectionIndexes
    >> byExtendingSelection:NO] ;
    >> [selectionIndexes release] ;
    >>
    >>
  • Ooh, really? I figured that would be a problem for backwards
    compatibility. I guess it could be an optional thing though...
    [outlineView setSelectionTracksItems:YES] or something.

    I've actually filed a bug against the docs already, saying that they
    should spell out the behavior better:
        rdar://5692703    [Docs] NSOutlineView docs don't discuss
    preservation of selected rows
    If you want me to file a separate feature request against NSOutlineView
    as well, I will happily do it.

    Corbin Dunn wrote:
    > Since this seems like a common operation, feel free to log this as a
    > bug/feature request against NSOutlineView. Reply back with the bug
    > number.
    >
    > The main problem: TableView keeps the selection on the same row, and
    > doesn't know about 'items'. NSOutlineView knows about items, but has
    > never had the smarts to restore the selected items. We could easily
    > add this.
    >
    > thanks,
    > corbin
    >
    > On Jan 17, 2008, at 8:22 AM, John Stiles wrote:
    >
    >> OK, this is a little disappointing; fortunately it's not too hard to
    >> work around on my own. Thanks for confirming my hypothesis.
    >>
    >>
    >> Jerry Krinock wrote:
    >>>
    >>> On 2008 Jan, 16, at 19:00, John Stiles wrote:
    >>>
    >>>> I would have assumed that the selection tracks an /item/, and
    >>>> doesn't just sit on a particular row.
    >>>
    >>>>
    >>>> Is this behavior to be expected? Seems kinda weird to me.
    >>>
    >>> Well, since you didn't expect it, it is "not expected".  However, I
    >>> do believe that this is the way it has always worked.  Probably has
    >>> something to do with the data source being a separate object.
    >>>
    >>> In my code, I get the 'selectedObjects' before -reloadData, then
    >>> after -reloadData, restore it.  Here is some ugly old code I found
    >>> while verifying my memory:
    >>>
    >>> // Restore selection
    >>> e = [selectedObjects objectEnumerator] ;
    >>> NSMutableIndexSet* selectionIndexes = [[NSMutableIndexSet alloc]
    >>> init] ;
    >>> while ((item = [e nextObject])) {
    >>> int index = [outlineView rowForItem:item] ;
    >>> if (index != NSNotFound) {
    >>> [selectionIndexes addIndex:index] ;
    >>> }
    >>> }
    >>> [outlineView selectRowIndexes:selectionIndexes
    >>> byExtendingSelection:NO] ;
    >>> [selectionIndexes release] ;
    >>>
    >>>
  • On Jan 17, 2008, at 10:37 AM, John Stiles wrote:
    > Ooh, really? I figured that would be a problem for backwards
    > compatibility. I guess it could be an optional thing though...
    > [outlineView setSelectionTracksItems:YES] or something.

    We have ways around compatibility problems :) (generally, they are
    checks to see what version of the OS you link against). But, for
    something like this, I'd probably make it opt-in, with a new property.

    >
    >
    > I've actually filed a bug against the docs already, saying that they
    > should spell out the behavior better:
    > rdar://5692703    [Docs] NSOutlineView docs don't discuss
    > preservation of selected rows  If you want me to file a separate
    > feature request against NSOutlineView as well, I will happily do it.

    Please do log a new bug; I think both things are important to get -- a
    documentation update (which happens more frequently than OS releases
    with new API), and new API.

    corbin
  • OK, you've got it!
    rdar://5692750    [NSOutlineView] Selection should track items, not rows

    Thanks for your interest here.

    I think it would make sense to have this be NO for existing outline
    views, but in IB, newly-created outline views should set the property to
    YES by default. That way, you won't break any old apps, but newly
    written code would be able to take advantage of the improved behavior.
    And of course, it'd be a checkbox in the IB attributes so you could
    enable it if you want to use it with existing code.

    Corbin Dunn wrote:
    > On Jan 17, 2008, at 10:37 AM, John Stiles wrote:
    >> Ooh, really? I figured that would be a problem for backwards
    >> compatibility. I guess it could be an optional thing though...
    >> [outlineView setSelectionTracksItems:YES] or something.
    >
    > We have ways around compatibility problems :) (generally, they are
    > checks to see what version of the OS you link against). But, for
    > something like this, I'd probably make it opt-in, with a new property.
    >
    >>
    >>
    >> I've actually filed a bug against the docs already, saying that they
    >> should spell out the behavior better:
    >> rdar://5692703    [Docs] NSOutlineView docs don't discuss
    >> preservation of selected rows  If you want me to file a separate
    >> feature request against NSOutlineView as well, I will happily do it.
    >
    > Please do log a new bug; I think both things are important to get -- a
    > documentation update (which happens more frequently than OS releases
    > with new API), and new API.
    >
    > corbin
  • NSOutline does actually preserve selected item if you (fully)
    implement  persistentObjectForItem: and itemForPersistentObject: That
    might be overkill for what you're looking for though, and/or might
    not do it the way you want....

    Sandy

    On 17 Jan 2008, at 8:52 PM, John Stiles wrote:

    > OK, you've got it!
    > rdar://5692750    [NSOutlineView] Selection should track items,
    > not rows
    >
    > Thanks for your interest here.
    >
    > I think it would make sense to have this be NO for existing outline
    > views, but in IB, newly-created outline views should set the
    > property to YES by default. That way, you won't break any old apps,
    > but newly written code would be able to take advantage of the
    > improved behavior. And of course, it'd be a checkbox in the IB
    > attributes so you could enable it if you want to use it with
    > existing code.
    >
    >
    > Corbin Dunn wrote:
    >> On Jan 17, 2008, at 10:37 AM, John Stiles wrote:
    >>> Ooh, really? I figured that would be a problem for backwards
    >>> compatibility. I guess it could be an optional thing though...
    >>> [outlineView setSelectionTracksItems:YES] or something.
    >>
    >> We have ways around compatibility problems :) (generally, they are
    >> checks to see what version of the OS you link against). But, for
    >> something like this, I'd probably make it opt-in, with a new
    >> property.
    >>
    >>>
    >>>
    >>> I've actually filed a bug against the docs already, saying that
    >>> they should spell out the behavior better:
    >>> rdar://5692703    [Docs] NSOutlineView docs don't discuss
    >>> preservation of selected rows  If you want me to file a separate
    >>> feature request against NSOutlineView as well, I will happily do it.
    >>
    >> Please do log a new bug; I think both things are important to get
    >> -- a documentation update (which happens more frequently than OS
    >> releases with new API), and new API.
    >>
    >> corbin

  • Really?
    Hmm. I don't care about autosaving at all, so would there be any harm in
    just returning the item back as its own persistent object?

    Sandy McGuffog wrote:
    > NSOutline does actually preserve selected item if you (fully)
    > implement  persistentObjectForItem: and itemForPersistentObject: That
    > might be overkill for what you're looking for though, and/or might not
    > do it the way you want....
    >
    > Sandy
    >
    > On 17 Jan 2008, at 8:52 PM, John Stiles wrote:
    >
    >> OK, you've got it!
    >> rdar://5692750    [NSOutlineView] Selection should track items, not
    >> rows
    >>
    >> Thanks for your interest here.
    >>
    >> I think it would make sense to have this be NO for existing outline
    >> views, but in IB, newly-created outline views should set the property
    >> to YES by default. That way, you won't break any old apps, but newly
    >> written code would be able to take advantage of the improved
    >> behavior. And of course, it'd be a checkbox in the IB attributes so
    >> you could enable it if you want to use it with existing code.
    >>
    >>
    >> Corbin Dunn wrote:
    >>> On Jan 17, 2008, at 10:37 AM, John Stiles wrote:
    >>>> Ooh, really? I figured that would be a problem for backwards
    >>>> compatibility. I guess it could be an optional thing though...
    >>>> [outlineView setSelectionTracksItems:YES] or something.
    >>>
    >>> We have ways around compatibility problems :) (generally, they are
    >>> checks to see what version of the OS you link against). But, for
    >>> something like this, I'd probably make it opt-in, with a new property.
    >>>
    >>>>
    >>>>
    >>>> I've actually filed a bug against the docs already, saying that
    >>>> they should spell out the behavior better:
    >>>> rdar://5692703    [Docs] NSOutlineView docs don't discuss
    >>>> preservation of selected rows  If you want me to file a separate
    >>>> feature request against NSOutlineView as well, I will happily do it.
    >>>
    >>> Please do log a new bug; I think both things are important to get --
    >>> a documentation update (which happens more frequently than OS
    >>> releases with new API), and new API.
    >>>
    >>> corbin

    >
previous month january 2008 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 31      
Go to today