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. > > 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 (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/mabdullah%40karelia.com > > This email sent to mabdul...@karelia.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
