Re: Telling Auto Save, "No, I'm busy now"
Re: Telling Auto Save, "No, I'm busy now"
- Subject: Re: Telling Auto Save, "No, I'm busy now"
- From: Kevin Perry <email@hidden>
- Date: Mon, 1 Aug 2011 08:14:37 -0700
AppKit-initiated autosaves generally happen for two main reasons: the autosave timer, and file coordination. These are both initiated with -autosaveWithImplicitCancellability:completionHandler:. The "implicitly cancelable" flag indicates whether it's appropriate for an NSDocument subclass to cancel an autosave (with an NSUserCancelled NSError, as you've discovered). Timer-initiated autosaves are cancelable (up to a certain limit), and you can detect this by calling -autosavingIsImplicitlyCancellable. Canceling an autosave when -autosavingIsImplicitlyCancellable returns NO will cause problems with file coordination.
If you absolutely cannot save when a non-cancellable autosave starts, it is OK to defer the autosave until you're ready, as long as you make sure to call the original completionHandler when you're done. There are consequences to this though. Not only will your application be blocked until the completionHandler is called, but you will cause other applications using File Coordination on your document's file to wait longer as well.
-KP
On Jul 30, 2011, at 6:41 PM, Jerry Krinock wrote:
>
> On 2011 Jul 30, at 15:39, email@hidden wrote:
>
>> You're lying to the save machinery by saying that you have saved, when you have not. So NSFileCoordinator will then think your file is up to date, and let others read (or write) it. It could lead to all sorts of nasty behaviors…
>
> Thank you, Wade. Yes, that's a good point.
>
>> What you should be doing is deferring the save - just hang on to 'completionHandler', queue up the save for the next available opportunity, and invoke the handler after the save really happens.
>
> OK, but I thought of an easier solution. Replace this line of code
>
> completionHandler(nil) ;
>
> which told the system that I had saved with no error, with this:
>
> completionHandler([NSError errorWithDomain:NSCocoaErrorDomain
> code:NSUserCancelledError
> userInfo:nil]) ;
>
> Now I'm not lying to Mother any more. And because this particular error domain/code is documented to not be displayed (see -Document-Based Applications Overview â–¸ Error Handling in the Document Architecture), the user doesn't get any crap.
>
> Indeed, the behavior is a little different now. Instead of waiting 10-15 seconds after my operations are completed, now the Auto Save happens immediately after my operations are completed. This implies that the system now knows that it has unsaved data, and so it kicks in more aggressively.
>
> I like it better now. But it still seems that Apple should document the correct way to handle this situation.
>
>> you're in the middle of applying a user action, one that has been expressly approved and is merely taking some time
>
> Yes, that is the situation.
>
> _______________________________________________
>
> 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
_______________________________________________
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