Re: Reordering a table insanity
Re: Reordering a table insanity
- Subject: Re: Reordering a table insanity
- From: Quincey Morris <email@hidden>
- Date: Wed, 28 Nov 2012 11:49:49 -0800
On Nov 28, 2012, at 02:17 , Graham Cox <email@hidden> wrote:
> But the target index is then off by one, so it needs to be adjusted by decrementing or the moved items will end up reversed.
Yes, you and Seth are quite right, the first set will get reordered without an adjustment. So, the correct version of the loop descriptions would be:
C1. Loop over the "less than" set starting from its highest index and working down. At each iteration, move the row at the current index to the targetIndex row, and decrement targetIndex.
C2. Reset targetIndex to its original value.
C3. Loop over the "greater than" set starting from its lowest index and working up. At each iteration, move the row at the current index to the targetIndex row, and increment targetIndex.
This is comforting, in a way, because it puts symmetry back into the algorithm. :)
> That's my mental picture of the first part, but the outcome is incorrect, so either the algorithm or the implementation is wrong. The loop itself is simple, so I can't see an error there... sooo, i'm wondering if repeatedly calling the table's moveRowAtIndex:toIndex: within the same update can actually work.
It has to work, because the use of begin/endUpdates is optional. If the observed behavior is murky, you might actually want to test without the begin/endUpdates and that might clarify what's going on.
> Given that it triggers an animation which doesn't complete immediately, won't it mess up when the second move comes along, which will move again some of the same rows that got moved first time. It's not clear whether that would be handled properly - i.e. are the animations cumulative or does the last one only have an effect?
Typically, state changes at the start of animations, and the animations are playing catch-up, but of course that's no guarantee it isn't different in this case.
I'd suggest you debug this in stages:
1. Start with no begin/endUpdates.
2. Debug a single-row move.
3. Debug a double-row move (where both are below or above the target row). If there's something wrong with the algorithm, I'd expect the problem to show up here.
4. Put the begin/endUpdates back in and see what happens.
_______________________________________________
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