Re: Grouping undo-able actions with CoreData
Re: Grouping undo-able actions with CoreData
- Subject: Re: Grouping undo-able actions with CoreData
- From: John Timmer <email@hidden>
- Date: Wed, 25 May 2005 18:32:00 -0400
Title: Re: Grouping undo-able actions with CoreData
Thanks for pointing me in the right direction on this. Now if I could only
sort out the undo menu enabling issue....
Are you using setPrimitiveValue:forKey: without wrapping it in willChange/didChange invocations? If so, you will get neither undo registration nor KVO notifications for those changes. The undo menu won't be enabled if there's nothing on the undo stack, so this could explain the behavior you're seeing.
No, I’ve been careful with that in all my classes. Besides, in my testing, I’m creating something like 35 items and setting an average of about 5 values in each – there’s no way I could have screwed up and skipped the change invocations that many times. Regardless, it’s all perfectly undoable, it’s just that something else has to wake up the undo system first, because the menu item doesn’t get enabled following my object creation binge. As soon as any action gets the undo menu activated, all 35 are nicely undoable in a single command-Z. As I said in my previous mail, some actions seem to trigger the menu item enabling, others don’t, but everything’s undoable once it’s enabled. The undo stack’s being managed properly, but the menu management isn’t.
I’m going to try moving the project over to a different machine and seeing if the problem persists there – maybe it’s some weird cruft left over from all the developer seeds.
JT
_______________________________________________
This mind intentionally left blank
_______________________________________________
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