Up through at least Xojo 2019r1.1 the folderItem.name in macOS would contain a slash if it had one in the Finder name (yes, I know that internally it was replaced with a colon). Sometime between 2019r1.1 and Xojo 2019r3.1 this behavior changed. Now folderItem.name will use a colon to represent the slash. This means
“test/name.pdf” is represented by folderItem.name as “test:name.pdf”
This causes a problem for anyone who has stored file names using previous versions of Xojo (going back forever). Because now,
folderItem = SpecialFolder.Desktop.child(“test/name”) will no long find that file (even though you can see it there).
It will be found by SpecialFolder.Desktop.child(“test:name”), even though to the user there is no colon in the name.
In my case, where my users routinely store the names of thousands of PDFs, the stored names will no longer match the name that Xojo assigns to the file. For example, when my app looks in a folder for the file test/name.pdf it will come up empty, even though the file with that name is there.
I don’t want to get into a debate about how slashes and colons should be handled in macOS, I get it. The problem here is one of backward compatibility. This new naming convention will break a lot of existing code and in a very subtle way, since it only affects files whose names contain slashes.
folderItem.displayname does have the slashes, of course, but it’s unreliable because the displayname changes will be different if the extension is showing or not.
I’m posting this to let people who missed this know in case they’re finding otherwise unexplainable file problems with existing code. I’ve filed a Feedback requesting that the longtime behavior be restored, if anyone wants to sign on. I have no objection to having the folderItem contain a name in which the slash is replaced, but for backward compatibility I suggest a new property be added, something like folderItem.truename, rather than changing the long-established behavior.