On Apr 23, 2013, at 17:39:17, Mike Abdullah <[email protected]> wrote:
> -hasUnautosavedChanges continues to be applicable to all (auto)saving models. > > I caution against overriding it since: > > A) Your override is likely a lie to the system when you get down to it. This > might upset the state for other bits of the system > B) A perfectly good system for backing out of non-essential autosaves already > exists, and should be used instead Then why would hasUnautosavedChanges be exposed publicly with no documentation that says overriding it is a bad idea? > If you read the docs for > -autosaveWithImplicitCancellability:completionHandler: *its* implementation > calls -hasUnautosavedChanges. It will back out without doing any work should > the document claim not to have any unautosaved changes. Yes, but if hasUnautosavedChanges returns NO, then autosaveWithImplicitCancellability won't autosave. I don't see what difference it makes which one I override, except hasUnautosavedChanges is a much simpler method to understand and override. > I suspect that if you do override -hasUnautosavedChanges, a call to > -scheduleAutosaving would be needed — at least under some circumstances — to > restart autosave when you’re ready. Not from my tests. If I cause an autosave to happen before I pause it locally, then later when it's resumed, any dirtying of the document is all that is needed to cause an autosave to fire again when the autosave time interval has elapsed. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
