Re: NSPersistentDocument: "Settings" (DepartmentsAndEmployees)
Re: NSPersistentDocument: "Settings" (DepartmentsAndEmployees)
- Subject: Re: NSPersistentDocument: "Settings" (DepartmentsAndEmployees)
- From: Quincey Morris <email@hidden>
- Date: Sat, 25 Oct 2008 09:51:42 -0700
On Oct 25, 2008, at 08:15, Jerry Krinock wrote:
- (id)initWithType:(NSString *)type error:(NSError **)error
{
self = [super initWithType:type error:error];
if (self != nil)
{
NSManagedObjectContext *managedObjectContext = [self
managedObjectContext];
[self setDepartment:[NSEntityDescription
insertNewObjectForEntityForName:@"Department"
inManagedObjectContext:managedObjectContext]];
// To avoid undo registration for this insertion,
removeAllActions on the undoManager.
// First call processPendingChanges on the managed object
context to force the undo registration
// for this insertion, then call removeAllActions.
[managedObjectContext processPendingChanges];
[[managedObjectContext undoManager] removeAllActions];
[self updateChangeCount:NSChangeCleared];
}
return self;
}
Documentation for -processPendingChanges says "causes changes to
registered managed objects to be recorded with the undo manager".
Well, since the intent is "to avoid undo registration for this
insertion", should not the -processPendingChanges message be sent
^before^ -setDepartment:? I made this change in the code, built,
tested a new document with Undo and all seems to still work fine.
The processPendingChanges method deals with changes that have already
been made, not changes that will be made.
The setDepartment call *may* register an undo action with the undo
manager, *or* create a "pending" change that the undo manager isn't
told about yet. It's an implementation detail which of the two
happens, so we don't know in any given case. If the change is
registered with the undo manager, you can just tell it to remove the
change. If the change is pending, there's no way to remove it
directly, so you must force it to be registered
(processPendingChanges) and then you can tell the undo manager to
remove it (removeAllActions).
Therefore the documented order of the calls is both correct and
required. If it seemed to work in the order you did it, it may be that
the change was registered immediately in your case, and there were no
pending changes to be taken care of.
BTW, if you want to make some changes that you don't want to be
recorded, you can also do it this way:
[managedObjectContext processPendingChanges];
[[managedObjectContext undoManager] disableUndoRegistration];
... make changes to the managed object context ...
[managedObjectContext processPendingChanges];
[[managedObjectContext undoManager] enableUndoRegistration];
But this seems less desirable in your case, IMO, because it's only
correct if you can be certain that the managed object context was not
dirtied (by some part of Core Data's internal housekeeping resulting
from opening the persistent store) before you got to initWithType.
That's not an assumption I'd like to rely on.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden