On Apr 12, 2013, at 13:10 , Steve Mills <smi...@makemusic.com> 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 (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
