On Jan 23, 2009, at 22:44, Jerry Krinock wrote:
I realize I could probably paper over this problem by disabling undo registration during the import
The stack trace clearly shows that an undo action is being recorded, which means that some property has been changed. ("Changed" in the sense that KVO-notifications were produced, which is what the undo mechanism notices, AFAIK. The actual values of the properties are likely irrelevant.)
Core Data is fanatically correct about recording changes as undo actions, and it's really, really difficult to find out what it thinks has changed, sometimes. It's possible that the delayed-action effect on dirtiness is a deferred processPendingChanges happening. It's possible that coalescing of changes by processPendingChanges might be suppressing change notifications.
So, disabling undo at times when you don't want any undo isn't really papering over a problem. It's more of a defense against Core-Data- induced madness.
Or, given your heroic investigations, you could almost justify submitting a bug report and hoping Apple will debug the rest of the problem for you.
Or, you could turn Core Data undo off completely, and handle undo yourself. Getting undo "for free" in Core Data is a benefit only if it causes less work for you, not more.
_______________________________________________ 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
