Re: NSDocument -canCloseDocumentWithDelegate::: not called when terminating
Re: NSDocument -canCloseDocumentWithDelegate::: not called when terminating
- Subject: Re: NSDocument -canCloseDocumentWithDelegate::: not called when terminating
- From: Kyle Sluder <email@hidden>
- Date: Mon, 23 Jul 2012 09:53:18 -0700
On Jul 23, 2012, at 9:06 AM, Kevin Perry <email@hidden> wrote:
> I can't really recommend an approach that essentially lies about the "dirty" state of a document. If you have something to write into the document bundle, then the document is dirty and it should be declared so with the available NSDocument APIs. If the existing APIs don't meet your needs for whatever reason, file an enhancement request.
What about overriding -hasUnautosavedChanges to return YES, and also calling -scheduleAutosaving whenever the preference state changes?
Marking the document edited just because the user has scrolled the content area is a poor user experience, and making such a change undoable is even worse.
We're hoping to move as much of this editor state information as possible to use NSWindowRestoration, but there are still a few places where the line between discardable visual configuration and semantically meaningful state is blurry. Is the currently-selected document in an OmniGraffle document meaningful? After all, you can configure shapes to switch canvases when you click on them.
>
> To answer your question more directly—there is no public callback that is invoked in every case on Quit when the document returns NO from -isDocumentEdited or -hasUnautosavedChanges. In fact, sometimes nothing gets invoked at all because when -isDocumentEdited returns NO, NSDocument enables sudden termination, which allows -[NSApplication terminate:] to take shortcuts and Shutdown/Restart/Logout to kill the app.
Perhaps in addition to the above, Markus could also disable sudden termination before calling -scheduleAutosaving, and re-enable it in an override of one of the save methods.
--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