On 2011 Sep 26, at 03:48, Richard Somers wrote: > My rough testing of a managed object (no undo grouping) produced the > following results…
Thank you, Richard. I agree with those results. > Regarding the contents of the undo and redo stack you could inspect it's > contents using something like this… Oh, I have a better way to do peek the undo stack. I don't use NSUndoManager. Instead, I use the open-sourced GCUndoManager. GCUndoManager's stacks are public, and I have code which extracts the target, selector and arguments from the invocations which are on the stacks. Unfortunately, they're quite opaque with Core Data. > Hope this helps. Well, it looks like it's going to be a long week. By overriding -dealloc, I've confirmed that the managed object for which "Core Data cannot fulfill a fault" is not being deallocced. And just to make sure that GCUndoManager wasn't causing a problem, I #if-ed NSUndoManager back into the project and retested. But I still get the same "cannot fulfill a fault" exception in my corner case. (Also, I get additional exceptions which are due to NSUndoManager not being as smart as GCUndoManager.) * * * So I go back to my assertion that, when undoing object deletion, Core Data somehow un-faults the faulted object by re-populating it with properties it has stored in an argument of an invocation which it had earlier pushed onto the undo stack. I'm still looking for confirmation of that, and any ideas on how I might possibly by hosing that machinery. _______________________________________________ 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
