On Nov 26, 2015, at 22:41 , Motti Shneor <su...@bezeqint.net> wrote: > > So -- I MUST warn him and allow him to cancel this quit command. > unfortunately, the @$@$@ NSDocument architecture insists I'm not to be > involved, and shortcuts even the ApplicationDelegate > "applicationShouldTerminate" for me, happily autosaving what's dirty, and > quitting immediately.
I’ve been looking into this a bit, and the situation is a bit more complicated than I thought. On re-reading the documentation, I see that the default for NSSupportsSuddenTermination is NO, so this issue is NOT caused by sudden termination. With autosavesInPlace==YES, you *do* have an opportunity to cancel app termination when there are dirty documents. I’ve just tried this in a brand new project, and it works fine. I suspect that you implemented the delegate method with the wrong signature (it has one parameter), but if not I can’t explain why the delegate method wasn’t called when you tried it. However, there is some NSDocument behavior that’s affected by the app trying to quit (i.e. terminate: being called), but not affected by whether the app actually quits. Specifically, when the app tries to quit, with autosavesInPlace==YES, the NSDocument machinery is *first* informed that the app wants to quit. At this point, it autosaves all documents, then discards all document windows and the document object itself. This is semantically *not* a close, either of the windows or the document, so none of the close machinery is invoked. This probably will surprise you, but I guess the point is that autosavesInPlace==YES *implies* that the document and its windows are restorable, and you don’t get any control over that. By the time your delegate method is called, it’s too late to prevent the document being discarded. The news isn’t completely bad, though. If a previous-saved document is discarded in this way, you can get the document back by just opening it again — it will come back still dirty, if it was before. If your app doesn’t discard the microscope state when a document disappears (which it might already, or it sounds like it could if it wanted to), then reopening the document should get the user back to where he was. In this scenario, you would discard the microscope state when the document *closes* through the regular close machinery. There are two problems with all this: 1. If the document has never been saved (is untitled), if you try to quit the app, the autosaved untitled document is written to disk, but the only way to get it back again (AFAICT) is to really quit the app and re-launch it. That means of course losing the microscope state. You might be able to mitigate this by forcing an immediate save when a new document is created, so the user never sees any untitled documents. 2. Because you’re using XXPersistentDocument, autosaving is going to be slow. I don’t see any direct solution to this, because autosavesInPlace==YES autosaving just wasn’t designed for a document based on a database. If you were using your own database directly, you could possibly arrange to do something with checkpoints or rollbacks, but I think you’re out of luck when using Core Data with the NSDocument architecture. I still think you’d be better off to look for a way to have documents that contain something like a delta to the database. Separately, you would have non-document state that kept track of the hardware state, as long as the app was running. Then, autosaving or saving the document would write the delta to disk, and closing (or discarding) the document would be recoverable. The only check you’d have to make when the document was re-opened is that the hardware state hasn’t changed since the last autosave/save. (Presumably you have some way to know when the hardware state changes, otherwise you wouldn’t be able to deal with the case where someone changes the microscope setup while a document is open and active.) I’m sure what I’m suggesting won’t actually work for you in detail, because I’m sure the details of what you’re doing are more complicated and/or more constrained. But I really don’t see a solution to your autosave/save performance issue without some way around copying the database. HTH _______________________________________________ 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
