• 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: Graham Cox <email@hidden>
  • Date: Wed, 28 Nov 2012 21:17:22 +1100

On 28/11/2012, at 5:35 PM, Quincey Morris <email@hidden> wrote:

> Am I crazy or isn't it just that easy? Note that there's no adjustment of indexes necessary, other than the increment of targetIndex in C2.


Thanks for thinking about this, Seth too.

I'm pretty sure there is a solution lurking in here somewhere, but it's not quite there yet. When a table row is moved, if it moves from lower to higher, the rows ahead of targetIndex move up (or left), so iterating the "less than" items in reverse sounds right. 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. At least when I sketch each step on paper that seems to be what's needed, but in practice it's messing up, so somewhere my mental picture of the array is at odds with reality.


e.g list before:

0, 1, 2, 3, 4, 5,...

If I want to move items 0, 1 to 5 (between 4 and 5), first step I move 1 -> 5:

0, 2, 3, 4, 1, 5,...

To keep 0, 1 in their original order, the insertion index is now 4, not 5, so I move 0 -> 4:

2, 3, 4, 0, 1, 5,...

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. 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? Is there not an implicit assumption that -moveRowAtIndex:toIndex: is dealing with an adjustment of just one row of the table?

The remove/insert code I posted is correct for the reordering, and I've discovered that if I take out the -reloadData call in that code, I get the animations happening, they're just a bit crappy looking. I've added a special case for when the number of rows being moved is 1, to use the move method to get a nicer animation. That might be the best I can do, unless someone knows whether my hunch about cumulative animations is right or wrong.


--Graham

_______________________________________________

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

  • Follow-Ups:
    • Re: Reordering a table insanity
      • From: Quincey Morris <email@hidden>
    • Re: Reordering a table insanity
      • From: Quincey Morris <email@hidden>
    • Re: Reordering a table insanity
      • From: Seth Willits <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>)

  • Prev by Date: Re: Reordering a table insanity
  • Next by Date: Checking if mouse event was generated by touch
  • Previous by thread: Re: Reordering a table insanity
  • Next by thread: Re: Reordering a table insanity
  • Index(es):
    • Date
    • Thread