> - (void)saveToURL:(NSURL *)url
> ofType:(NSString *)typeName
> forSaveOperation:(NSSaveOperationType)saveOperation
> completionHandler:(void (^)(NSError *errorOrNil))completionHandler {
> if (saveOperation == NSAutosaveInPlaceOperation) {
> if ([[[NSOperationQueue mainQueue] operations] count] != 0) {
> // "No, I'm busy now"
>
> // If you don't do this, it hangs forever…
> completionHandler(nil) ;
>
> return ;
> }
> }
That doesn't seem right at all. I haven't played with autosaving that much
yet, but as I understand it, your document will be told to auto-save in a
variety of situations - such as when another application wants to read the
document on disk, which could be a consequence of the user dragging and
dropping the document into e.g. Mail, as an attachment.
The point is to ensure that what's on disk is the latest copy; what the user is
seeing. 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
behaviours.
It may also confuse NSDocument's internal change management machinery; the
NSDocument will think it's saved, but it's not. It may show the document as
unmodified even though in-memory changes have not been persisted to disk. That
could in turn have consequences of data loss if sudden application termination
is in play.
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.
You mentioned in a separate message that you're using NSOperations - could you
not just add another operation to the end of your operation graph, that
performs the save?
The only way I'd consider your current behaviour correct is if you're in the
middle of an extended user interaction (e.g. you have a sheet open to apply
some mutation, and the user is still in the middle of choosing the parameters
of that mutation). But in that case any changes the operation might entail
shouldn't yet be applied to the document, so it shouldn't be thinking it's
modified to begin with. And a big hint that you're in this scenario is if you
have a big 'Cancel' button which aborts the prospective changes and leaves the
document unmodified. It sounds more like you're in the middle of applying a
user action, one that has been expressly approved and is merely taking some
time.
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
