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 (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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
