Hi
I am trying to set the documents folder in a launcher and am using %PortableApps.comDocuments%, the portable apps menu is a local install so the documents path is C:\users\UserName\Documents but the PortableApps.comDocuments variable returns C:\Documents which does not exist.
How is the variable derived?
Thanks
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
The PortableApps.comDocuments variable, by design, is hard-coded to reside in the same directory as your PortableApps directory, so usually it sits 2 directories higher than your app.
What you want is the Documents variable.
See here for more details: https://portableapps.com/manuals/PortableApps.comLauncher/ref/envsub.htm...
Hi
Because I chose local install my portable apps directory is c:\user\username\portableapps so the hard coding for the PortableApps.comDocuments variable on this machine should be c:\user\username\documents, however it points to c:\documents.
If I am trying to use a launcher to set the working folder to the portableapps documents folder this variable would be correct from a flash drive and not from a local install (option in latest portable apps platform release) and the Documents variable would be correct for the local install but not for the flash drive.
How do I get the launcher to recognise if it is a local or flash drive install?
Hope that makes sense
Thanks
I have just tested. %PortableApps.comDocuments% always point to x:\Documents where x is the drive that the portable app is in regardless where is the PortableApps directory or whether the portableapps.com Platform is installed.
This is primarily for use with the platform. The platform will set it to the Documents directory in the same base directory as Start.exe. This will only apply when your app is launched from the platform. In other cases, the variable will either contain X:\Documents or be unset. I use custom code in launchers to search for it when unset.
ExpandEnvStrings $1 "%PortableApps.comDocuments%" ${If} $1 == "" ${OrIfNot} ${FileExists} "$1\*.*" ${GetParent} $EXEDIR $3 ${GetParent} $3 $1 ${If} $1 == "" ;Be sure we didn't just GetParent on Root StrCpy $1 $3 ${EndIf} ${If} ${FileExists} "$1\Documents\*.*" StrCpy $2 "$1\Documents" ${Else} ${GetRoot} $EXEDIR $1 ${If} ${FileExists} "$1\Documents\*.*" StrCpy $2 "$1\Documents" ${Else} StrCpy $2 "$1" ${EndIf} ${EndIf} System::Call 'Kernel32::SetEnvironmentVariable(t, t) i("PortableApps.comDocuments", "$2").r0' ${EndIf}See the LibreOffice Portable launcher for an example. This feature will be built into the PA.c Launcher in a later release.
Sometimes, the impossible can become possible, if you're awesome!
I have purposely installed the platform to some directory where PortableApps and Documents directories are in x:\some\directory\
I also created a Documents directory in x:\
In an app I set a file move to %PortableApps.comDocuments% and launch the app from the platform. The file is in fact move to x:\Documents and not to x:\some\directory\Documents
Does X:\Documents exist?
Sometimes, the impossible can become possible, if you're awesome!
Yes.
Unless you've already done so, I'll take a look at integrating that into variables.nsh
I take it the other PA.c variables should be treated similarly?
I'm not fully understand the NSIS code. But from the following code which from variables.nsh
ReadEnvStr $0 PortableApps.comDocuments
${If} $0 == ""
${OrIfNot} ${FileExists} $0
StrCpy $0 $CurrentDrive\Documents
${EndIf}
${SetEnvironmentVariablesPath} PortableApps.comDocuments $0
My understanding is, the launcher try to get the environment variable %PortableApps.comDocuments% which should be generated by the platform I think. If not available (I am very sure that the Documents directory is exist) than the laucher will set it to x:\Documents.
If my understanding is correct, than it show that the platform is not generated the environment variable at all. This may be a bug of the platform.
Hi John
Sorry if I am reading your code wrong (new to NSIS) but it looks like this starts at the root and continues till it finds the documents folder, in the new platform shared PC's can have a different install of portable apps by user by doing the local install (great feature) so how would you know if it has picked the correct users\username\documents if multiple exist... George could end up using Andy's documents folder.
Again sorry if I am reading the code wrong but am interested in the launchers and NSIS code.
Thanks
GetParent goes up a single directory. The pair of them goes up to the folder above the PortableApps directory, the directory containing Start.exe. From there, it finds Documents. GetRoot is a separate command and not utilized here.
Sometimes, the impossible can become possible, if you're awesome!
I think I finally got it, it is the "${OrIfNot} ${FileExists} "$1\*.*"" line that causes c:\documents to be chosen in JLim's example hence you asking if it exists and on a multi install shared PC it will not exists and use the ${GetParent} to find the portable apps directory....
Thanks very much I will use you code.
Cheers
Keep in mind that this isn't what the platform sets as will be seen in your PAL launcher. This is custom code for PAL for use without the platform. The platform doesn't currently set the var due to a bug.
Sometimes, the impossible can become possible, if you're awesome!
Following on from John's post I have created a custom file that uses the apps directory and works backwards to derive the documents folder.
${SegmentPre}
ExpandEnvStrings $0 "%PAL:AppDir%"
StrCpy $1 "$0" -38
StrCpy $2 "$1\Documents"
System::Call 'Kernel32::SetEnvironmentVariable(t, t) i("PortableApps.comDocuments", "$2").r0'
This will work as long as the PortableApps folder and Documents folder are at the same level.
My code already does that.
Sometimes, the impossible can become possible, if you're awesome!