On May 2, 2005, at 3:59 PM, mmalcolm crawford wrote:
-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.
mmalc,
Thanks for your help.
The documentation enhancement/clarification request is <rdar://4106260>.
Is there a recommended way for keeping a last saved date attached to
individual entities then? The last saved date may or may not be
displayed in the UI at any given time.
If I change the requirements to be the last edit time, I suppose I
could catch the edits via a setValue:forKey override and make sure
the key isn't the timestamp key (and that we aren't in the middle of
an undo or redo.) Are there gotchas with this approach? Bad idea?
Anyone doing something similar?
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...
This causes the UI to refresh, but I still end up with a phantom undo
state. (Is there a good bottleneck to set a breakpoint so I can watch
CoreData register undos, and do/undo them to understand what is going
on when I encounter a "phantom" undo state?)
Thanks,
Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden
