Re: Restoring unsaved docs does wrong thing
Re: Restoring unsaved docs does wrong thing
- Subject: Re: Restoring unsaved docs does wrong thing
- From: Quincey Morris <email@hidden>
- Date: Fri, 12 Apr 2013 14:16:53 -0700
On Apr 12, 2013, at 13:10 , Steve Mills <email@hidden> wrote:
> If I have an unsaved doc open in my app (I mean one that has never been saved to disk), and I kill the app, upon relaunch, the OS attempts to restore that document, but it does so incorrectly. First of all, the data was never saved by the new Cocoa autosaving mechanism (we have our own and must use it for now). Second, it creates a new untitled doc by calling our document controller's openUntitledDocumentAndDisplay method. Why would it do that? A new untitled doc with nothing in it has *nothing* to do with what might've been an untitled doc with user changes in it.
Here's how I believe it works:
-- If you have an untitled document, but the document has not been dirtied before you quit, the restore mechanism will tell you to create an untitled document when you start up again. I think the rationale here is that there's no point in wasting disk space saving anything, but you do want the window to re-appear (with restored appearance) when the app re-starts.**
-- If you have a dirty document, untitled or not, then it will always be autosaved before you quit -- *either* when the autosave timer elapsed, which might be anything from a few seconds to about 30 seconds, *or* just before quitting, if the timer hasn't fired yet. When you start up again, the documented will be opened in the usual way, and if it was previously untitled it will be untitled again. Either way, the document is *still* dirty.
IOW:
untitled + never dirtied --> no save or autosave on quit -->create untitled on start
untitled + clean --> no save or autosave on quit --> open autosave as untitled + clean on start
saved + clean -> no save or autosave on quit --> open save as saved + clean on start
untitled + dirty --> autosave on quit -> open autosave as untitled + dirty on start
saved + dirty -> autosave on quit --> open autosave as saved + dirty on start
A "regular" [non-auto-]save is done only if the user explicitly asks it for using File menu-->Save, etc.***
You have to keep in mind that the new document handling metaphor is *fundamentally* different from the old one. If you try to interpret its behavior in terms of the old metaphor, it will seem to be senseless and wrong. If you think in terms of the new metaphor, things do make sense, eventually.
In this regard, I don't think Apple did us any favors by glomming the new behavior onto the old API. It would have helped a lot if there were a a NSModernDocument class that didn't bother with API compatibility.
> Also, what should I be overriding and returning in my document subclass to ensure that the OS autosaving never happens and prevent it from trying to create new docs on launch like this?
You can just override "autosavesInPlace" to return NO, to turn off the new behavior.
It's also possible that just overriding "autosavesDrafts" to return NO might disable the untitled document behavior, if that's all you need, but the "drafts" behavior is a bit hard to follow from the documentation.
** I ran into a complication here, in a situation where a new untitled document contained the result of an import. You have to dirty the document to force an eventual autosave, but using the recommended constant for the purpose (NSChangeReadOtherContents) didn't quite produce the correct results after a quit, re-start and explicit window close, IIRC. I think I had to use the "undesirable" NSChangeDone to get this to offer to save the untitled document in all cases. But it was a while ago, and tangled up with the mysteries of drafts, so I don't remember the details.
*** If you need to know which kind of save is being done, I think the easiest way is to override one of the 'saveToURL:ofType:forSaveOperation:…' methods and look at the save operation.
_______________________________________________
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