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 protected] 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 protected]) > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/kperry%40apple.com > > This email sent to [email protected] _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
