On Jan 13, 2014, at 9:24 AM, Markus Spoettl <ms_li...@shiftoption.com> wrote: > >> On 1/13/14 5:29 PM, Kyle Sluder 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. > > Are you sure this is how it works? Reading the constants' documentation > (especially that of UIDocumentChangeCleared) doesn't seem to imply that there > is strict counter balancing going on: > > ---------- > UIDocumentChangeCleared > The document is cleared of outstanding changes. > ---------- > > To me it more sounds like the change counter is reset, regardless of how it > got incremented.
That’s true for Cleared, but Done/Redone function as a counter increment, while Undone functions as a decrement. And remember that the undo stack persists across autosaves, so it's possible to decrement (undo) from a Cleared state. There is no guarantee that your app delegate's -applicationWillResignActive: will be called before UIDocument's implementation hears about UIApplicationWillResignActiveNotification. If UIDocument catches the notification, saves, and clears the change count, all before your code even executes, you're now stuck with a phantom +1 change count. -updateChangeCount: is intended for _wholesale replacement_ of NSUndoManager. It's not really designed to do double duty as a change counter and as a binary flag. > > Plus Mike doesn't seem to think that either (not proof of course). > >> It would be better to add a flag to your UIDocument subclass that you >> set whenever the user changes a non-undoable model property, and >> override -hasUnsavedChanges to return the OR of this property and >> super's return value. > > The point of this is I'm trying to find a way around the necessity of > tracking the settings for changes. We're talking about a bazillion of highly > complex settings objects, not just 10 bools. Also, if I did that, I could > easily use the undo manager and add appropriate changes. All any of the objects has to do is alert your document to the change. The “has non-undo-manager-tracked changes” flag is a one-way switch that you would clear in an override of -autosaveWithCompletionHandler:. FWIW, this is how all our UIDocument-based apps work. > > Of course I could overwrite -hasUnsavedChanges. But I want it to return YES > (in addition to super returning YES) if and only if the app is being > backgrounded and the system is trying to save changes as a result of that. > That requires me to know when that happens, and I don't. If you want to force a save at a specific time, call -autosaveWithCompletionHandler: directly (from within a background activity). If you want to influence the system’s autosave decisions, follow the override points rather than subverting the change counter. --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
