You are here

[Closed] [Closed][PA.c Launcher] Exact sequence of launcher actions

13 posts / 0 new
Last post
depp.jones
Offline
Last seen: 2 days 2 hours ago
DeveloperTranslator
Joined: 2010-06-05 17:19
[Closed] [Closed][PA.c Launcher] Exact sequence of launcher actions

I encountered a strange problem during packaging Nemp and suspect it a timing issue.

Problem:
Nemp is a little bit "automatic" and starts a wizard at the first launch to query several settings - mostly related to changes made to the system. Even if these are user settings, they could compromise portability (automatic updates, register file types, etc.).
It is started only, if no folder called "Data" exists with some config files in the app folder. As this is an online installer, there is none initially. I tried to solve this with a "Data" folder containing some precofigured files in DefaultData and a [DirectoriesMove] Data=%PAL:AppDir%\nemp\Data .
But it just does not work. Everytime I launch from a fresh install, the wizard would start, despite the Launcher being told to move the Data folder in place. It seems to be just timing. I tried to delay the launch of the base app with a longer SplashTime and LaunchAppAfterSplash=true, but that didn't solve the problem. The contents of DefaultData are just copied and moved at a later time (just as the base app is launched).

Is there a workaround for that? I think I need some safety time buffer between the copying of the folder and the base app launch.

Another issue
[FileWriteN] failed with Type=INI. It just creates duplicate sections in the Nemp.ini. That may be timing dependent, too, as I don't know, at which point Nemp writes settings to the ini and if they are existend, while the file is in use. Type=ConfigWrite works as workaround, though (there are no duplicate Keys in the ini, so that is safe).

To conclude my issue:
I expected the following behaviour, but that seems not to be the exact case:

  1. Launch of NempPortable.exe
  2. Launcher realizes "No Data" and copies contents of DefaultData to %PAL:DataDir%
  3. Launcher moves folder "Data" from %PAL:DataDir% to %PAL:AppDir%\nemp\
  4. Nemp.ini in %PAL:AppDir%\nemp\ gets adjusted by the launcher according to the NempPortable.ini
  5. Nemp.ini is present in %PAL:AppDir%\nemp\ when nemp.exe is called and therefore no wizard is launched. Settings could be written to it by nemp.exe
  6. After closing Nemp, the launcher moves "Data" back to %PAL:DataDir%

It happens too fast to nail down, but I think nemp.exe is called (5) simultanious to the file/folder operations (2-4) so that it just misses them by a whisker. (are there ways to trace that?)

Aluísio A. S. G.
Offline
Last seen: 7 years 8 months ago
DeveloperTranslator
Joined: 2010-11-09 17:43
Wrong order; debug

Swap #3 and #4.
You can enable debugging when compiling the launcher and then pasting the Data\debug.log file.
Can you paste your launcher.ini?

Previously known as kAlug.

depp.jones
Offline
Last seen: 2 days 2 hours ago
DeveloperTranslator
Joined: 2010-06-05 17:19
Thanks! I forgot the debug

Thanks! I forgot the debug option. It's of great help!

I think I found the first bug on my end. After I switched to an online installer, I didn't realize, that the downloaded zip already contains a "Data" folder. As that is existent, the launcher does not replace it with the one in %PAL:DataDir% but simply keeps it and deletes the one in %PAL:DataDir% (shouldn't it backup it and replace it with the one in %PAL:DataDir%? Or is that related to the bug someone posted a while ago? prapper? -edit- see here). Now I'm looking for a way to exclude the "Data" folder from extraction. I could just use AdvancedExtractNTo for every single folder - there are just 5+root - but there must be a more elegant way. Wink

Issue 2 still occurs.
Here is my old launcher.ini with Type=INI (I use Type=ConfigWrite for now as that works).

[Launch]
ProgramExecutable=nemp\nemp.exe
DirectoryMoveOK=yes
MinOS=XP

[Language]
Base=%PortableApps.comLanguageCode%
DefaultIfNotExists=en
CheckIfExists=%PAL:AppDir%\nemp\Languages\%PAL:LanguageCustom%\LC_MESSAGES\default.mo

[LanguageFile]
Type=INI
File=%PAL:DataDir%\Data\Nemp.ini
Section=Allgemein
Key=Language

