[Outdated] PortableApps.com Launcher 2.0 Release Candidate 2

[DirectoriesCleanupForce]
Shouldn't this backup/restore any local folders of the same name? It doesn't seem to at the moment.

[DirectoriesMove]
Folders specified here seem to be created by PAL automatically. Wouldn't it be better if they weren't?

I updated my PAL and it left %TEMP%\nsr1C.tmp\launcher.ini behind.

But I am pretty sure it wasnt introduced with this update as the latest UnicodeNSISPortable_2.46_Developement_test_3_online.paf.exe package also has this flaw.

Hey,

I have to do a WaitForEXE1= in my launcher.ini but sometimes, the application crashes, which is not totally unexpected. How can you cleanup the file AppName\Data\PortableApps.comLauncherRuntimeData-AppName.ini when that happens? If it is present when relaunching the app, it tends to hang.

Thanks!
Homer

I wanted to see if anyone had any suggestions about the error that I am receiving when I try to use the PortableApps Launcher Generator. When I try to use it, the launcher creations fails with the following report. Any suggestions would be greatly appreciated. I received a similar error when I previously tested it with the beta 4 release. I redownloaded the UnicideNSISPortable and tried again using a different file location without success as well. Thank you for your assistance with this situation.

Processing script file: "F:\PortableApps\PortableApps.comLauncher\Other\Source\PortableApps.comLauncher.nsi"
Including required files... (macro:!echo:3)
!insertmacro expects 1+ parameters, got 0.
Usage: !insertmacro macroname [parms ...]
!include: error in script: "F:\PortableApps\UnicodeNSISPortable\App\NSIS\Include\Util.nsh" on line 25
!include: error in script: "F:\PortableApps\UnicodeNSISPortable\App\NSIS\Include\TextFunc.nsh" on line 60
Error in script "F:\PortableApps\PortableApps.comLauncher\Other\Source\PortableApps.comLauncher.nsi" on line 51 -- aborting creation process

I just got ATanks to wiórk with RC1 with language switching and all. Everything worked (crashing the app, local settings etc), nothing was left behind except for the ini file but that's been taken care of in RC2.
I'll be gone for a week so I sadly wont be here for the release

Hi Chris, I made a menu that you can add for your launcher that I think could be helpful to many users. It in houses the help file with the Launcher Generator and also the folder template I have also included the sample scrips with the main Launcher script that you setup as a guideline.

I hope you guys like it and if you need me to modify it in any way please let me know download it extract it in the same folder as PortableApps.comLauncher is or it wont work.

This will only add some files with some pictures. Your program stays the same and it works well with portableapps menu. I hope you like it.

E-mail me at danny_m_2785 @ hotmail.com for questions or suggestions about this menu.

I found something that might be useful, it is a free "Gui Builder" that might be helpful for making the gui that we need. All that is needed is some one that know how use java programing.

here is that link toGuiGenie.

We can also see if can add this program to PAC since it looks useful.

Hey I updated the menu for the PAC Launcher just added a couple of things. just extract and replace the files that are already there from before and you are good to go. Downlaod It Here Enjoy!!

I am not going to continue the discussion of the menu here for it is not part of the PAL. I will post a link to this menu soon.

EDIT: here is the link to the GUI/MENU for PAL https://portableapps.com/node/23631

Sorry Chris for taking space in your forum.

And I was still having quotes around some of my ini values. Then ForEachINIPair deleted the quotes, but also the last character of the string.
ForEachINIPair.nsh, line 70:

StrCpy ${VALUE} ${VALUE} -2 1

Should probably be:

StrCpy ${VALUE} ${VALUE} -1 1

[Edit:
Some thing I brought up a while ago about the language switching, here & here, still seems to be an issue ! And yes I know, also for me it's a PITA to get my head around this one, but I consider it quite an important feature, what is missing atm !

Maybe it could be done by always reading the initial value with [LanguageFile], also when PAP is used ! Then later, if the LanguageString or language file is missing, PAL could use the initial value, instead of the default !]
[Edit:2 'also when PAP is Not used' should be 'also when PAP is used'. Small typo, but big difference! Fixed it now, though]

I've been playing with the language section, to have a better idea how realistic my above statements are! And I came to this.
http://pastebin.com/mQydWs9Z

I done some testing on it(maybe not enough yet, but had to go to bed), and it does for what I head in mind. But I'm not sure if it does all what you have in your mind.
It still deals with a 'Default' value, but is basically only used on a first run.

I updated Japanese translation.
Please check follow:
http://oss.poyo.jp/pub/contribute/portableapps/2010-06-01/japanese_trans...
(hg exported)

I done a re-write of the two functions of TextFunc.nsh to support UTF-16LE format files.
It's setup in a way that the function checks what the encoding is, so the function will use the appropriate encoding to write/read the file !

I just hope you aren't using anymore functions of TextFunc.nsh, but if you do, let me know and I'll have a look at it.

For now just include this into PAL's 'Other\Source' folder. PAL should automatically make use of it that way.
I will report this to JimPark.

TextFunc.nsh

