Re: Core Data: Begin+End Undo Group = Dirty Dot. Why?
Re: Core Data: Begin+End Undo Group = Dirty Dot. Why?
- Subject: Re: Core Data: Begin+End Undo Group = Dirty Dot. Why?
- From: Graham Cox <email@hidden>
- Date: Sat, 14 Nov 2009 14:41:02 +1100
On 14/11/2009, at 1:53 PM, Jerry Krinock wrote:
> - (IBAction)dooDoo:(id)sender {
> [[self undoManager] beginUndoGrouping] ;
> [[self undoManager] endUndoGrouping] ;
A known bug in NSUndoManager is that doing this records an empty undo task - the Undo menu becomes available but does nothing. Adding undo tasks dirties the document. I'm not sure if this bug is fixed in 10.6, but other changes were made to NSUndoManager so I do hope so.
> In my real app, I often manually begin and end a "super undo group".
You don't need to - the standard event loop already does that. You can record a whole series of tasks to the undo stack and if they are all submitted at the same time (meaning, within the same event cycle), they get grouped together under a single undo action.
There are not that many cases for opening your own undo groups unless you do a lot of mouse-based interaction such as dragging that you'll want to undo (because each 'step' of a drag is a different event).
> However, I don't know before it starts if any changes will be made to the store. So, in order to avoid these false dirties, the only workaround I can think of is to manually track changes (which, fortunately, I'm already doing for other reasons), and later send a -clearAllChanges if no changes occurred. Is there a less kludgey workaround?
Unfortunately I haven't found anything that isn't a kludge of equal or greater proportions for this. Rather than clearing changes after the fact, I wait until I get a task ready to be submitted to the undo manager, then make a callback to the controller which opens the group "just in time". It then knows to close it again afterwards because the other really hideous fact about NSUndoManager is that unless you are EXTREMELY careful, it's very easy to get an unbalanced group open/close situation which basically shuts down that instance of the undo manager from then on. In this sense NSUndoManager is extremely fragile, which is unfortunate as every single bit of code in an app typically calls it.
As an example, if you do open a group but subsequent code throws an exception, you better make sure you catch it and close the opened group if necessary as part of the exception handler, otherwise your app basically stops being undoable.
On more than one occasion I've been tempted to write my own undo stack from the ground up to work around these various issues. I haven't yet though - I've so far just piled on the kludges.
--Graham_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden