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: Jerry Krinock <email@hidden>
- Date: Fri, 13 Nov 2009 20:04:04 -0800
On 2009 Nov 13, at 19:41, Graham Cox wrote:
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.
Not the answer I was hoping for, but a good explanation, Graham.
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....
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).
The other case is if Core Data is involved -- see my reply to Kyle.
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".
Wow!!
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.
Graham, you'd feel right at home if you read my console logs for the
last year :))
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.
So have I, and might have actually done so were it not for the added
complication of Core Data.
So, since this is a known bug, I guess I'll get to work on my kludge.
Thanks, Graham.
Jerry
_______________________________________________
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