Please reread the DirectoriesMove section of the manual. The target directory is the full target path.
You are here
[Outdated] PortableApps.com Launcher 2.0 Release Candidate 2
Please re-read original Post it explains that I have tried it many ways including your suggestion
As expected? so if you do a CleanDirectoriess if Empty it removes all your APPDATA?
Perhaps in the future I
A: won't ask questions
B: will post entire ini files including all the commented out things that have not worked, have been tried but I left in the file temporarily so as to keep track of what had been unsuccessful
The problem is with your DirectoriesMove lines, not DirectoriesRemoveIfEmpty. It's the DirectoriesMove target directory of %APPDATA% which is messing up your APPDATA.
Try something like this:
[Launch] ProgramExecutable=Snarl\Snarl.exe [Activate] Registry=true [DirectoriesMove] snarl=%APPDATA%\full phat\snarl [DirectoriesCleanupIfEmpty] 1=%APPDATA%\full phat [RegistryKeys] SnarlPortable=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Snarl.exe
Sure (Caveat) vf2nsr (Homepage) - June 25, 2010 - 5:49pm [Launch] ProgramExecutable=Snarl\Snarl.exe [Activate] Registry=true [DirectoriesMove} settings\full phat\snarl=%APPDATA%\full phat\snarl [DirectoriesCleanupForce] 1=%APPDATA%\""full phat" [RegistryKeys] SnarlPortable=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Snarl.exe I know directories move looks wrong BUT it is only way to get it to delete the APPDATA info. I also have the files needed for APPDATA preloaded into App/DefaultData folder. Also I have toyed with multiple versions of this ini making numerous changes to no avail. I'm sick of following my dreams. I'm just going to ask them where they're going and hook up with them later. Eye-wink Smiling Eye-wink
That was one of my original posts As I have said I have tried everything and nothing is being moved appropriately. So lets try a different process
http://tinypaste.com/e5fe2 there are the files that need moving....what line of code will do so?
settings\full phat\snarl
has been replaced withsnarl
; this may avoid subdirectory issues.- The DirectoriesCleanupForce has been all fixed and replaced with ..IfEmpty
Have you tried the content I gave you? It's worth while trying.
---------------------------
PortableApps.com Launcher
---------------------------
Snarl Portable cannot be started. You may wish to re-install to fix this issue. (ERROR: C:\DOCUME~1\COMPAQ~1\LOCALS~1\Temp\nsq57D.tmp\launcher.ini could not be found)
---------------------------
OK
---------------------------
by hand instead of copying, it moved 2 files from etc folder only, deleted APPDATA appropriately, and now etc is empy in DATA folder instead of the 6 files in it
Sounds like you gave it the wrong filename. And for the next comment did you get the content exactly right? Sounds most likely to me you got a typo somewhere or something strange like that. Or Snarl is multi-process and goes a tad weird with its settings.
#1: Could PortableApps.comLauncherGenerator.exe give the launcher the app's version number instead of the LauncherGenerator version number? When I recompile PAL, it gives the launcher the app's version number, but PALG gives the launcher a different version number.
#2: (Originally requested by NathanJ79) Could the launcher's internal name be set to AppName Portable instead of PortableApps.com Launcher?
Thanks!
- Do you mean the way the Generator has 1.0.0.0 as its own internal version? Yes, I should probably change that.
- I don't believe it's the internal name which is used here, but rather the file description. It's bad, whatever it is. I'll see about fixing it without disturbing the VI table as much as possible.
As 2.0 has been released (in the release queue), these will be held off till 2.0.1 or 2.1.
1. No, I'm talking about the version number of any launcher created via the Generator. Instead of using the app's version number, it uses a different one (perhaps the Generator's version #?)
2. I'm not sure if the Internal Name or the File Description is at fault here, but I think you're right.
Are either of these necessary? The version of the launcher should be the version of the launcher (NOT the app) as that matches every other portable app we have. So this should not be changed.
The file name as it shows up in Explorer doesn't really need changing. The app's name is contained in AppInfo\Appinfo.ini and that's what the platform uses to display the name. A third party menu could easily be adapted to use it as well. Any third party menu that doesn't, the user will just have to rename it once they install it for the first time, which shouldn't be a big deal since the user will be doing a lot of things manually with another menu anyway. If anything, maybe "AppName Portable (PortableApps.com Launcher)", since that would make it easier for folks using 3rd party stuff or associating it directly in Explorer.
I wanted to comment on HWiNFO32 Portable about adding WaitForProgram=false to it's launcher.ini, cause there didn't seem any sense to wait for the app.
But, after some testing I realized that HWiNFO32 Portable couldn't deal with a secondary-launch anymore. I'm not sure if this is expected behavior or not, but I just wanted to inform you.
As-well, the launcher seemed to create a folder called %PAL:DataDir%\temp when I ran it with WaitForProgram=false, but folder was left empty.
What breaks with secondary launch with WaitForProgram=false? I can't think of anything that should really change.
As for the directory called temp, that's because of the clean TEMP mechanism; it sets the TEMP directory to Data\temp so that it won't be left behind. There are two options if this is ever undesirable: don't use WaitForProgram=false, or set [Launch]:CleanTEMP=false.
Nothing really breaks, but I get this message at secondary-launch:
--------------------------- PortableApps.com Launcher --------------------------- Another instance of HWiNFO32 is already running. Please close other instances of HWiNFO32 before launching HWiNFO32 Portable. --------------------------- OK ---------------------------
The launcher.ini looks like this:
[Launch] ProgramExecutable=HWiNFO32\HWiNFO32.exe RunAsAdmin=force WaitForProgram=false
Ah, I see. I should make it so that WaitForProgram=false implies SingleAppInstance=false. If you put that line in, it'll fix that.