Re: Bunch of CoreData based NSDocument questions.
Re: Bunch of CoreData based NSDocument questions.
- Subject: Re: Bunch of CoreData based NSDocument questions.
- From: Motti Shneor <email@hidden>
- Date: Mon, 23 Nov 2015 22:50:00 +0200
> On Nov 23, 2015, at 09:23, Quincey Morris <email@hidden> wrote:
>
> On Nov 22, 2015, at 22:41 , Motti Shneor <email@hidden <mailto:email@hidden>> wrote:
>
>> I wish I knew enough to write my own MyPersistentDocument
>
> The problem is that the way NSDocuments are used is semantically different from the way databases are used, and you *cannot* reconcile the two across all the functions on the NSDocument-based File menu. (This was an old discussion.)
Any references to that old discussion? I’d like to read it. However, I think there should be a reasonable way to provide close-enough interpretation to NSDocument’s view of documents using CoreData's persistence. Database here is only means for partial saving of changes, without re-serializing the whole document. In the past there was a whole genre of applications who worked with very little Memory, by doing the same thing - reading small parts of their document into memory, and writing small changes to the document one at a time. Surely, the Document architecture acknowledges such applications.
>
>> Problem is - the application quits immediately even when there are dirty documents open!!! the @#$@#$ document "architecture" feels free to quit because all has been "AutoSaved". not "Saved". I just want the old behavior - you should not be able to quit with dirty documents. That's all.
>
> You are probably falling foul of Sudden Termination:
>
> https://developer.apple.com/library/prerelease/watchos/documentation/Cocoa/Reference/Foundation/Classes/NSProcessInfo_Class/#//apple_ref/doc/uid/20000316-SW3 <https://developer.apple.com/library/prerelease/watchos/documentation/Cocoa/Reference/Foundation/Classes/NSProcessInfo_Class/#//apple_ref/doc/uid/20000316-SW3>
> You can try opting out of this completely, or opting out temporarily. Or possibly the change count type I suggested doesn’t cause the opt-out behavior in NSDocument, in which case you could try NSDocumentChangeDone instead. Or possibly the change count has to be updated later.
>
Just turned off sudden-termination for my App (setting NSSupportsSuddenTermination to “NO” in my info.plist) to no avail.
My issue seems different, and can also be easily reproduced in other apps (e.g. TextEdit). Quitting it with a dirty document will quit immediately, and on next launch the document will be open with all last-session’s changes, and the dirty flag on. The last autosaved state can be used to “Save” the changes from previous session.
I found this in NSDocument.h
The default implementation of this method has two rather different behaviors. If [[self class] autosavesInPlace] returns YES and [self fileURL] returns non-nil then it simply invokes [self autosaveWithImplicitCancellability:NO completionHandler:aCompletionHandler] if [self hasUnautosavedChanges] returns YES after making sure that any editor registered using Cocoa Bindings' NSEditorRegistration informal protocol has committed its changes. Otherwise it presents a panel giving the user the choice of canceling, discarding changes, or saving. In that case the shouldClose value passed to the delegate will be YES if the document was not modified in the first place, or the user chose to discard modifications, or chose to save and the saving was successful. NO will be passed if the user chose to cancel the operation or saving was unsuccessful. Because -saveDocumentWithDelegate:didSaveSelector:contextInfo: is used, an alert panel will be presented before the delegate is messaged if saving is attempted but does not succeed.
*/
- (void)canCloseDocumentWithDelegate:(id)delegate shouldCloseSelector:(SEL)shouldCloseSelector contextInfo:(void *)contextInfo;
While BSManagedDocument open source class I’m using implements this method, It is never called in my app. I set up a breakpoints, and added NSLog lines - it’s never called, no matter what.
I may be plain stupid, but I can’t understand the above description especially in my context. I can’t even make the break into the “two rather different behaviors”. Could anyone please shed light on this?
Details of my application:
1. autoSavesInPlace returns YES;
2. [self fileURL] will also return non-nil object.
3. [self hasUnautosavedChanges] will probably return NO
4. I have 2 (or more window controllers with their windows open), only one - main window - will return YES for closing the document when it is closed.
_______________________________________________
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