• 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: Mon, 16 Sep 2013 17:30:22 -0500

On Sep 16, 2013, at 12:24 PM, Kevin Perry <email@hidden> wrote:

> Re-using a single NSDocument instance to represent several different files is certainly atypical…

True, and I don't know what other similar applications so, but for some applications that are viewers it makes sense to let the user move forwards and backwards through a folder to display the file using the same window rather than opening and closing a window for each file. IT's mre efficient and a more pleasant experience for the user.

> 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)

Thanks! That seems to have worked.

It *is* necessary to use -revertToContentsOfURL:ofType:error: rather than -readFromURL:ofType:error:. And it's necessary as you suggested to do this inside a "File Access" with an NSFileCoordinator. Simply using -revertToContentsOfURL:ofType:error: without these doesn't work.

Thanks for your help.
_______________________________________________

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


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: Progress for archiving/dearchiving
  • Next by Date: Re: Progress for archiving/dearchiving
  • 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