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

Reply via email to