Re: canAsynchronouslyWriteToURL:ofType:forSaveOperation: Prevent Quit?
On 20 Apr 2014, at 19:58, Trygve Inda cocoa...@xericdesign.com wrote: I return YES from canAsynchronouslyWriteToURL:ofType:forSaveOperation: Which works fine, but the user is able to quit the app while the save is in progress. Is there way way to know when the save is complete so that I can prevent quit before the save ends? If you play by NSDocument’s rules, the won’t actually terminate until saving is finished. How have you determined that this is not the case for your app? Is your save process doing anything weird? ___ 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: canAsynchronouslyWriteToURL:ofType:forSaveOperation: Prevent Quit?
On 20 Apr 2014, at 19:58, Trygve Inda cocoa...@xericdesign.com wrote:
I return YES from
canAsynchronouslyWriteToURL:ofType:forSaveOperation:
Which works fine, but the user is able to quit the app while the save is in
progress. Is there way way to know when the save is complete so that I can
prevent quit before the save ends?
If you play by NSDocument’s rules, the won’t actually terminate until saving
is finished. How have you determined that this is not the case for your app?
Is your save process doing anything weird?
If I start a save and quit immediately, the file is not written. In my
Document class I override:
-(NSFileWrapper *)fileWrapperOfType:(NSString *)typeName error:(NSError
**)outError
{
if ([self documentFileWrapper] == nil)
[self setDocumentFileWrapper:[self createPackageDirectoryStructure]];
...
[self unblockUserInteraction];
return documentFileWrapper;
}
-(BOOL)canAsynchronouslyWriteToURL:(NSURL *)url ofType:(NSString *)typeName
forSaveOperation:(NSSaveOperationType)saveOperation
{
return YES;
}
___
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: canAsynchronouslyWriteToURL:ofType:forSaveOperation: Prevent Quit?
Do you override any other NSDocument saving methods? I believe NSDocument’s
internal use of -performAsynchronousFileAccess… should cause it to delay
NSApplication termination.
--Kyle Sluder
On Apr 20, 2014, at 1:01 PM, Trygve Inda cocoa...@xericdesign.com wrote:
On 20 Apr 2014, at 19:58, Trygve Inda cocoa...@xericdesign.com wrote:
I return YES from
canAsynchronouslyWriteToURL:ofType:forSaveOperation:
Which works fine, but the user is able to quit the app while the save is in
progress. Is there way way to know when the save is complete so that I can
prevent quit before the save ends?
If you play by NSDocument’s rules, the won’t actually terminate until saving
is finished. How have you determined that this is not the case for your app?
Is your save process doing anything weird?
If I start a save and quit immediately, the file is not written. In my
Document class I override:
-(NSFileWrapper *)fileWrapperOfType:(NSString *)typeName error:(NSError
**)outError
{
if ([self documentFileWrapper] == nil)
[self setDocumentFileWrapper:[self createPackageDirectoryStructure]];
...
[self unblockUserInteraction];
return documentFileWrapper;
}
-(BOOL)canAsynchronouslyWriteToURL:(NSURL *)url ofType:(NSString *)typeName
forSaveOperation:(NSSaveOperationType)saveOperation
{
return YES;
}
___
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: canAsynchronouslyWriteToURL:ofType:forSaveOperation: Prevent Quit?
On Apr 20, 2014, at 13:34 , Kyle Sluder k...@ksluder.com wrote: Do you override any other NSDocument saving methods? Also, there *may* be a relevant interaction between ‘terminate:’, sudden termination and automatic termination, even though technically they’re separate things. Opting in to the latter two, if you haven’t done so already, might improve the saving situation. ___ 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: canAsynchronouslyWriteToURL:ofType:forSaveOperation: Prevent Quit?
Do you override any other NSDocument saving methods? I believe NSDocument’s
internal use of -performAsynchronousFileAccess… should cause it to delay
NSApplication termination.
--Kyle Sluder
My Document class contains:
//Read File Package
-(BOOL)readFromFileWrapper:(NSFileWrapper *)fileWrapper ofType:(NSString
*)typeName error:(NSError **)outError;
//Write File Package
-(NSFileWrapper *)fileWrapperOfType:(NSString *)typeName error:(NSError
**)outError;
-(BOOL)canAsynchronouslyWriteToURL:(NSURL *)url ofType:(NSString *)typeName
forSaveOperation:(NSSaveOperationType)saveOperation;
-(void)setFileURL:(NSURL *)absoluteURL;
SetFileURL looks like:
-(void)setFileURL:(NSURL *)absoluteURL
{
[super setFileURL:absoluteURL];
if ([self documentFileWrapper])
[documentFileWrapper readFromURL:absoluteURL options:0 error:NULL];
}
If I choose save and immediately close the document, it closes right away
but the file still gets written a few moments later.
However, if I choose save and immediately quit, it quits without writing the
file.
T.
___
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: canAsynchronouslyWriteToURL:ofType:forSaveOperation: Prevent Quit?
Do you override any other NSDocument saving methods? I believe NSDocument’s
internal use of -performAsynchronousFileAccess… should cause it to delay
NSApplication termination.
--Kyle Sluder
On Apr 20, 2014, at 1:01 PM, Trygve Inda cocoa...@xericdesign.com wrote:
On 20 Apr 2014, at 19:58, Trygve Inda cocoa...@xericdesign.com wrote:
I return YES from
canAsynchronouslyWriteToURL:ofType:forSaveOperation:
Which works fine, but the user is able to quit the app while the save is in
progress. Is there way way to know when the save is complete so that I can
prevent quit before the save ends?
If you play by NSDocument’s rules, the won’t actually terminate until saving
is finished. How have you determined that this is not the case for your app?
Is your save process doing anything weird?
If I start a save and quit immediately, the file is not written. In my
Document class I override:
-(NSFileWrapper *)fileWrapperOfType:(NSString *)typeName error:(NSError
**)outError
{
if ([self documentFileWrapper] == nil)
[self setDocumentFileWrapper:[self createPackageDirectoryStructure]];
...
[self unblockUserInteraction];
return documentFileWrapper;
}
-(BOOL)canAsynchronouslyWriteToURL:(NSURL *)url ofType:(NSString *)typeName
forSaveOperation:(NSSaveOperationType)saveOperation
{
return YES;
}
A small correction... This seems to only happen when I do a Save As. If
the file is dirty and I do a Save, the file is dirty warning catches the
quit.
However, a clean file (freshly saved) doing a Save As, has nothing that
prevents a quit in the middle of the save.
___
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: canAsynchronouslyWriteToURL:ofType:forSaveOperation: Prevent Quit?
On Apr 20, 2014, at 4:29 PM, Trygve Inda cocoa...@xericdesign.com wrote: A small correction... This seems to only happen when I do a Save As. If the file is dirty and I do a Save, the file is dirty warning catches the quit. Does the bad behavior also apply to Save if you turn off the “Close all windows when quitting apps” option in System Preferences? --Kyle Sluder Yes - it quits regardless of that setting. T. ___ 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: canAsynchronouslyWriteToURL:ofType:forSaveOperation: Prevent Quit?
On Apr 20, 2014, at 6:58 PM, Trygve Inda cocoa...@xericdesign.com wrote: On Apr 20, 2014, at 4:29 PM, Trygve Inda cocoa...@xericdesign.com wrote: A small correction... This seems to only happen when I do a Save As. If the file is dirty and I do a Save, the file is dirty warning catches the quit. Does the bad behavior also apply to Save if you turn off the “Close all windows when quitting apps” option in System Preferences? --Kyle Sluder Yes - it quits regardless of that setting. What I'm asking is whether turning that setting off causes Save to exhibit the same behavior as Save As—in other words, are you only seeing a difference in behavior because your machine happens to be configured in a way that involves NSApplication's consult-the-dirty-documents codepath? And in that vein, have you subclasses NSApplication at all, implemented -[NSApplicationDelegate applicationShouldTerminate:] and/or sent -replyToApplicationShouldTerminate: to NSApp, or taken over termination yourself? --Kyle Sluder ___ 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: canAsynchronouslyWriteToURL:ofType:forSaveOperation: Prevent Quit?
On Apr 20, 2014, at 6:58 PM, Trygve Inda cocoa...@xericdesign.com wrote:
On Apr 20, 2014, at 4:29 PM, Trygve Inda cocoa...@xericdesign.com wrote:
A small correction... This seems to only happen when I do a Save As. If
the file is dirty and I do a Save, the file is dirty warning catches
the
quit.
Does the bad behavior also apply to Save if you turn off the “Close all
windows when quitting apps” option in System Preferences?
--Kyle Sluder
Yes - it quits regardless of that setting.
What I'm asking is whether turning that setting off causes Save to exhibit the
same behavior as Save As—in other words, are you only seeing a difference in
behavior because your machine happens to be configured in a way that involves
NSApplication's consult-the-dirty-documents codepath?
And in that vein, have you subclasses NSApplication at all, implemented
-[NSApplicationDelegate applicationShouldTerminate:] and/or sent
-replyToApplicationShouldTerminate: to NSApp, or taken over termination
yourself?
--Kyle Sluder
Changing the System prefs checkbox does not affect Save or Save As.
In a Save the dirty mark is not cleared until the file is written, thus it
asks before quitting about saving the document.
My app delegate for termination looks like:
-(BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication
*)theApplication
{
return NO;
}
-(void)applicationWillTerminate:(NSNotification *)aNotification
{
[self quitApplicationWithBundleIdentifier:myHelperAppBundleIdentifier];
[[NSUserDefaults standardUserDefaults] synchronize];
}
-(void)quitApplicationWithBundleIdentifier:(NSString *)identifier
{
NSArray* appArray = [NSRunningApplication
runningApplicationsWithBundleIdentifier:identifier];
for (NSRunningApplication* process in appArray)
[process terminate];
}
___
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: canAsynchronouslyWriteToURL:ofType:forSaveOperation: Prevent Quit?
On Apr 20, 2014, at 10:11 PM, Trygve Inda cocoa...@xericdesign.com wrote:
On Apr 20, 2014, at 6:58 PM, Trygve Inda cocoa...@xericdesign.com wrote:
On Apr 20, 2014, at 4:29 PM, Trygve Inda cocoa...@xericdesign.com wrote:
A small correction... This seems to only happen when I do a Save As. If
the file is dirty and I do a Save, the file is dirty warning catches
the
quit.
Does the bad behavior also apply to Save if you turn off the “Close all
windows when quitting apps” option in System Preferences?
--Kyle Sluder
Yes - it quits regardless of that setting.
What I'm asking is whether turning that setting off causes Save to exhibit
the
same behavior as Save As—in other words, are you only seeing a difference in
behavior because your machine happens to be configured in a way that involves
NSApplication's consult-the-dirty-documents codepath?
And in that vein, have you subclasses NSApplication at all, implemented
-[NSApplicationDelegate applicationShouldTerminate:] and/or sent
-replyToApplicationShouldTerminate: to NSApp, or taken over termination
yourself?
--Kyle Sluder
Changing the System prefs checkbox does not affect Save or Save As.
In a Save the dirty mark is not cleared until the file is written, thus it
asks before quitting about saving the document.
Well, the reason I asked about that checkbox is that if it's unchecked, AppKit
might not look at dirty windows *at all* during termination. Unchecking that
box actually has the effect of telling AppKit to autosave all documents at Quit
and restore them on the next launch. (This is the behavior AppKit performs when
background-terminating or being asked to terminate because the system is
logging out—assuming the user also chose “Restore windows at login” on the
logout confirmation panel.)
Come to think of it, does your app adopt Lion Autosave?
My app delegate for termination looks like:
-(BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication
*)theApplication
{
return NO;
}
-(void)applicationWillTerminate:(NSNotification *)aNotification
{
[self quitApplicationWithBundleIdentifier:myHelperAppBundleIdentifier];
[[NSUserDefaults standardUserDefaults] synchronize];
}
-(void)quitApplicationWithBundleIdentifier:(NSString *)identifier
{
NSArray* appArray = [NSRunningApplication
runningApplicationsWithBundleIdentifier:identifier];
for (NSRunningApplication* process in appArray)
[process terminate];
}
Hmmm… I’m assuming these are not the problem. But just for laughs, maybe try
taking this code out and see if you have the same issue.
Otherwise, it might be time to file a Radar and/or a DTS incident.
--Kyle Sluder
___
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: canAsynchronouslyWriteToURL:ofType:forSaveOperation: Prevent Quit?
On Apr 20, 2014, at 22:26 , Kyle Sluder k...@ksluder.com wrote: In a Save the dirty mark is not cleared until the file is written, thus it asks before quitting about saving the document. Come to think of it, does your app adopt Lion Autosave? The implication of “dirty mark” — if taken literally — is that this is pre-Lion NSDocument behavior. The newer behavior has “Edited” text in the title bar, of course, and no mark in the close button. Perhaps that’s why it’s not behaving as expected on quitting — the deferral of termination may happen only with “modern” NSDocument behavior. Unfortunately, trying to predict the effects of implementing various combinations of the various overrides, return values and miscellaneous dreck that’s accumulated in NSDocument API since 10.5 is probably beyond the ability of mere mortals. ___ 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