[edit: BTW, wouldn't it be better to deal with .reg files as an INI file, instead of using ${ConfigRead} ?]

First of all there is a small typo in the manual, the minus is in the wrong place:

Encoding
Values: ANSI / UTF16-LE

Second issue what came to my mind, is when updating existing (ansi) apps, the ansi reg file will have a problem to be drive-letter updated when using the above setting.

One way of solving it (just came to my mind) is to have PAL look for a BOM by default. Instead of using ANSI by default !
Example, just add this to FileWrite.nsh after line 54 (${ReadLauncherConfig} $5 FileWrite$R0 Encoding)

${If} $5 == ``
	FileOpen $9 $1 r
	FileReadByte $9 $5 ; Use FileReadByte for ansi NSIS compatibility
	FileReadByte $9 $8
	IntOp $8 $8 * 256
	IntOp $5 $5 + $8
;	FileReadWord $9 $5 ; Unicode NSIS
	${IfThen} $5 = 0xFEFF ${|} StrCpy $5 UTF-16LE ${|}
	FileClose $9
${EndIf}

BTW: I just realized I have a bug in my code TextFunc.nsh code. FileSeek isn't using the right handle in line 936 & 1030. This is to reset the file position after trying to read a BOM but it didn't exist. Maybe I do an update of the whole file (one day) as I should probably finish the other instructions as well !

[edit: For your info, I never yet experienced a problem with, quote:

Language switching does not work when running as admin as the environment is reset. Due to be fixed in 2.1 if possible.

, neither with RegistryValueWrite.nsh, which I'm using in one of my own apps with 7 separate value to write ! I did see you have some doubt about the code, but sleep 50 shouldn't be necessary and definitely deleting before writing a value is also not necessary !
Sorry for the amount of edits !]

Is there anyone who thought about what happens with my settings if my PC crashes due to a power failure or something else?
Last week I crashed my PC (deliberately!) to see what happens to my portable settings. It was exactly the way I thought it would be: the settings I had copied to my %APPDATA% remained there and when I run my app after the crash, PAL thought they were the local settings and backed them up.
Does that mean the "no personal settings are left behind"-rule only applies if I shut down my PC peacefully?

I haven't tried if the PAL correctly saves my "portable" registry entries back to my Data folder after a PC crash but I think it does as they are all kept in one place.

I know this problem has existed for about as long as this page is up, but it just appeared to me that maybe the new launcher could be a way to work around it by having a file stored some place so it can keep track of things and clean up a pc even after a crash.

EDIT: I just found this comment by Chris mentioning that something like this is already in place. Does this only work in the registry?

How do I write the drive letter to a file on first run? I debugged the launcher and it seemed like the drive letters were being assigned before DefaultData had been copied. Is that correct or am I missing something?

Hey Chris, we may have a problem.

TopOCR saves a lot of info in %WINDIR%\TopOCR.ini. On my XP box, TopOCR Portable cleans that up. xuesheng (one of my TopOCR Portable testers), though, reported that that file is not being properly cleaned up on his Win7 64-bit system, despite the appropriate PAL command. He thinks the problem is with the file virtualization employed on 64-bit systems; if this is the case, PAL has a pretty big hole.
Here's the whole story:
https://portableapps.com/node/21986#comment-151436 (original report of trouble)
https://portableapps.com/node/21986#comment-151563 (suspicion of file virtualization, including some good info from MSDN)

The [FilesMove] description in the manual says "The target directory is the full path to the directory the file is copied to during the program execution. Do not include the file name."

If the target directory supplied ends in a trailing slash then when the program ends the launcher will remove the target directory if it is empty, even if the empty directory existed before the launcher started.

For example, if the launcher.ini file contains

[FilesMove]
settings\TopOCR.ini=%WINDIR%\

this results in the launcher's runtime data file containing

[FilesMove]
RemoveIfEmpty:C:\Windows\=true

Changing the launcher.ini file to

[FilesMove]
settings\TopOCR.ini=%WINDIR%

gets rid of the "RemoveIfEmpty:C:\Windows\=true" entry

If I use any of the standard NSIS registers ($0 to $9, $R0 to $R9) in my custom code segment do I need to worry about saving/restoring their values at the start/end of my custom code?

I can't get this latest one to compile...

Invalid command: MoreInfo::GetProductName
Error in macro CheckForPlatformSplashDisable on macroline 16
Error in macro SplashScreen.nsh_Init on macroline 5
Error in macro RunSegment on macroline 12
Error in script "M:\PortableApps\launcher-054390912040\Other\Source\PortableApps.comLauncher.nsi" on line 182 -- aborting creation process

OK Here they are, they may be stupid but hey if I don't ask I won't know:

1. When writing the launcher.ini does the ini order of events dictate the order in which they are executed? For instances I am working on Snarl. When it installs it adds files to APPDATA. I have been using Directoried Move to swap them between PAL:DATA and APPDATA However the program is looking for the files as soon as launched. So it does not read the files correctly. I was thinking if I can move the files before the executable launches?
2. If 1 above is not possible, is it possible to create a pre-launcher to move files before the exe is started?
3. Is it possible to write a program or script to move the files ahead of the program at al?

Thanks