On 2011 Sep 30, at 00:06, Quincey Morris wrote: > However, there are a number of well-known examples of outrageousness. The > most relevant one that I can think of is that NSPersistentDocument was > originally released without (and may still not have, for all I know) support > for NSDocument's "Save To…" behavior, as well as "Save As…" behavior that > (apparently) went only as far as a successful default migration could carry > it.
and then there's the outrageousness that, when you 'Revert' an NSPersistentDocument, unlike NSDocument, it closes and re-opens the window. I wish Quincey was wrong but I'm afraid he's correct. * * * Oh, another thing. Although my app is using Autosave in Place and Asynchronous Saving, the problem persists if I switch these off. As it turns out, though, Asynchronous Saving + NSPersistentDocument is *another* issue. * * * I'm still working on this issue, trying to find the trigger which moves my corner case into the corner, hoping for a workaround. It's tedious because of different operations and states. Repeating what I've already posted, • There is a chance that it could still be my code. • The deleted objects are definitely *not* being deallocced. • There are no object attributes in the invocations on the undo stack. • The heavy lifting is apparently done by -[NSManagedObjectContext _undoUpdates]. The implication of the last two points is that Core Data implements Undo quite on its own; the undo manager acts as little more than a counter. Of course, if I can find a workaround and/or isolate to a demo I shall post, file a bug, etc.. _______________________________________________ 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
