• 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: Thu, 29 Nov 2012 13:53:49 +1100

On 29/11/2012, at 1:18 PM, Quincey Morris <email@hidden> wrote:

> If I understand you correctly, then it can't be done without an extra parameter. The "coordinate system" of the indexes in *both* index sets is that of the original list. When you're undoing, all of the indexes in both index sets are "wrong" for the current state of the table. Even if the "right" indexes could be recovered, which I'm not sure about but perhaps, you still wouldn't know whether to do the recovery.


I don't think that is right - though I will muse on it some more.

The number of items in the table hasn't changed (such add/remove changes are themselves undoable, so when an undo is called for, the state of the table is exactly as it was just after the original change).

I can see that using the adjusted (offset) table might be a problem if that's what is stored by the undo manager, because the original value of the offset can't be recovered, maybe that's what you're thinking about?

But suppose the two index sets are "absolute" in that there is not yet any adjustment to either of them. Then the indexes they refer to are absolutely referring to the table rows - there is a 1:1 correspondence between the order of indexes in the two sets representing source and dest rows, in absolute terms, before and after the move. Thus, by swapping the tables on undo, the move is reversed. The destination index set can be thought of as a list of where I want each index in the source set to end up, so if these two sets are flipped having made the change, the source list is now where the items got moved to, and the dest list is where they originally came from, with a 1:1 correspondence.

Right now I pass the undo manager the adjusted index set. Undo works fine and fully as long as I don't attempt to move the table rows one by one, but use the delete/insert approach. That seems to indicate that two index sets are enough information to implement undo correctly.

--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>
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>)
 >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: 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: Quincey Morris <email@hidden>)

  • Prev by Date: Re: Reordering a table insanity
  • 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