Re: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file
Re: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file
- Subject: Re: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file
- From: Brian Clark <email@hidden>
- Date: Wed, 18 Sep 2013 08:53:53 -0500
A follow-up as a result of more testing.
It's not actually necessary to do the read via -revertToContentsOfURL:ofType:error: in a "File Access" block to solve the problem I had, though I'm sure it's best to do so (and that's what I now do).
Similarly moving the file to the Trash or deleting it should probably also be done in a "File Access" block, and that's what I now do to.
But there's an exception to this rule. In my app, if the displayed file is marked as to be trashed, it's moved to the Trash when the window is closed in the document's -close method (before calling [super close] ). But this results in a hang if it's done inside a [self performSynchronousFileAccessUsingBlock:^{ ... }]; block. So in this case a "File Access" block apparently can't be used.
On Sep 16, 2013, at 12:24 PM, Kevin Perry <email@hidden> wrote:
> But, I suspect the problem here is that you're not using File Coordination when reading in the contents of the new file. By not doing that, you're not giving File Coordination the hint that it needs to check back with your NSFilePresenter (the NSDocument) for its presentedItemURL. When you read in the contents of the new file you should:
>
> 1) Start a "File Access" with -performSynchronousFileAccessUsingBlock: or -performAsynchronousFileAccessUsingBlock
> 2) Create an NSFileCoordinator instance with the NSDocument as the NSFilePresenter passed in the initializer.
> 3) Using that NSFileCoordinator, take a coordinated read of the target file
> 4) Inside the coordinated read: read the contents of the new file (-revertToContentsOfURL:ofType:error: is probably the most correct here, as it will update -fileURL, -fileModificationDate, -fileType, change counts, and other internal state as necessary)
_______________________________________________
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