On Sep 29, 2011, at 16:50 , Jerry Krinock wrote: > The -[NSManagedObjectContext undo] method […] does not get invoked when user > clicks Edit ▸ Undo in a Cocoa application.
I dunno. The issue isn't whether the method gets invoked. The issue is whether the property data that's needed to undo the deletion of an object is available after a 'save:'. I was using the documentation as evidence that it's not. (The other evidence being that your test fails 59% of the time.) > Like any normal app, my app's Edit ▸ Undo menu item targets First Responder. > A careful reading of the documentation [1] reveals that the message is > targeted to -[NSDocument undo]. There is no indication that > NSPersistentDocument overrides -undo, either in the header nor the Class > Reference document. Therefore, I don't care what -[NSManagedObjectContext > undo] says because I'm not invoking it. You misread the the first document you linked. As you correctly said: > "NSResponder declares the undoManager method for most objects that inherit > from it (namely, windows and views). When the first responder of an > application receives an undo or redo message, NSResponder goes up the > responder chain looking for a next responder that returns anNSUndoManager > object from undoManager. Any returned undo manager is used for the undo or > redo operation." > > NSDocument is in the Responder Chain and implements -undoManager; thus, > NSUndoManager gets the -undo message. So the 'undo' action message is going to end up at NSUndoManager, not NSDocument. However, I'm just being nitpicky. NSUndoManager can't undo anything, but it invokes an undo action. That action may not be (or invoke) [NSManagedObjectContext undo], but it certainly could be (or invoke) the same thing that method invokes. The point is what I said before: it sounds like the necessary property information is (deliberately) discarded by Core Data at 'save:' time. > Clearing the undo stack upon save is obviously not acceptable – I've never > seen any app do that. Believe it or not, back in Mac Classic days, it was far more usual for undo *not* to work across saves. The feature became widely available in Mac OS X because NSDocument made it easy to do. However, that doesn't necessarily mean the abomination that is NSPersistentDocument can also do it. > Clearing it only "if there are deleted objects in the picture" is not > acceptable either because that situation is when the user wants it most. Actually, where I was going with this was that there might be a workaround by *not* deleting Core Data objects in response to what the user thinks of as a delete, but simply put them in stealth mode as far as visibility to the user is concerned, and let them get garbage-collected out of existence only when no longer referenced, not even by undo actions. Even that probably sounds horrific to you, but if Core Data undo really does require the objects to *exist* in the persistent store in order to be reliably undoable, then you simply can't delete them when you, er, delete them. Anyway, only someone from Apple can now speak definitively on this issue, I think. _______________________________________________ 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
