In Xojo 2020r1 the folderItem.name of a file whose name contains multiple slashes is incorrectly reduced to the last element. For example, if you have a file whose name contains a date, such as
“Receipts from 5/5/2020.pdf”
the folderItem.name is “2020.pdf”
It is impossible to get the real name from the pathname because you can’t tell what is a true separator from what is a part of the name.
In Xojo 2019r1 and before the file.name was the actual name was in the Finder, and you could store it away and use it again to find the file. Now that’s impossible.
Some history here: Original Mac paths, going back to pre-OSX, used colons as path separators. When they switched to OS X, and its Unix base, they had to do translation so, internally, colons are represented as slashes and slashes are colons. You can see this by creating a file in the Finder with slashes, then looking at the file name in Terminal.
It might be that you have to do the same substitution yourself in code. Not to say this isn’t a bug, but that might be a workaround.
I’ve just tested 2020r1 and getting the FolderItem by open dialog, the Name property shows colons where the slashes were. I think this is the expected result.
It wasn’t the case in Xojo up through 2019r1.1. The name returned was exactly what was in the Finder.
At least when going through the open dialog there’s a chance to fix the name the user sees. I’ll have to check drag and drop next, since the names change depending on how the folderItem is created. Which is a mess in itself.
The folderItem.name of a dropped file is the same as you get via the openfile dialog. Slashes are replaced by semicolons. The Displayname is actually correct, but will break if the user is hiding the extension in the Finder.
Yes, I imagine you’re right. But the new behavior breaks old code. For example
f = SpecialFolder.Desktop.child(“Receipts from 5/5/2020.pdf”)
reports f.exists = false, even though the file of that name is there (and would have been found in r3.1.)
So there is a workaround for file names obtained via openfile and a dropped file, but it would be so much more straightforward if Xojo corrected whatever the the OS is returning. It will mean updating file names with slashes saved in databases, too, which is a main feature of my app.
@Kem_Tekinay Yes, I’m coming to that conclusion. I hate to add this overhead to each file access and I don’t want to update existing user’s databases that contain the names of files with slashes (because they won’t be compatible with versions of my app built with earlier versions of Xojo), but it may be necessary. (I do consider it a bug in that the behavior of the API has changed and is not backward compatible).
A possible workaround for now is to use something like this:
FileName=File.NativePath.Mid(File.Parent.NativePath.Length+2)
+2: the separator isn’t in the parent path and we need to get the next characters.
Xojo needs to handle non-path slashes, it means, escaped chars (using backslashes) like: Receipts from 5\/5\/2020.pdf
And not replacing chars with others like colons. Users also need to adjust things when necessary, if it is the case.
No, no escaped characters. Simply report the file name as Xojo always has – as it’s represented to the user (the slash). The conversions between slashes and colons should be handled internally, like it is by the Finder, so the user never has to be concerned about it. The old behavior worked transparently for everyone, it should not have been changed.
As I see it, escaped characters aren’t the problem here. Escaped characters are just a representation of a string, while the problem here is the correct value isn’t even retrieved by the API call(s).
If you get just the last part of a slash-delimited file name from a given API, you can hardly transform that into an escaped-characters correct version.