Re-using a single NSDocument instance to represent several different files is certainly atypical…
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) After the coordinated read, NSFileCoordinator should re-invoke -presentedItemURL (which returns [self fileURL] by default), notice the URL has changed, and disassociate the NSFilePresenter state from the previous URL. This should prevent you from getting any unwanted NSFilePresenter messages. -KP On Sep 16, 2013, at 10:04 AM, Brian Clark <ba-cl...@comcast.net> wrote: > > On Sep 16, 2013, at 4:38 AM, Mike Abdullah <mabdul...@karelia.com> wrote: > >> >> On 14 Sep 2013, at 21:14, Brian Clark <ba-cl...@comcast.net> wrote: >> >>> I'm hoping someone can suggest the correct way to deal with the following >>> problem. >>> >>> For an image viewing app i display a file in the usual way in an >>> NSDocument. setFileURL: is properly called by NSDocument's >>> _initWithContentsOfURL:ofType:error:. >>> >>> I now want to display the next file in the folder, and move the old file to >>> the Trash. To do this I do the necessary file reading tasks and call >>> setFileURL: with the new file URL. I then move the old file to the trash >>> (using NSFileManager 's trashItemAtURL:resultingItemURL:error: but using >>> different methods gives the same result.) >> >> What are "the necessary file reading tasks"? Rather than call -setFileURL: >> yourself, have you tried calling -revertToContentsOfURL:ofType:error: >> instead? The top of the class documentation briefly notes that it should >> always be used for re-reading documents. > > The "necessary tasks" are readFromURL:ofType:error: and the other chores > associated with setting up the document state for the different image file. > > Using -revertToContentsOfURL:ofType:error: instead does not work. After doing > this NSDocument still seems to treat the old URL as the file's document, and > I still get presentedItemDidMoveToURL: for the old file URL when it is moved > to the Trash AFTER I-ve called revertToContentsOfURL:ofType:error:. While > revertToContentsOfURL:ofType:error: may work correctly for the cases for > which I guess it was intended (as described by the NSDocument Class > Reference), it doesn't seem to work for this case, for reasons unknown. > > The best work-around I've found is to add a file reference URL to my > NSDocument subclass, and set it in an override of setFileURL:. Then in an > override of presentedItemDidMoveToURL: I test if the saved file reference URL > is the same as the new URL, and do nothing if they're not the same file. That > seems to work, but it's a bit of a hack, and I'd really like to understand if > NSDocument is simply broken in this regard, or why setFileURL: does not work > and what is the correct and reliable way to change the URL for an open > document. > > > _______________________________________________ > > 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: > https://lists.apple.com/mailman/options/cocoa-dev/kperry%40apple.com > > This email sent to kpe...@apple.com _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
