Meaning of "current folder"

General
1

Mac
Mojave
Xojo 2020 2.1

Below I am quoting from the Language Reference. Somethings confuse me here.

– Start of snippet

The Folderitem.Constructor can be used to get a FolderItem for an item in the current folder by passing it the name of the item. For example, the following returns a FolderItem for the folder “MyTemplates” in the current folder:

Var f As New FolderItem(“MyTemplates”, FolderItem.PathModes.Native)

If the document or folder does not exist, the Exists property of the FolderItem is False.

If you pass the empty string to FolderItem.Constructor, it returns the FolderItem for the folder that contains the application.

Var f As New FolderItem(“”, FolderItem.PathModes.Native)

– End of Snippet from the Language Reference.

  1. What exactly is the “current folder”. I cannot find a definition here. Is the current folder always considered to be the folder that contains the app (whether or not it is complied?).

  2. Var f As New FolderItem(“MyTemplates”, FolderItem.PathModes.Native)
    Is this a reliable way to refer to a folder named “MyTemplates” that exists in the same folder with the app?

  3. Var f As New FolderItem(“”, FolderItem.PathModes.Native)
    is described as the way to get a reference to the folder that contains the app. In my experience, this seems unnecessary in that

Var f As New FolderItem

also seems to produce a reference to the folder that contains the app. Is there some reason that the simple

Var f As New FolderItem

should not be considered to reliably create the same reference as

Var f As New FolderItem(“”, FolderItem.PathModes.Native)

1 Like
2

No.
When running in debug mode, you get ‘one folder’
When running as compiled, a different one.
If you deploy a Mac app, and put it into folder called ‘X’, with a file beside it,
BUT
OSX ‘translocates’ your application,
then you wont find your ‘local file’ next to the app either.

The best advice to be had for folderitem and ‘local’ is :
Forget that local even exists as a concept.

If you want a file, go to specialfolder.applicationdata
or specialfolder.documents

because their position is fixed*, regardless of where your app is, release/debug/translocated.

*A sandboxed app doesnt see the same ‘documents folder’ as a non-sandboxed app.

2 Likes
3

somehow yes but i like to see this usage intuitive in case it were possible.
Var f As New FolderItem(FolderItem.Paths.Executable)

4

I use
Var f As FolderItem = App.ExecutableFile.Parent
to get the folder my application is running in.

1 Like
5

As @Jeff_Tullin says above, on macOS you should not rely on the location of your app for finding other resources. It’s best to use an installer (PKG) to place these files in SpecialFolder.ApplicationData or do that on your first run.

If you’re only reading files that you want to distribute with your app, then you can create a Copy Files build step to place them in your app’s Resources directory and use SpecialFolder.Resources.

If you want read/write, you should either be prompting for the user to select a file or storing in a location that’s dependable outside of your application’s bundle.

6

I don’t think “current folder” has any meaning at all. If I want to get a folderitem for myfile.txt that is on my desktop, then I have to ensure that I’m doing this:

Var f As New FolderItem ("/Users/tim/Desktop/myfile.txt", FolderItem.PathModes.Native)

I suspect the doc is OOD.

7

This is mentioned in a different post on the forum. But it seems that the result is sensitive to the platform. On Windows, this seems to return the folder of the application but on the Mac, it returns some folder downstream and to get the folder of the application requires.

Var f As FolderItem = App.ExecutableFile.Parent.Parent.Parent.Parent

I do not know how reliable under all circumstances the above is. And I I not know what the situation is in the Linux world.

Markus wishes (as I do) that there was a reliable way to have the path to the application and that putting “other stuff” in this folder was considered OK.

Var f As New FolderItem(FolderItem.Paths.Executable)

But the fact that Xojo does not have a “SpecialFolder” for this folder and the comments of Jeff above all imply that what I am trying to do is a bad idea and that I am swimming up current to do something that Apple and Xojo don’t want me to do. There are plenty of reasons that I want to do this, but I will back off and take Jeff’s advice:

Forget that local even exists as a concept.

8

Maybe
Var f as FolderItem=SpecialFolder.Desktop.child(“my file.txt”)
is better and more readable.

In any case the “local” concept is useful on debug when you don’t want to fill your document folder and want to test for some files keeping everything in your project folder.

1 Like