The calls are on the Will/Did undo/redo notifications not the KVO
callbacks on object changes.
I can account for the number of undo entries (the menu item disables
at the right time), but would not mind pointers on how to detect what
the undo changes. I am not getting notifications from the managed
object context for object changes, but that is probably me not doing
something right.
What I am seeing is that my code changes a managed object property, I
undo, and no change occurs in the managed object. The property
affected is a binary attribute (a CATransform3D as bytes).
I am looking at the object state before and after the undo using the
Will/Did notifications for the undo manager. Is it possible that
either a) I am interfering with the undo manager because of the logic
running in the notifications, or b) is it possible the changes are
delayed to after the notifications? The undo behaves the same as
before I added any notification processing however.
Michael
On Mar 5, 2008, at 6:31 PM, Ben Trumbull wrote:
I call processPendingChanges from both the *Will* and *Did*
notifications.
Please stop. It doesn't make sense for the context to coalesce
pending changes in the middle of the change to a single object
during the KVO callbacks.
Your original problem description is a bit sparse. Common problems
that produce that symptom are people doing things in a managed
object's initializer they shouldn't, people doing things in -
awakeFromInsert/Fetch they shouldn't, or the undo stack having more
entries on it than they expect (i.e. undo works just fine, but the
stack isn't coalesced as the user expects)
--
-Ben
_______________________________________________
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 [EMAIL PROTECTED]
