New: PeerBlock Plus (Dec 04, 2023), Platform 27.0.1 (Dec 03, 2023)
450+ real apps (49GB), 1.1 billion downloads, Please donate.
Now Accepting Wire Transfers, Testing Ad Placements
Please reread the DirectoriesMove section of the manual. The target directory is the full target path.
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
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
“Be who you are and say what you feel because those who mind don't matter and those who matter don't mind.” Dr. Seuss
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:
vf2nsr (Homepage) - June 25, 2010 - 5:49pm
settings\full phat\snarl=%APPDATA%\full phat\snarl
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?
Have you tried the content I gave you? It's worth while trying.
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)
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?
"The question I would like to know, is the Ultimate Question of Life, the Universe and Everything. All we know about it is that the Answer is Forty-two, which is a little aggravating."
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.
Sometimes, the impossible can become possible, if you're awesome!
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.
Windows XP Pro sp3 x32
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:
Another instance of HWiNFO32 is already running. Please close other instances of HWiNFO32 before launching HWiNFO32 Portable.
The launcher.ini looks like this:
Ah, I see. I should make it so that WaitForProgram=false implies SingleAppInstance=false. If you put that line in, it'll fix that.