Unexpected results from folderitem after movefileto

General
1

A very common thing my apps do is “watch” a source folder for files, process them and then move the original file to another folder. Today, when working with single files I noticed that the routine was trying to process a file that it had already moved. In short, it seems that a persistent folderitem.item(x) is cached in some way. This is XOJO 2015, on OS X 10.10.5 BTW. I will see if I can try on other OS/versions to see if my results are consistent, but if anyone can (a) reproduce (b) explain why it would work this way or © tell me how to tickle the folderitem so it sees the correct directory listing I would appreciate it.

Simple app… window with a button, the window has one property “sourcefolder” type folderitem

Button code

dim i,i2 as Integer
dim f as FolderItem

if sourcefolder=nil then
sourcefolder=SelectFolder()
end if

f=sourcefolder.Parent.Child(“Moved”)
if not f.Exists then
f.CreateAsFolder
end if

i2=sourcefolder.Count
for i=i2 downto 1
MsgBox sourcefolder.Item(i).Name
sourcefolder.Item(i).MoveFileTo f
next

Make a folder somewhere convenient. Put a file in the folder. ex: “X.txt”
Run the app
press the button, select the folder with “X.txt” in it
You will get the messagebox “X.txt”, and “X.txt” will be moved to a folder “Moved” at the same level as the source folder
Press the button again, nothing is shown, as the .count is 0
Put a different file “Y.txt” in the source folder
Press the button again
You will get the message box “X.txt”, and “Y.txt” will be NOT moved to a folder “Moved”
Put “X.txt” back into the source folder again, while “Y.txt” is still there… press the button, I get a nil object exception when accessing item(1) even though the source folder.count reports as 2.

2

Update… same code runs as expected (differently) on Windows 10 under XOJO 2015 and 2013.
Same code runs the same as above (can’t find new items) on OS X Lion with XOJO 2015 and 2013.

Weird

3

Take a look at the following feedback post, it also contains declares for OS X as an alternative. <https://xojo.com/issue/41706>

If the workaround works for you, perhaps this case should be re-opened.

4

It seems it uses the FolderItem properties that were there when you assigned the FolderItem to the property.
You can Dim another FolderItem and use the path from your property.

If you place something like this:
Dim SourceFolder As FolderItem = GetFolderItem(SourceFolder.NativePath,3)
…above:
i2=sourcefolder.Count
… it should work.

Also, be aware that if the Destination File already exists, CopyFileTo will abort. Although the documentation doesn’t mention it, I think it’s the same with MoveFileTo.

5

The MoveTo Case is interesting, but it still doesn’t explain how AFTER a successful move, the folderitem pointed at a directory continues to return the moved file as being in the directory.

I will try recreating the folder item each time, but as mentioned, it works fine/as expected on Windows… just not on OS X.

Thanks for the time/consideration

6

Short update… recreating the folder item: tempfolder = GetFolderItem(SourceFolder.NativePath,3) does update the contents of the folder item on Mac. I just think it shouldn’t be necessary, and it is inconsistent with what happens under Windows. I may file a bug report to see what Austin says about it.

7

On Mac, file actions take time to complete. Often several seconds, while on Windows it is instant. Could that explain ?

8

I don’t think it does, for two reasons… first, in my example above, the folderitem.count is correctly reported as 0 the second time the button is pushed, but when the new file is put in the folder, the count changes to 1, but the .item still refers to the original item. Secondly, Marco’s suggestion works… which is just to make a new folder item using the path in the original, and that reports correctly the contents… so if it were just an OS issue you would expect the duplicated folder item to also report things incorrect/the same as the first folder item. I suppose I could highlight that by making a folder item, manipulating the contents of the folder, create a new folder item with the originals path and then dumping what each believes to be the contents… but at this point they are different. I have not had a case, no matter how long I wait that the original updates with the correct contents.