Re: Rearranging NSOutlineView via drag-and-drop
Re: Rearranging NSOutlineView via drag-and-drop
- Subject: Re: Rearranging NSOutlineView via drag-and-drop
- From: Charles Jenkins <email@hidden>
- Date: Mon, 05 Jan 2015 08:12:51 -0500
In case it helps anyone, here's how my NSOutlineView rearranging story ends.
I found that reloadItem: works perfectly well to update disclosure triangles. In my acceptDrop method, I tracked which parent items were affected by the move by adding them to an NSSet, then I use performSelector:withObject:afterDelay: using a 0.2-second delay to call a method which reloads the affected items after giving the drag animation time to complete.
But in my app, whether an item has children or not can affect which icon appears beside it in the list. Unfortunately, reloadItem: doesn't request a view, which would call the function that assigns icons, nor can I figure out how to ask the outline for the view after my delegate creates it. Rather than trying to come up with some system to track the views outside of the outine, I gave up and simply use performSelector:withObject:afterDelay using a 0.5-second delay to call a method which reloads the entire outline after a move operation is successful. Now rearranging the tree works as expected and both the disclosure triangles and the item icons get updated properly.
—
Charles
On Sunday, January 4, 2015 at 22:07, Charles Jenkins wrote:
> Thanks, all. I’ll reload parent items. In my app, whether an item has children or not can change which icon appears in the tree, and the outline view has no way to know about that without a reload to cause it to requery the delegate.
>
> —
>
> Charles Jenkins
>
>
> On Sunday, January 4, 2015 at 7:06 PM, Roland King wrote:
>
> >
> > > On 5 Jan 2015, at 02:13, Quincey Morris <email@hidden (mailto:email@hidden)> wrote:
> > >
> > > On Jan 4, 2015, at 05:39 , Roland King <email@hidden (mailto:email@hidden) <mailto:email@hidden>> wrote:
> > > >
> > > > I had to reload the parent row to get it to call the isItemExpandable and other methods to either show a new disclosure triangle or remove one which was no-longer valid.
> > >
> > > That sounds at least halfway to being a bug. However, since (if I understand you correctly) the rows you’d have to reload are *not* the rows you’re moving/inserting/deleting, then the reloads shouldn’t interfere with the animations. I wonder, also, if expanding or collapsing the affected parents would achieve the same thing, if reloads were actually too drastic somehow.
> >
> > Correct - the rows I was reloading were not the ones inserted or removed. I am allowing the user to drag a row onto another row which currently has no children and create a hierarchy there and also to drag a row out of a hierarchy leaving it empty of children. I initially started by having any row which is eligible to have children have a disclosure triangle, even if it didn’t currently have any, but decided it looked rather ugly/non-intuitive in this particular case because everything is really eligible. So when a row is added/deleted/moved I check the parent row(s) before and after status to see if its ‘having children’ state changed, if it has, I reload that parent row only which causes the isItemExpandable etc to be called again and shows/hides the disclosure as appropriate.
> >
> > Is it a bug? Possibly. It would certainly not be unreasonable for the outline view to re-query the parents of rows after table changes to see if they should be re-drawn. Depends a bit on whether you see the expandability of a row as being a fairly static property independent of whether it currently has children or something often queried. I can see it both ways, it was very obvious what needed to be done and it was barely a few lines of code to do it so I put it down to my use case of wanting to change indicators and continued on.
> > _______________________________________________
> >
> > Cocoa-dev mailing list (email@hidden (mailto: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 (http://lists.apple.com)
> >
> > Help/Unsubscribe/Update your Subscription:
> >
> > This email sent to email@hidden (mailto: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