300+ free and legal portable apps (over 9GB), up-to-date, & new apps regularly (Jul 15, 2014: CherryTree).
Get the fast, new 64GB PortableApps.com Companion, encrypted PortableApps.com Carbide, or carry your KeyZ.
PA.c Platform 12.0 Beta 3.2 (May 20, 2014) | PortableApps.com needs your help: Please donate today.

Location of the storage of the settings

tapsklaps
Developer
- October 31, 2011 - 4:21pm

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.


( categories: )

Always use DefaultData

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.

Creation of the Data folder by the launcher

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.

Stop Editing

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 Sticking out tongue

Sometimes, the impossible can become possible, if you're awesome!

impossible to use the PortableApps.com Installer

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?

Something Wrong

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!

Storage of Reg files in the folder DefaultData\settings

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?

AppInfo.ini\[Version]:ProductVersion

That field is in the wrong format. It should be four numbers separated by dots (X.X.X.X).

GENERATION -705 - 991i: The first time you see this, copy it into your sig on any forum. Square it, and then add i to the generation.

Previously known as kAlug.

Your tip is the solution

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.

Reg files

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.

test works fine

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".

Don't move

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.

GENERATION -705 - 991i: The first time you see this, copy it into your sig on any forum. Square it, and then add i to the generation.

Previously known as kAlug.

some considerations about specific code

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:

  1. After the start of the program is created in the registry the key HKLM\Software\Publisher\AppName.
  2. After closing the program the launcher exported this registry key and stores it in the folder Data\settings. Here the launcher named this exported file as appname.reg
  3. Finally the Launcher will delete the registry key HKCU\Software\Publisher\AppName in the registry editor.

Your observations are right,

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.

accurate information regarding the folder DefaltData

Thank you for your good remarks concerning the use of the folder DefaultData. In particular I thought, that the following sentences are very appropriate:

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.).

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:

  1. The launcher looks in the folder Data\settings and finds the registry key appname2.reg.
  2. This registry key appname2.reg the launcher adds now in the registry.
  3. Now the app will be started and use this registry key appname2.reg
  4. After closing the program the launcher exported this registry key appname2.reg (if no changes are made in the settings of the program) or the changed registry key appname3.reg (if changes are made in the settings of the program) and stores it in the folder Data\settings. Here the launcher named this exported file as appname2.reg or appname3.reg.
  5. Finally the Launcher will delete the registry key appname2.reg or appname3.reg in the registry editor.

Edit:

Another possibility would be:

  1. The app will be started and create the original registry key appname1.reg
  2. The launcher looks in the folder Data\settings and finds the registry key appname2.reg
  3. The Launcher compares the two registry keys and finds out that they are not identical.
  4. The Launcher will change the registry key appname1.reg in the registry with such values, that the changed registry key is identical with the registry key appname2.reg
  5. After closing the program the launcher exported this registry key appname2.reg (if no changes are made in the settings of the program) or the changed registry key appname3.reg (if changes are made in the settings of the program) and stores it in the folder Data\settings. Here the launcher named this exported file as appname2.reg or appname3.reg.
  6. Finally the Launcher will delete the registry key appname2.reg or appname3.reg in the registry editor.

Hello tapsklaps, I don't

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:

...
[Activate]
Registry=true

[RegistryKeys]
appnameportable1=HKCU\Software\Publisher\Appname\KeyName

[RegistryCleanupIfEmpty]
1=HKCU\Software\Publisher\Appname\KeyName
2=HKCU\Software\Publisher\Appname
3=HKCU\Software\Publisher\
...

Then the sequence should look tike this:

  1. Launcher (AppNamePortable) will be started and before launching the app, takes care of what it is told.
  2. Launcher looks in folder Data\settings if it finds a file appnameportable1.reg containing the registry key HKCU\Software\Publisher\Appname\KeyName with one or more values. It than writes these to the registry, making a backup, if they already exist.
    If no appnameportable1.reg exists, nothing is written.
  3. Launcher start base app, which uses these values and/or writes new settings to the corresponding key in the registry.
  4. After Base app is closed, the launcher extracts the key HKCU\Software\Publisher\Appname\KeyName from the registry and stores it as appnameportable1.reg in Data\settings. If there is a backup (see 2), it restores its content to the registry, otherwise it deletes the contents of HKCU\Software\Publisher\Appname\KeyName.
  5. If HKCU\Software\Publisher\Appname\KeyName is empty (means: no settings from a possible local install), it deletes the key (see the three entries under [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.

Fix RegistryCleanupIfEmpty

[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

Thanks, you are absoultely right. Eye-wink 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.

Don't know

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

Differentiation of specific individual cases

Thank you for your interesting reply.

Regarding your remarks, I would say the following:

depp.jones wrote...

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.

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.

depp.jones wrote in No. 1 ...

It than writes these to the registry, making a backup, if they already exist.

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.

depp.jones wrote in No. 4 ...

If there is a backup (see 2), it restores its content to the registry, otherwise it deletes the contents of HKCU\Software\Publisher\Appname\KeyName.

Due to the code

[RegistryKeys]
appnameportable1=HKCU\Software\Publisher\Appname\KeyName

the registry key HKCU\Software\Publisher\Appname\KeyName will be deleted. If no backup exists, then in the section [RegistryCleanupIfEmpty] the entry

1=HKCU\Software\Publisher\Appname\KeyName

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:

[RegistryKeys]
appnameportable1=HKCU\Software\Publisher\Appname
(instead of appnameportable1=HKCU\Software\Publisher\Appname\KeyName)

[RegistryCleanupIfEmpty]
1=HKCU\Software\Publisher  

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:

[RegistryKeys]
appnameportable1=HKCU\Software\Publisher 
(instead of appnameportable1=HKCU\Software\Publisher\Appname\KeyName)

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:

[RegistryCleanupIfEmpty]
1=HKCU\Software\Publisher\Appname
2=HKCU\Software\Publisher

In a new post I try to offer exactly instructions for some individual cases.

Please stop editing your posts

Please stop editing your posts. It keeps showing up in the Recent Posts tracker, with no way to tell what you've changed.

Sorry

I want to apologize for my behaviour.

Hello tapsklaps, as you may

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. Eye-wink
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...