One of my projects does FTP/SFTP downloads. While the user can select location, right now I am using SpecialFolder.Desktop as the default. ~/Downloads would be better practice. However, a SpecialFolder.Downloads does not exist (#41113), and I fear localization problems, among other things, if I use simple paths.
From that feedback case, the Mac-side workaround is supposed to be…
Function DownloadsFolder() As FolderItem
Const kUserDomain = -32763 //I did ‘theDomain as Integer=SpecialFolder.DomainUser’ instead.
Const kDownloadsFolderType = “down”
Return SpecialFolder.GetFromDomainAndCode(kUserDomain, kDownloadsFolderType)
This works on 2019r1.1, but on r2 the function returns ~/Library. I tried messing around with “garbage” four letter strings. These predictably threw NilObjectExceptions on r1.1. On r2, though, I got ~/Library no matter what I did, crashing only if I gave an empty string. Filed #58188 on this one.
Yes, a SpecialFolder.Downloads would be nice, especially with a workaround apparently broken. Meanwhile, on the Windows side I am getting into the weeds with Declares, trying to figure this out based on VB and C# code I’ve found. Usually, when I’ve gotten to this point in the past, Christian has bailed me out.
That is actually what I meant when I mentioned “simple paths”. Perhaps I wasn’t clear, but I certainly meant using SpecialFolder.UserHome.Child in front. I am concerned that “Downloads” would present issues on non English-systems. I have worked very hard to provide my apps with localization support.
In any case, the bottom line is r2 broke this SpecialFolder function to deal with Mac system-known folders, and I’m sure it is the best practice.
On Windows it’s even worse, because I understand users can actually move their Downloads folders, and I would want to be able to ask the system to find it for me. But that’s another story (and a reason I would so love to have SpecialFolder.Downloads.)
Future Jerry: Marked “fixed”. That was fast
Would you care to explain, please ?
Yes, I was referring to the FB case I filed, which was mentioned (rather buried, and not linked) in my original post
@Jerry Fritschle On macOS, there should be no localization problem with Specialfolder.UserHome.Child(“Downloads”) because all the system folders have the same name no matter what language is selected for the system. Localization of the names is made later by the system or the Finder.
However, I agree that it is not an ideal case and we should be able to access the Downloads folder directly.
Yes, I now better understand the localization issue (or lack thereof.) Still, doing things the “right” way can avoid unexpected consequences. And kudos to Xojo for fixing the Mac bug in one day.
On Windows I have to declare to an api called SHGetKnownFolderPath(), and I’m presently wrestling with converting some VB code I found, i.e, passing the parameters correctly in Xojo. The conversations I’m finding “over there” make it clear that even without a localization problem (Windows handles that just as you say the Mac does), this is “the” way to do it, because the user may have moved the folder to a different drive or something. As I said, still working on it; this is my first real foray into declares because plugins have heretofore saved the day. Maybe the exercise is good for me
There is a limit to what you should address. If the user doctors his system, he should expect applications to be broken.
Perhaps if he moved his Download folder, the right way to do it is to recreate the Download folder at the documented place.
And I would also advise such a user from hell to seek professional help ASAP
Well, moving the Downloads folder seems to be a legit thing on Windows, done easily in Settings, not a hack. And it doesnt appear uncommon. So yes, I do want to be able to get the known folder from the system, rather than question the users sanity
Still, in the meantime, Im doing basically what you saidcreating my own folder in user root (with my name on it) if Downloads isnt there. And I will uncomment that correct Mac code once the bug fix is released
If indeed Windows settings allow placing Downloads elsewhere, why not. I will question Windows engineers sanity, then
There is an alternative, though, which is commonly used by browsers : pop a Save as dialog. After all, let the user point to any folder he likes to save to.
The app DOES allow the user to select the download location, and save it to preferences. Users of this app pick a path suitable to their workflow, and stick with it. The path, whatever it is, is displayed in the window. Im simply trying to follow what appear to be best practices in setting the default. And that seems to be to get the path to a system-known folder from the system. Yes Im spending a lot of energy on this, but at this point its a challenge.
I know the feeling. Sometimes, I spend a lot of time on details, but the app is not complete without