[DirectoriesMove]
Data=%PAL:AppDir%\nemp\Data

[FileWrite1]
Type=Replace
File=%PAL:DataDir%\Data\nemp.ini
Find=%PAL:LastPackagePartialDir%
Replace=%PAL:PackagePartialDir%
;just in case, a folder setting is not stored relative

[FileWrite2]
Type=replace
File=%PAL:DataDir%\Data\nemp.ini
Find=%PAL:LastDrive%\
Replace=%PAL:Drive%\
;just in case, the drive letter is stored anywhere in the nemp.ini

[FileWrite3]
Type=INI
File=%PAL:DataDir%\Data\nemp.ini
Section=Allgemein
Key=Language
Value=%PAL:LanguageCustom%

[FileWrite4]
Type=INI
File=%PAL:DataDir%\Data\nemp.ini
Section=Allgemein
Key=AllowOnlyOneInstance
Value=1

[FileWrite5]
Type=INI
File=%PAL:DataDir%\Data\nemp.ini
Section=Updater
Key=AutoCheck
Value=0

It does not replace existing keys in a section but appends a new section with new keys (resulting in doubled sections an keys and Nemp launching the wizard again :D)

Aluísio A. S. G.
Offline
Last seen: 7 years 8 months ago
DeveloperTranslator
Joined: 2010-11-09 17:43
Installer's custom code.

Use it.
I'll download Nemp to see what is wrong.

Previously known as kAlug.

depp.jones
Offline
Last seen: 2 days 2 hours ago
DeveloperTranslator
Joined: 2010-06-05 17:19
Thanks, I'll try. The actual

Thanks, I'll try. The actual Dev Test does not include the DefaultData, though.

-edit-
I have put up Dev Test 2 that should fix the first issue.

Aluísio A. S. G.
Offline
Last seen: 7 years 8 months ago
DeveloperTranslator
Joined: 2010-11-09 17:43
UTF-8

Data\nemp.ini is UTF-8 encoded and has a BOM. This is why the INI writer doesn't see the [Allgemein] section. Somehow it's able to read it, though.

Previously known as kAlug.

depp.jones
Offline
Last seen: 2 days 2 hours ago
DeveloperTranslator
Joined: 2010-06-05 17:19
Thanks for that info. So,

Thanks for that info. So, should I stay with ConfigRead/Write? That seems to work.

Chris Morgan
Chris Morgan's picture
Offline
Last seen: 8 years 9 months ago
Joined: 2007-04-15 21:08
Try removing BOM

Try removing the BOM from nemp.ini and see if it gets reinstated. When not properly handled, BOMs can cause the first line to be incorrectly parsed.

(BOMs in UTF-8 are a nuisance and should rarely if ever be used any more. Everything should assume that unless otherwise specified, it's UTF-8.)

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

Aluísio A. S. G.
Offline
Last seen: 7 years 8 months ago
DeveloperTranslator
Joined: 2010-11-09 17:43
Added

The BOM gets added automatically. How can we delete it on Pre/Post?

Previously known as kAlug.

PAL Enthusiast
Offline
Last seen: 12 years 1 month ago
Joined: 2011-12-26 12:19
I Had Same Problem

Notepad++ can remove a file's BOM.

Not sure about Pre/Post ..

That would be cool to know .. i always wondered if it was possible to remove a file's BOM on the fly.

depp.jones
Offline
Last seen: 2 days 2 hours ago
DeveloperTranslator
Joined: 2010-06-05 17:19
Couldn't I use ConfigRead and

Couldn't I use ConfigRead and ConfigWrite for this concrete case (Nemp)? It does the same and it works, just treating the INI-file as text-file. The keys in question exist only once and therefore could be adressed that way. I know it is not the desired and elegant way, but it does the trick.
In addition, I could drop the developer a note for upcoming releases and see, if he is willing to change it.

Aluísio A. S. G.
Offline
Last seen: 7 years 8 months ago
DeveloperTranslator
Joined: 2010-11-09 17:43
It's your app

If it works for you, then fine; stay with it.

Previously known as kAlug.

depp.jones
Offline
Last seen: 2 days 2 hours ago
DeveloperTranslator
Joined: 2010-06-05 17:19
I'll mark the topic as closed

I'll mark the topic as closed then. Thanks again for your help.

Log in or register to post comments