Re: CoreData: Using willSave to update timestamps causes hang?
Re: CoreData: Using willSave to update timestamps causes hang?
- Subject: Re: CoreData: Using willSave to update timestamps causes hang?
- From: mmalcolm crawford <email@hidden>
- Date: Mon, 2 May 2005 12:59:44 -0700
On May 2, 2005, at 9:53 AM, Jim Correia wrote:
It appears that making the change inside of willSave causes
willSave to be called again.
- (void)willSave
{
[self setValue: [NSDate date] forKey: @"lastSavedDate"];
}
- (void)willSave
{
[self setPrimitiveValue: [NSDate date] forKey: @"lastSavedDate"];
}
(Otherwise you're sending additional change notifications during
the save process.)
Should the docs make that explicit? (If so, I'm happy to write a bug.)
If I do that in my willSave method, the last saved date in the UI
doesn't update.
If I provide a didSave which does this
- (void)didSave
{
[self willChangeValueForKey: @"lastSavedDate"];
[self didChangeValueForKey: @"lastSavedDate"];
}
the UI updates, but I end up with a extra undo state that has no
visible effect in the UI. (Perhaps it is undoing the lastSavedDate
change, but the old value and the new are the same because of my
hacked didSave method.)
What is the canonical way to update timestamps or values from
didSave without ended up in a change loop and still having the
values appear in the UI?
In particular in the case of time-stamps, since these are read-only
from the UI perspective, the changes should be transparent and non-
undoable by the user.
-willSave isn't really designed for making user-visible changes in
this way. I'll file a bug report for that; please file an
enhancement request (use the feedback button) for the clarification
in the documentation.
I'd recommend against use of didSave in the way you suggest(*). A
better architecture would be to register for the relevant save
notifications and refault the objects...
mmalc
(*) If you really, really want to do this, then you could probably
get away with:
- (void)didSave
{
NSUndoManager *um = [[self managedObjectContext] undoManager];
[um disableUndoRegistration];
[self willChangeValueForKey: @"lastSavedDate"];
[self didChangeValueForKey: @"lastSavedDate"];
[um enableUndoRegistration];
}
but as you note, the old value and the new are the same in this case
which may at some stage confuse an observer that relies on a
difference.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden