Currently I am busy with the preparation of my second portable program. Let me call it "boardgame". In the program folder I found some files as follows:
- one file called xxx.ini
- one file called xxx.config
- one file called xxx.db
- one file called xxx.db1
- one file called xxx.db2
- multiple files called xxx.sfg
Initially I was interested to know which of the above files are assigned to the settings of the program. Personally, I suspect that only the file named xxx.ini is assigned to the settings of the program. Is it sufficient if I move this file from program folder to the Data\settings folder? Then I add in the file "boardgamePortable.ini" the following code:
[FilesMove]
settings\xxx.ini=%PAL:AppDir%\boardgame
Or should I first create the folder DefaultData and inside this folder I create a new folder named settings? In this folder settings I now insert the file xxx.ini. Or I can skip this intermediate step?
Moreover, by the progam 4 registry keys were generated.
Is it sufficient if I write code in the file boardgamePortable.ini according to following scheme?
[Activate]
Registry=true
[RegistryKeys]
appname=HKCU\Software\AppName
Then the file appname.reg was saved in the folder Data\settings after closing the portable version of the app boardgame.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
I suspect the config file also stores settings, but until you post the app, I can't say for sure.
Always use DefaultData to store the original data, including any Reg files needed. This way, if Data doesn't exist, it can be recreated by the launcher using the stored original data.
Your launcher sections look good to me, so far.
I also suspect, that the file xxx.config stores settings. Therefore I should insert the both files xxx.ini and xxx.config in the folder DefaultData\settings.
If I understood you correctly, the launcher will automatically create the folder structure Data\settings, if it is not yet available. Another possibility would be, that I create this folder structure Data\settings self.
But how should I insert the file appname.reg in the folder DefaultData\settings.
How do I get this file appname.reg? As I read in the section Dealing with the registry the following code
[RegistryKeys]
appname=HKCU\Software\AppName
automatically saves the file appname.reg in the folder Data\settings. Of course, this folder Data\settings already must exist.
Please figure out what you want to post and just post it. Editing a post over and over makes it keeping showing up in Recent Posts
Sometimes, the impossible can become possible, if you're awesome!
After formation of the folder and file layout in accordance with the PortableApps.com Format ™ 2.0 I have made the launcher with the PortableApps.com launcher. I then want to apply the PortableApps.com Installer to create the installer. Unfortunately, I received an error message associated with the display of a log file. What should I do in this case?
Then there is something wrong with your build. The PA.c Installer creates the log file within its data directory and that will tell you where the error is. It offers to show it on the exit screen.
Sometimes, the impossible can become possible, if you're awesome!
This log file contains 2682 rows and in the last 2 rows I found the following content:
Error: invalid VIProductVersion format, should be X.X.X.X
Error - aborting creation process
Unfortunately I can not do anything with this information.
However, the developer Gord Caswell mentioned that the reg files also must be saved in the folder DefaultData\settings. This storage I have not been realized. It is therefore necessary that I first export these registry keys in the registry editor and then insert them into the DefaultData\settings folder?
That field is in the wrong format. It should be four numbers separated by dots (X.X.X.X).
Previously known as kAlug.
Thank you for your tip. In fact I have in the file appinfo.ini in the section [Version] for the entry [Package Version] used the wrong format X.X instead of the correct format X.X.X.X
Can you also give me some information regarding the storage of the reg files? I have mentioned in my last post something about this problem.
Export the needed registry keys from registry editor and save in DefaultData.
Don't use DefaultData\settings, because the settings folder is used internally by the launcher. I don't have the link handy, but that's mentioned in the launcher manual.
In the meantime I have tested my created portable app now in my virtual machine. And I don't export the reg files and save them in folder DefaultData. Nevertheless, the necessary reg files were saved in Data\settings. Also in the registry I can't find some registry keys after closing the portable app.
Therefore I'll now upload the portable app in the forum in the section "Beta testing".
You just should not move it; this doesn't means you can't store anything on it.
But personally, I prefer to keep it reserved for the launcher.
Previously known as kAlug.
I've been thinking a bit about the following code:
[RegistryKeys]
appname=HKCU\Software\Publisher\AppName
Previously I had assumed that I first have to export a registry key with the registry editor. Then this registry key should be pasted in the folder DefaultData. Now I've found out - contrary to my assumption - that through the above code automatically the registry key is inserted into the folder Data\settings. But how is this possible? Of course this is only explainable by the programming of the launcher. Specifically the launcher execute the following steps after reading the above codes in the appropriate file AppnamePortable.ini:
Your observations are right, that is exactly how the launcher deals with registry keys, if told so (refer to the manual).
Don't forget to clean up empty Registry entries, too.
(something like that:)
[RegistryCleanupIfEmpty]
1=HKCU\Software\Publisher\appname\
2=HKCU\Software\Publisher\
After reading your post (and the other one here), I fear, you maybe didn't fully understand the concept of DefautData - no offence meant, just a guess. I recall the problem with streamwriter where you discarded your attempt for language switching (which partly failed because of mixing up DefaultData and Data). DefaultData is only needed if an app needs some special settings before its first launch. These settings never should be adjusted by the launcher, because they will not be used after the first launch anymore.
You could place a reg file in DefaultData, if you need to adjust some settings before the first launch (to set an app to portable mode f.i.). For that purpose you could extract its registry settings to a reg file in DefaultData\settings named according to the entry in your launcher.ini. These entries are used for the first run (while existing entires are temporarily backed up), and stored and deleted from (or restored to) the registry when the app is closed. All action is done by the launcher. Those settings will reside in Data\settings from now on.
If you don't need any special settings for the first run, you don't need DefaulData.
Thank you for your good remarks concerning the use of the folder DefaultData. In particular I thought, that the following sentences are very appropriate:
On this occasion I would like to mention, that the above described 3 steps can be applied only to a specific case. This case corresponds to the situation that the program for the first time will be started and then generates a new registry key.
Let me name this key as appname1.reg. However, after the second start of the program I changed some settings and the corresponding registry key appname1.reg is changed. Let me name this changed key as appname2.reg. Then by the above step Nr. 2 the changed registry key appname2.reg will stored in the folder Data\settings. Finally the Launcher will delete the registry key appname2.reg in the registry editor. If you now start the program for the third time, then the following steps must be achieved by the launcher:
Edit:
Another possibility would be:
Hello tapsklaps, I don't know, if I exactly understood your explanations, because I think you mixed up definitions with filenames. So I better describe, what the launcher does (if told so).
Let's assume, the Launcher.ini contains these entries:
Then the sequence should look tike this:
If no appnameportable1.reg exists, nothing is written.
[RegistryCleanupIfEmpty]) so that no entries are left over.The different numbered filenames are only needed, if you have to deal with different keys, but the filenames stay the same for every 'task'. Only the contents change.
[RegistryCleanupIfEmpty]:1 is useless. 3 should have the trailing backslash removed.
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
Thanks, you are absoultely right.
I overlooked No.1 and No.3 was a typo (in my KiTTY dev test, too). Does the trailing backslash break its functionallity? I don't remember getting a leftover key when I tested KiTTY.
That depends on the registry plugin. But it's not valid, whether it works or not.
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
Thank you for your interesting reply.
Regarding your remarks, I would say the following:
Of course you are perfectly right. I meant with the files appname1.reg, appname2.reg and appname3.reg always the same registry key. With the numbers I just wanted to point out to the different contents in the same registry key. Apology for this oversight.
However, I am of the opinion that your instructions are not completely accurate.
A major reason is, that you mix different situations in your instructions. Through this mixing your instruction appears a little bit too unclear. Therefore I think that it is better to create for each specific case a separate instruction.
In addition I am of the opinion that some of your statements are false.
This situation is based on the case that in addition to the portable version a local installation of the program is available and this local installation has already created a registry key. In addition to the backup of the registry key (which was produced by the local installation) it is necessary to delete this registry key. Afterwards the launcher must write the registry key called appnameportable1.reg of the portable version to the registry.
Due to the code
the registry key HKCU\Software\Publisher\Appname\KeyName will be deleted. If no backup exists, then in the section [RegistryCleanupIfEmpty] the entry
is useless (see also the comment of Chris Morgan).
Therefore No. 5 must be written as follows:
If the registry key HKLM\Software\Publisher\AppName is not empty and after the deletion of this key the registry key HKLM\Software\Publisher is empty, then the following code is appropriate:
If the registry key HKCU\Software\Publisher\Appname is not empty and after the deletion of this key the registry key HKCU\Software\Publisher is not empty, then the section [RegistryCleanupIfEmpty] isn't necessary and following code should be used:
If both the registry key HKCU\Software\Publisher\Appname and the registry key HKCU\Software\Publisher are empty, then the following code should be used:
In a new post I try to offer exactly instructions for some individual cases.
Please stop editing your posts. It keeps showing up in the Recent Posts tracker, with no way to tell what you've changed.
I want to apologize for my behaviour.
Hello tapsklaps,
as you may have already realized, my explanations were shortened to the relevant events and should only give a rundown of what happens when the launcher deals with registry. This is universally valid. You always have to find own ways to deal with special cases, but the general actions stay the same. I left out a whole bunch of actions, the launcher also executes, too.
It does not really matter, if the launcher replaces the contents of a key or deletes it first and then writes it new.
The depth of the key structure is also case specific, and what you have to deal with depends on that special case. So if your first or your second setup is valid or a third one, where you have to deal with different keys, who knows? The manual contains detailed information how that works, but I think you already hace read that.
If you are interested, you can follow the actions of the launcher precisely if you build it in debug mode (refer to the the manual for that).
Btw. it is not always necessary to use the most elegant setup if it works as it's supposed to. A part, that is redundant but does no harm (because it does nothing like my first entry in RegistryCleanupIfEmpty) is only a few bytes in the launcher.ini. I for one include in most of my packages path handling even if not strictly necessary just in case, someone uses the Data folder as storage place...