Re: NSOutlineView reloadItem:reloadChildren: selection bug
Re: NSOutlineView reloadItem:reloadChildren: selection bug
- Subject: Re: NSOutlineView reloadItem:reloadChildren: selection bug
- From: Kevin Ballard <email@hidden>
- Date: Thu, 15 Apr 2004 08:58:25 -0400
On Apr 15, 2004, at 8:49 AM, Marc LAFFITTE wrote:
>
> NSOutlineView normally deals with the selection just fine. When I
>
> have something else selected and I Remove an item above it, the
>
> selection stays with the same object just fine
>
>
Really ? If the deleted row was above the selected, the same item, not
>
the next one remains selected after removing?
That's exactly what I see. I didn't write the original code, but I
haven't found anything that seems to change this. And it's logical -
when you do deal with an NSOutlineView you deal with the represented
items, not the row indexes, because the index for a given item changes
depending on what other items are expanded at the given time (sure, the
selected items are accessed by index but you generally use itemForRow:
with those). It makes sense for NSOutlineView to remember what was
selected by object and not by index when refreshing.
>
> (i.e. the same row is selected even though the row index is now
>
> different). It only acts odd when the selected item is the last one.
>
>
According to my previous remark, this would be logical: The list would
>
like to select the former last item index which does not exist any
>
more an selects instead the first row.
Indeed, but given the above-mentioned behaviour this shouldn't be
happening.
>
> And setting the selection myself won't work because it will select
>
> row 1 then the old row again, but each time I change the selection
>
> the entire window changes its content view, so the view will be
>
> changed twice when it shouldn't be changed at all.
>
>
A work around would be to set a flag saying that your content view
>
should not be refreshed before removing your item, and reseting this
>
flag after the selection. Before refreshing your content view, you
>
would check this flag.
I'd rather not require that. I'll do it if I have to, but I'd like to
find some other way.
>
By the way: Usually, when designing the UI actions, an item may be
>
removed from a list after a user's action on the selected item, and
>
the selected item is removed. The user may get confused if some item
>
is removed while another one has the focus.
This list reflects the current userlist for an IRC chatroom (this is
the code for Colloquy [1]). When a user joins or parts the userlist is
updated. This bug shows up if I have the last item selected and a user
parts.
[1]
http://colloquy.info
--
Kevin Ballard
email@hidden
http://www.tildesoft.com
http://kevin.sb.org
[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.