FileSystem.getFolder(FileSystem.Downloads) -- not resolving correctly...

[d.healey]

I would suspect there is a register entry somewhere for it, otherwise all other programs, including web browsers, would be confused.

Yup: https://www.elevenforum.com/t/move-or-restore-default-location-of-downloads-folder-in-windows-11.8710/

[Dan Korneff]

This has actually affected me on the User side of things in the past. I almost always change the target path of my downloads and documents to a folder that's shared on my network. It helps keep my OS drive lean, but caused some headaches with a couple installers.
Seeing that it's a setting that's controlled via Windows, I wonder if there is a way to retrieve the redirect?

[Lindon]

@Christoph-Hart said in FileSystem.getFolder(FileSystem.Downloads) -- not resolving correctly...:

If you want to cater in this case, check if the return type is undefined (FileSystem.getFolder checks if it exists and returns undefined if it doesn't), and then do something else, but this is not something that I can solve on the HISE level.

except it is something you can check as Dave points out....its part of the user profile. In fact this should be the place HISE looks for it - not defaulting to a "C:" based solution.

[Lindon]

@d-healey said in FileSystem.getFolder(FileSystem.Downloads) -- not resolving correctly...:

@Lindon FileSystem.getFolder(FileSystem.Temp)

Seems to be missing from the docs - https://docs.hise.audio/scripting/scripting-api/filesystem/index.html

Took a look in there - woah thats full of a lot of rubbish...could be a good candidate.

I create a sub directory in the temp folder called "Libre Wave" and within that I create a directory for each product, then once it's downloaded I can easily clean up.

Is it "always" there? can the user (foolishly) remove it?

[d.healey]

@Lindon said in FileSystem.getFolder(FileSystem.Downloads) -- not resolving correctly...:

Is it "always" there? can the user (foolishly) remove it?

A user can change it, but I'm not sure how HISE is retrieving it. I'll test it later.

[Lindon]

@Lindon said in FileSystem.getFolder(FileSystem.Downloads) -- not resolving correctly...:

@Christoph-Hart said in FileSystem.getFolder(FileSystem.Downloads) -- not resolving correctly...:

If you want to cater in this case, check if the return type is undefined (FileSystem.getFolder checks if it exists and returns undefined if it doesn't), and then do something else, but this is not something that I can solve on the HISE level.

except it is something you can check as Dave points out....its part of the user profile. In fact this should be the place HISE looks for it - not defaulting to a "C:" based solution.

-- except this is now starting to look messy - and not going to work anyway......its a badly documented Windows API call and even then it makes a bunch of assumptions, that dont seem to be very reliable.... hmm, Temp may be my friend.

[Lindon]

@d-healey said in FileSystem.getFolder(FileSystem.Downloads) -- not resolving correctly...:

@Lindon said in FileSystem.getFolder(FileSystem.Downloads) -- not resolving correctly...:

Is it "always" there? can the user (foolishly) remove it?

A user can change it, but I'm not sure how HISE is retrieving it. I'll test it later.

thanks let me know how it goes...

[aaronventure]

@Lindon said in FileSystem.getFolder(FileSystem.Downloads) -- not resolving correctly...:

Temp may be my friend

Or your own company folder in APPDATA, that you always have permissions to create in case it's missing, so you just check if it's undefined, it so you create it, and then write whatever

[Lindon]

@aaronventure said in FileSystem.getFolder(FileSystem.Downloads) -- not resolving correctly...:

@Lindon said in FileSystem.getFolder(FileSystem.Downloads) -- not resolving correctly...:

Temp may be my friend

Or your own company folder in APPDATA, that you always have permissions to create in case it's missing, so you just check if it's undefined, it so you create it, and then write whatever

I'm leaning in towards this solution thanks. I like it because I pretty much know AppData is there if the plugin is running....

[d.healey]

@Lindon one problem to be aware of with both app data and the temp folder is they are always on the system disk. If you have a large download there may not be enough room - especially with recent apple devices that have non replaceable disks.

I've ran into this issue before with users unable to download. My backup solution in these cases is they can download through their browser and install manually.

[Lindon]

@d-healey said in FileSystem.getFolder(FileSystem.Downloads) -- not resolving correctly...:

@Lindon one problem to be aware of with both app data and the temp folder is they are always on the system disk. If you have a large download there may not be enough room - especially with recent apple devices that have non replaceable disks.

I've ran into this issue before with users unable to download. My backup solution in these cases is they can download through their browser and install manually.

yep - already covered there - I test there is enough space, and if not offer the "off-line" install which lets them setup from any folder on any drive that they have already downloaded the zipped files to.

Thanks tho.

[d.healey]

@Lindon Good news, if you change the temp folder location the HISE constant still works :)

[Lindon]

@d-healey said in FileSystem.getFolder(FileSystem.Downloads) -- not resolving correctly...:

@Lindon Good news, if you change the temp folder location the HISE constant still works :)

Great! _ I will bear this in mind - tho Im using Aaron's suggestion this time out....