On 29/11/2012, at 1:18 PM, Quincey Morris <[email protected]> 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 protected]) 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 [email protected]
