Hello everyone,
There is this thread:
that addressed and closed this subject, but my app still gets it with 2023r1.1 on macOS Ventura.
Thanks!
If FolderItem.ShowOpenFileDialog is used to get to the folder, it works!
Do I summarise correctly by saying it works using folderitem.ShowOpenFileDialog and fails using the SelectFolderDialog class?
I tried FolderItem.ShowOpenFileDialog and it works. But I really want to have new FolderItem() work instead. (Showing a dialog is not an option in this particular app).
The thread example you provided is confusing, as it refers to showing a SelectFolderDialog (assuming you then refer to the file using the returned folder and the Child command).
Perhaps you can show your “new FolderItem” call so we can see the format you’re passing?
1 Like
Since the original example was macOS, it should be noted that there is another subtle, however important, difference between the two. On recent versions of macOS, your app needs permission to read from disk except for a few exceptions. When you use the dialogs, the user is in fact giving the app permission because they are doing the choosing, whereas when you create a folderitem from scratch, the app is selecting the location.
I suspect that you’re going to need to add a plist entry to your app which gives a description as to why your app needs access to the network volumes:
1 Like
dim s as string
dim f as folderItem
s = “/MyNetwork Main/My Files/”
f = new FolderItem(s)
// f not nil
// f.exists returns false here
When the app is notarised, I think the app doesn’t need a specific entry (I don’t recall ever having the need to add one). The OS would simply show a dialog to the user, asking for permissions (or fail).
Are the other properties what you expect? (e.g. NativePath)
1 Like
Well that’s certainly not true. The message that gets shown in that dialog comes from the app’s plist. Notarization does not change the need for the privacy requirements.
1 Like
Thank you, Greg. I’ve added the key and verified it is in the app. Checking it now.