• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file
      • From: Kevin Perry <email@hidden>
References: 
 >Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file (From: Brian Clark <email@hidden>)
 >Re: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file (From: Mike Abdullah <email@hidden>)
 >Re: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file (From: Brian Clark <email@hidden>)
 >Re: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file (From: Kevin Perry <email@hidden>)

  • Prev by Date: Re: iOS 6 Web View Frame Problem
  • Next by Date: Re: Core Data: Primitive Accessors & Ivar-Backed Properties
  • Previous by thread: Re: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file
  • Next by thread: Re: Unwanted presentedItemDidMoveToURL: for old file after using setFileURL: to specify a new file
  • Index(es):
    • Date
    • Thread