dim f as Xojo.IO.FolderItem
dim t as Text
f = new Xojo.IO.FolderItem("/Users/ebaum/Desktop/missing") // f.exists = False
t = f.Name
t = f.DisplayName
…assigning f.Name to t works, but assigning f.DisplayName to t raises an exception because the file is missing.
What about .DisplayName is dependent on an actual file?
I guess I would expect that trying to access something like .CreationDate or .Length should fail if the file is missing. But my naive model for Name/DisplayName is that both are based on the file path, and since I defined that in the constructor, I should be able to call either of them.
A followup question: what exactly does DisplayName do differently from Name?
DisplayName is the value of the actual file… no file, no displayname (since it wouldn’t be seen in a directory listing either)
Name is simply the last child value in the folderitem. It just so happens that both are equal when the file DOES exist
dim f as FolderItem
dim s as String
f = new FolderItem("/Users/ebaum/Desktop/missing", FolderItem.PathTypeShell) // f.exists = False
s = f.Name
s = f.DisplayName
…works fine and does not raise any errors or exceptions. So it looks like the new framework has introduced a new failure case that the old framework did not have. Since that’s not documented anywhere, and I was expecting the old behavior (while refactoring legacy code to use the new framework), it bit me.
I think it’s a little misleading for the documentation to recommend using .DisplayName instead of .Name without also mentioning that there is an edge case (exists = False) where the two properties are NOT interchangeable.
Once you know this can happen, there’s a simple workaround:
def DisplayNameSafe(extends f as Xojo.IO.FolderItem)
if f.exists then
So it looks like the new framework has introduced a new failure case t[quote=378136:@Eric Baumgartner] So it looks like the new framework has introduced a new failure case[/quote]
“New” vs “Old” framework does not apply here
no need to use NEW with FolderItem…
you might consider “specialfolder.desktop” instead
I wouldn’t agree that assumption is safe to make. Mac has some interesting localization features in the Finder. They aren’t commonly used by developers outside of Apple, but it can cause differences. Use DisplayName only for the purpose of displaying the name of the file as the user would expect to see it in Finder/Explorer.
The file should need to exist for the way it’s name is displayed to be determined. I’m not Xojo staff so I don’t know the internals of the framework, but this could include name localization or extension display options.
It may make a call into an OS framework asking for the display name, whereas Name is part of the FolderItem as you mentioned.