> On 5 Jan 2015, at 02:13, Quincey Morris <quinceymor...@rivergatesoftware.com> > wrote: > > On Jan 4, 2015, at 05:39 , Roland King <r...@rols.org <mailto:r...@rols.org>> > 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 (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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
