GetFolderItem changed behavior

General
1

I recently spent a lot of time tracking down an issue using GetFolderItem

I know that it is ‘deprecated’ (although it doesnt seem to have a good replacement - the documented folderitem constructor doesnt seem to accept a path?)

But bear with me… lots of people are using older Xojo versions, and my problem occurred because I code in in 2018R3 but have begun compiling in newer versions to get a Universal build for Mac

In Xojo 2018 (and 2015 which I use on Windows), this code will get me a valid folderitem

dim f as folderitem =   <some valid  and existant folderitem>
dim s as string = f.absolutepath
dim f2 as folderitem = getfolderitem(s)

I started hearing of issues when the folderitem in question was on an external drive, and convinced myself that was the problem.

The absolutepath might be EXT1:Somefile.jpg

In Xojo 2018 onwards, what happens is this:

dim f as folderitem =   {some valid  and existant folderitem}
dim s as string = f.absolutepath
dim f2 as folderitem = getfolderitem(s)

//f2.exists is now FALSE
//F2.absolutepath  looks like this...  
//{Full Path to Applications Folder}/EXT1\Somefile.jpg

Now in some respects, this will be explainable - because the doc for
GetFolderItem says it defaults to ‘current folder’ (which would be applications)

In Xojo 2018, the string is recognised as containing a volume name, and it works.
In Xojo 2021, the string is taken as ‘generic’ and appended to the local folder path.

This behavior shouldnt have changed, regardless of deprecation, but I guess no-one will consider it as a bug that will be addressed.

I have the usual workaround: the MBS plugins provide a function called
NewFolderItemFromAbsolutePathMBS
which works as I expect it to.

1 Like
2

Sure it does (though that second parameter is wrong in the docs [Report]):

Constructor(path as String, pathMode as FolderItem.PathModes, followAlias as Boolean = True)

https://documentation.xojo.com/api/files/folderitem.html#folderitem-constructor1

3

Interesting… The page referenced from the old GetFolderItem is this one:

http://man.hubwiz.com/docset/Xojo.docset/Contents/Resources/Documents/docs.xojo.com/FolderItem-9.html

FolderItem.Constructor(f as FolderItem)

From Xojo Documentation

Constructor

FolderItem.Constructor(f as FolderItem)

Creates a new FolderItem. You can create a copy of a FolderItem by passing the FolderItem to be copied to the constructor. The result is a copy of the passed FolderItem rather than a reference to it.

4

Well, for old versions of Xojo, that’s probably true. I’m looking at what should be in 2021 (the version you said you’re compiling with). IIRC, when FolderItem was updated for recent versions of macOS, the underlying API now expects a different format. For example, one of my external drives has a path like this:

NativePath: /Volumes/Storage-1TB/filename.png
ShellPath: /Volumes/Storage\-1TB/filename.png
URLPath: file:///Volumes/Storage-1TB/filename.png

Rather than:

Storage-1TB:filename.png

The version mixing you’re doing is probably going to be hard to pull off well because FolderItem was updated due to problems with the old API on newer versions of macOS, but I’ve not really tried to do that so I can’t say for certain. Maybe someone who has can pitch in and help out or correct anything I’m getting wrong here.

5

The path constructor is present in the external documentation you linked. Just go to the FolderItem page and look at the listed Constructors.

1 Like
6

This page might help explain what you’re seeing. The new FolderItem implementation uses POSIX style paths while the old API (and AbsolutePath value you shared) used traditional Mac paths.

2 Likes
7

To add to that, AbsolutePath graduated from deprecated to removed in 2019r2 (and versions prior to that have unreliable FolderItem behavior on Big Sur and newer).

1 Like
8

Luckily my Xojo 2021 instance is still happy to deliver it.

OK. More work-that-adds-nothing-but-could-introduce-bugs for me in the near future, then.

At the end of the day, the real shock was seeing my ‘valid’ file path being appended to the path to the applications folder. There is no sense to that at all, but I didnt come looking for a solution so much as to offer a mild warning , and a post that might come up if anyone searched for similar effects. Thanks all for the input. :slight_smile:

1 Like
9

Luckily there is still NewFolderItemFromAbsolutePathMBS which I need for AppleScript and my favourite app Outlook.

10

Before I go and wholesale change everything then get into heavy testing, can we confirm that .NativePath works in all versions and isn’t likely to e be removed any time soon?

11

Let’s hope so. My code is liberally sprinkled with such as:

f = new FolderItem (orphname, FolderItem.PathModes.Native)
if  (f<>Nil and f.Exists=True)  then
  // Do something
end if

In fact it seems I have 58 of them. My app runs on macOS (both CPUs), Windows, Linux (both intel and Pi) so that would appear to be reasonably x-platform.