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:
- Launch of NempPortable.exe
- Launcher realizes "No Data" and copies contents of DefaultData to %PAL:DataDir%
- Launcher moves folder "Data" from %PAL:DataDir% to %PAL:AppDir%\nemp\
- Nemp.ini in %PAL:AppDir%\nemp\ gets adjusted by the launcher according to the NempPortable.ini
- 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
- 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?)
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
Swap #3 and #4.
You can enable debugging when compiling the launcher and then pasting the
Data\debug.logfile.Can you paste your launcher.ini?
Previously known as kAlug.
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.
Issue 2 still occurs.
Here is my old launcher.ini with Type=INI (I use Type=ConfigWrite for now as that works).
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)
Use it.
I'll download Nemp to see what is wrong.
Previously known as kAlug.
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.
Data\nemp.iniis 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.
Thanks for that info. So, should I stay with ConfigRead/Write? That seems to work.
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
The BOM gets added automatically. How can we delete it on Pre/Post?
Previously known as kAlug.
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.
Couldn't I use
ConfigReadandConfigWritefor 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.
If it works for you, then fine; stay with it.
Previously known as kAlug.
I'll mark the topic as closed then. Thanks again for your help.