> 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.
You can queue up and control the undo actions in each document's undo manager. But you're still left with the problem that undo will be wired to the front most document, and there's no meta-undo manager for cross-document undo operations. I don't see how this is a Core Data issue. Either you can coordinator undos across multiple different undo managers, or you can't. Well, I suppose unless you want to have all your documents share an undo manager, which Core Data won't like. But that's crazy talk :-) As a user, I would never expect undo to go modifying the contents of other windows in a document based app. Take TextEdit for example. The behavior you suggest is completely inappropriate for TextEdit. I have separate documents because I'm working on separate things. I'd be pretty frustrated if I couldn't move things between documents without borking undo. The behavior you describe is more commonly associated with non-document apps like iCal or Address Book. They use a single undo manager for the user edits. - Ben _______________________________________________ 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
