Steps to Reproduce: 1. Build Apple's DepartmentAndEmployees sample project. 2. Launch it. 3. Create two documents (i.e. two departments) 4. Add an employee to Document 1. 5. Select the employee and Edit > Cut. 6. Click on the Employee table in Document 2. 7. Click Edit > Paste. Cut employee appears in Document 2. 8. Click Edit > Undo.
Although some users might expect that the employee moves from Document 2 back to Document 1, that does not happen. Because each document has its own managed object context and own undo manager, because Document 2 is active, the employee disappears from there. But order to make it reappear in Document 1, user also needs to activate Document 1 and click Edit > Undo *again*.
One could argue that there is no problem. Mac Users understand that Undo is per-document. They will instantly realize that they did two *do* operations in two different documents (Cut in Document 1, Paste in Document 2) to get where they are at, so they expect that two *undo* operations, one in each document, will be required to get back. A highly-skilled Core Data developer might even be able to set the correct undo actions, "Undo Paste Employee" and "Undo Cut Employee", which will help cue in those users with unrealistic expectations.
But this answer is not as plausible if the user makes the move using drag-drop instead of cut-paste. (Drag-drop is not implemented in DepartmentAndEmployees, but it is common in real apps.) Clearly, the user has now performed only one operation, and might rightfully expect it to be undoable with a single Undo.
I suppose that the developer of such an app could replace the undo manager in each document, upon creation or loading, with a single, common undo manager. But I fear that this would cause hundreds of unintended under-the-hood consequences in Core Data, and am loathe to think about it. Has anyone ever done this?
Another alternative: In the drag-drop implementation, before doing the *delete* operation, temporarily disable undo registration in the source document. Then, explicitly register with the undo manager of the destination document an action which would insert an object with the old object's attributes into the source document's moc. An equivalent trick would probably work in a non-Core-Data document, but I suspect that Core Data's under-hood magic wouldn't be too pleased with this.
In either case, there's the little issue of what if the source document is closed, then later this Undo action gets invoked. Setting a flag to say that "you've got Document 1's stuff on your undo stack", and removing all undo actions when Document 1 is closed would probably be a good idea, but this is starting to get messy.
Is there is a better answer? Sincerely, Jerry Krinock _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
