Re: Restoring unsaved docs does wrong thing
On Apr 12, 2013, at 16:16:53, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
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 don't see an autosavesDrafts method anywhere. Ah, I just found it in
NSDocument. Strange that searching for that term in the help window didn't find
it.
I have the following overrides in my NSDocument subclass:
+(BOOL) preservesVersions
{
return NO;
}
+(BOOL) autosavesDrafts
{
return NO;
}
- (BOOL)hasUnautosavedChanges
{
// We don't do Cocoa autosaving - we do our own:
return NO;
}
- (NSString*)autosavingFileType
{
// Another way to prevent Cocoa's autosaving:
return nil;
}
Note in my original message I said kill not quit. I meant if I kill the app
from the debugger or force quit. In this case, if I had an dirty untitled
document open, the system will create new empty documents when I launch again.
How can I prevent this? The data was never saved anywhere, so opening a new
document is the wrong thing for the OS to do. The stack is shown below. I don't
see any method I can override to prevent this. I could install my own event
handler for kAEOpenApplication, but I don't know everything the default handler
does for this event, so I'd probably lose lots of standard behavior, and it
seems like overkill.
#0 0x027b237a in -[FCMacDocumentController
openUntitledDocumentAndDisplay:error:]
#1 0x99ed1998 in -[NSDocumentController
_openUntitledDocumentOfType:andDisplay:error:] ()
#2 0x99ed9834 in -[NSDocumentController
_restorePersistentDocumentWithState:completionHandler:] ()
#3 0x99eda17c in __block_global_27 ()
#4 0x99ed1ea6 in -[NSDocumentController
_waitForAsyncOpeningOrPrintingToFinishThenContinue:] ()
#5 0x99ed9ea3 in __76+[NSDocumentController
restoreWindowWithIdentifier:state:completionHandler:]_block_invoke_0 ()
#6 0x99b7cfee in -[NSApplication _whenReopeningIsAllowedDo:] ()
#7 0x99ed9dec in +[NSDocumentController
restoreWindowWithIdentifier:state:completionHandler:] ()
#8 0x99ac641d in -[NSApplication(NSPersistentUISupport)
restoreWindowWithIdentifier:state:completionHandler:] ()
#9 0x99ac5d3a in -[NSApplication(NSPersistentUISupport)
_restoreWindowWithRestoration:handler:] ()
#10 0x99ac48cd in -[NSPersistentUIManager
restoreAllPersistentStateRegisteringAsReadyWhenDone:completionHandler:] ()
#11 0x99b7af28 in -[NSApplication
_reopenWindowsAsNecessaryIncludingRestorableState:registeringAsReady:completionHandler:]
()
#12 0x99b7adf5 in -[NSApplication(NSAppleEventHandling)
_reopenWindowsIfNecessaryWithAppleEvent:completionHandler:] ()
#13 0x99b7acfa in -[NSApplication(NSAppleEventHandling)
_handleAEOpenEvent:] ()
#14 0x99b7a824 in -[NSApplication(NSAppleEventHandling)
_handleCoreEvent:withReplyEvent:] ()
#15 0x915b1628 in -[NSObject performSelector:withObject:withObject:] ()
#16 0x92f2c73a in __76-[NSAppleEventManager
setEventHandler:andSelector:forEventClass:andEventID:]_block_invoke_0 ()
#17 0x92f2c291 in -[NSAppleEventManager
dispatchRawAppleEvent:withRawReply:handlerRefCon:] ()
#18 0x92f2c08e in _NSAppleEventManagerGenericHandler ()
#19 0x90523a35 in aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned
long, unsigned char*) ()
#20 0x904f8fbe in dispatchEventAndSendReply(AEDesc const*, AEDesc*) ()
#21 0x904f8e7d in aeProcessAppleEvent ()
#22 0x90170c58 in AEProcessAppleEvent ()
#23 0x99b76d4d in _DPSNextEvent ()
#24 0x99b761dc in -[NSApplication
nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#25 0x99b6c63c in -[NSApplication run] ()
#26 0x99b0f666 in NSApplicationMain ()
#27 0x01309368 in main
--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157
___
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
Re: Restoring unsaved docs does wrong thing
On Apr 15, 2013, at 4:49 PM, Steve Mills smi...@makemusic.com wrote: I don't see an autosavesDrafts method anywhere. Ah, I just found it in NSDocument. Strange that searching for that term in the help window didn't find it. It might be that your Xcode doc window is searching the 10.7 docset. The autosavesDrafts method is 10.8-only. In the search field in Xcode doc window, hit the little magnifying glass and select Show Find Options. There will be a Find in popup menu showing which docsets are being searched. --Andy ___ 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
Re: Restoring unsaved docs does wrong thing
Hi Steve, On Apr 12, 2013, at 1:10 PM, 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. If the app unexpectedly crashed or was killed, the system will make a best-effort to restore state. If the document was never saved, the best it can do is recreate an Untitled document. 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 mark a window as not restorable in the xib, or by calling [window setRestorable:NO] Hope that helps, -Peter ___ 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
Re: Restoring unsaved docs does wrong thing
On Apr 15, 2013, at 16:06:51, Andy Lee ag...@mac.com wrote: On Apr 15, 2013, at 4:49 PM, Steve Mills smi...@makemusic.com wrote: I don't see an autosavesDrafts method anywhere. Ah, I just found it in NSDocument. Strange that searching for that term in the help window didn't find it. It might be that your Xcode doc window is searching the 10.7 docset. The autosavesDrafts method is 10.8-only. Ah, that explains it. Thanks. -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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
Re: Restoring unsaved docs does wrong thing
On Apr 15, 2013, at 13:49 , Steve Mills smi...@makemusic.com wrote: I have the following overrides in my NSDocument subclass: […] You didn't mention autosavesInPlace. This is the one to override if you don't want any (new-style) autosaving. The data was never saved anywhere, so opening a new document is the wrong thing for the OS to do. No, that's not true when autosavesInPlace is YES. In that case, if the app has a window open when it quits, it should and will open a window when it re-starts. If autosave has never completed, it'll be a new, untitled window. Having said that, things get a bit more complicated when you kill the app during debugging. It's a bit unpredictable what restorable state has been saved, and whether it'll successfully restore. You can turn off the Launch application without state restoration option in the Run action of the scheme, which make help you out during debugging, though that of course won't prevent the behavior in normal usage for your users. ___ 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
Restoring unsaved docs does wrong thing
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. 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? -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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
Re: Restoring unsaved docs does wrong thing
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
