• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Reordering a table insanity
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

References: 
 >Reordering a table insanity (From: Graham Cox <email@hidden>)
 >Re: Reordering a table insanity (From: Quincey Morris <email@hidden>)
 >Re: Reordering a table insanity (From: Graham Cox <email@hidden>)
 >Re: Reordering a table insanity (From: Graham Cox <email@hidden>)
 >Re: Reordering a table insanity (From: Quincey Morris <email@hidden>)
 >Re: Reordering a table insanity (From: Graham Cox <email@hidden>)

  • Prev by Date: Re: Question about docs / window controllers...
  • Next by Date: Re: Reordering a table insanity
  • Previous by thread: Re: Reordering a table insanity
  • Next by thread: Re: Reordering a table insanity
  • Index(es):
    • Date
    • Thread