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: Mike Abdullah <email@hidden>
- Date: Mon, 16 Sep 2013 10:38:45 +0100
On 14 Sep 2013, at 21:14, Brian Clark <email@hidden> 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.
>
> Prior to 10.7 this worked fine and gave the desired result. Under 10.8, shortly after I load the new file and call setFileURL: with the new file URL as described above, I see a presentedItemDidMoveToURL: call with the old file URL. From that point on, the document has the wrong URL associated with it.
>
> #0 0x0000000100014cf0 in -[ImageDoc setFileURL:] at /Volumes/Data/Documents/Projects/Ptah/ptah src 3.1.0/Source/ImageDoc.m:3669
> #1 0x00007fff84763b6f in __block_global_243 ()
> #2 0x00007fff842fa869 in -[NSDocument continueFileAccessUsingBlock:] ()
> #3 0x00007fff842fa432 in -[NSDocument _performFileAccessOnMainThread:usingBlock:] ()
> #4 0x00007fff842ff0d7 in -[NSDocument performAsynchronousFileAccessUsingBlock:] ()
> #5 0x00007fff84763b3d in __40-[NSDocument presentedItemDidMoveToURL:]_block_invoke_0 ()
> #6 0x00007fff832789cf in -[NSBlockOperation main] ()
> #7 0x00007fff8324e926 in -[__NSOperationInternal start] ()
> #8 0x00007fff832560f1 in __block_global_6 ()
> #9 0x00007fff8750bf01 in _dispatch_call_block_and_release ()
> #10 0x00007fff875080b6 in _dispatch_client_callout ()
> #11 0x00007fff8750d0c8 in _dispatch_main_queue_callback_4CF ()
> #12 0x00007fff8c4b4b4c in __CFRunLoopRun ()
> #13 0x00007fff8c4b40e2 in CFRunLoopRunSpecific ()
> #14 0x00007fff8b9e0eb4 in RunCurrentEventLoopInMode ()
> #15 0x00007fff8b9e0c52 in ReceiveNextEventCommon ()
> #16 0x00007fff8b9e0ae3 in BlockUntilNextEventMatchingListInMode ()
> #17 0x00007fff8442a533 in _DPSNextEvent ()
> #18 0x00007fff84429df2 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
> #19 0x00007fff844211a3 in -[NSApplication run] ()
> #20 0x00007fff843c5bd6 in NSApplicationMain ()
> #21 0x0000000100063f79 in main at /Volumes/Data/Documents/Projects/Ptah/ptah src 3.1.0/Source/App.m:136
> #22 0x00000001000020e4 in start ()
>
> What is the proper way to prevent this behavior? Obviously simply calling setFileURL: with the new file URL does not fully establish the the document is now associated only with the new file, and that the old file should be forgotten and not associated in any way with the document. I'm not explicitly using NSFileCoordinator or NSFilePresenter. This is a non-sandboxed app.
> _______________________________________________
>
> 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
_______________________________________________
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