Let's talk about the code SetOutPath.
Applications act funny. Some of them understand where they are and where to look, regardless of their location. some of them however, get confused. And some of them act really funny.
Now, this blog entry was brought about by this this post. Now, I'm not making this entry to insult the original poster, just bring about some better explanations.
Now, onto the meat 
Remember how I said that some apps understand where they are and don't get confused? Well, an example of this is PNotesPortable (NOTE: You can take me using my apps primarily as either blatant advertising, or you can assume that I'm just using them becuase I'm more familiar with the code. Either way, you're right)
PNotesPortable knows where to look its settings files. It does because of the command line variable passed to it. However, it would now this anyway. You can look at the test version of PNotes Portable 1x and see this.
An example of an app that gets confused is VTiPortable. VTi in normal use would look right beside itself for its files- roms, skins, etc. However, when launched via the NSIS launcher, it gets confused, and starts looking for files at the launchers folder. This leads to errors, and recreations of the skins. But, by manipulating the SetOutPath, it can be told to look under Data\roms.
Now for the app that acts funny. Currently, the app is still sitting on my flash drive waiting to get cleaned up and posted. Instead you get a coding blog post 
FakeNES Portable Acts really funny. It know to look right next to itself to finds its configuration file. However, if I set SetOutPath to Data\saved, it will start looking for the saved states in that folder!
To use SetOutPath, all you have to do is call it somewhere before launch. I prefer to set it right before I execute the base app.
LaunchNow:
SetOutPath "$EXEDIR\Data\roms\"
Exec $EXECSTRING
GoTo CheckRunningThat's from VTiPortable, so, its setting the path to the roms folder, under Data- which is exactly where I want it to look for the info at. That way, I don't have to move the files about.
VTi Portable is a case where manipulation was used to save work for the launcher. In the case of this post, it will need to be used to get the app to function properly, period.
- OliverK's blog
- Log in or register to post comments
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
Comments
Command line arguments
are a potential problem; I've got heaps of doskey macros for my cmd portable; e.g. gimp for X:\PortableApps\GIMPPortable\GIMPPortable.exe.
If GIMP set the working directory, if I called it from X:\Documents\foo as "gimp bar.xcf" - to open X:\Documents\foo\bar.xcf - if the working directory has been changed, I'll need to specify the full path, or put in some fiddly NSIS code to get around it. There is, however, a dll call with standard windows libraries to combine paths, I'll find it later, I've got it in AHK, but how do you then detect that it's meant to be a path, etc. I hope you understand the problem!
But yes, I've had to use SetOutPath in at least one app that I've done - can't remember now. But if there is any other solution and the program works with user-specified files (most will) then use the other solution, even if it's more fiddly.
command line arguments
yeah, and this is definitely true for USB drives, because USB drives are hot swappable, meaning the drive letter could be G: one day, F: the next, or H: the next, or D: inserted on a different computer entirely, so to make ANY app portable, the program MUST detect what the current path is on EVERY insert, for the drive letter could always change depending upon the computer its on, or even on your computer at home the drive letter could change every time its inserted, like mine does... I personally don't see, from a developers point of view, why you'd even have to specify a path, because usually a single dot represents the CURRENT path in DOS, or linux, so I don't even understand why you have to detect the current path at all, just use teh "." trick, or ".." for the directory above that, or "\" or "/" in linux, for the rooth path, so there should be no reason u should have to from a developers point of view.
Sometimes they stay the same,
Sometimes they stay the same, sometime they don't. This is the concept that PNotesSync worked on.
What we use in NSIS for the current directory is
$EXEDIR. Otherwise, I prefer to use a macro to gather the current drive, then go from there. I don't know if NSIS can use those tricks.I'm not saying to use
I'm not saying to use SetOutPath with a commandline argument. Generally, they should have a problem with getting confused.
I just used PNotesPortable as I was familiar with the code, and needed a good example of somethign taht doesn't get confused.