Re: Mixing UIDocument's NSUndoManager and -updateChangeCount:
Re: Mixing UIDocument's NSUndoManager and -updateChangeCount:
- Subject: Re: Mixing UIDocument's NSUndoManager and -updateChangeCount:
- From: Kyle Sluder <email@hidden>
- Date: Mon, 13 Jan 2014 12:13:29 -0800
On Mon, Jan 13, 2014, at 12:08 PM, Mike Abdullah wrote:
> > This does not strike me as a good idea. -updateChangeCount: is a
> > counter; adding a place that increments the counter without having a
> > corresponding decrement sounds like an invitation for state corruption,
> > particularly in the presence of framework code that treats the counter
> > as normal.
>
> You’ve got a good point here. Consider the steps of:
>
> 1. Make change, with corresponding undo registration
> 2. Update document change count
> 3. Undo, twice
>
> The change counter is now back at where it was at the start, probably
> leading the document to believe it has no unsaved changes, when in
> reality, the undo manager has actually wound back to some earlier state
> before step 1.
>
> So that does suggest mixing undo manager and manual change counting isn’t
> a good idea.
Theoretically, this wouldn't be an issue in Markus's original case,
since he's only incrementing the change count immediately before an
autosave that would clear the change count.
But realistically, there is no guarantee that Markus's code will run
before the autosave, so he might be incrementing the change count
_after_ the autosave. Or, possibly worse, UIDocument could skip the
autosave, because -hasUnsavedChanges returned NO from within
UIDocument's notification handler, and then Markus's code could run.
But it's just generally a bad practice to violate the framework's stated
assumptions. -updateChangeCount: manages a change counter, not a "force
saving" flag. There's a very clear way to implement a "force saving"
flag that fits within the framework design. The existence of that option
should be entirely sufficient to discount all other approaches.
--Kyle Sluder
_______________________________________________
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