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 10:31:51 -0800
On Jan 13, 2014, at 9:24 AM, Markus Spoettl <email@hidden>
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 (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