> On Nov 23, 2015, at 09:23, Quincey Morris 
> <quinceymor...@rivergatesoftware.com> wrote:
> 
> On Nov 22, 2015, at 22:41 , Motti Shneor <su...@bezeqint.net 
> <mailto:su...@bezeqint.net>> 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 (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

Reply via email to