Can I have separate profiles (INI files) for different users or user groups?

questions
1

I am finding more and more, that settings in the INI file do not suit all users. Is it possible to have separate files for either individuals or for groups of individuals. If so, can they be held in the shared program data folder so they are available, irrespective of which machine on a network they logged on from?
Any suggestions would be most welcome.

2

A couple of things to think about:

  1. The INI file has two levels sectors and names, so if you are using the Sector to identify the worker you are limited to a single level below that
  2. You can store the INI file in a CSIDL folder but if people are switching machines all the time, then some setting they set up and liked on machine 1 won’t be available on machine 2.
  3. INI files are not the only way to store stuff, databases are also a good place to store stuff. If you have complicated requirements, like people in this group have this, this particular person has that, people who are not in this one group shouldn’t see…then maybe a database would keep track of that stuff more cleanly. One thing you could do is when people log on, write all their current settings into an INI file in their CSIDL folder. Any important preferences you would have to write back into the database after doing a PUTINI.
  4. I think the INIClass only allows you to have a single location for your app, but if you use GETINI and PUTINI directly, filename is the optional fourth parameter, so you could have a shared INI file and a personal INI file.
    And just my personal opinion: I almost always click “Disable Save/Restore Window Locations” on the General tab of Global Properties, because the downside of dealing with people who move from a two monitor setup to one monitor, and their windows “open” on the non-existent other monitor far outweighs any positive things from allowing the program to remember where people had their multiple open windows last positioned.
1 Like
3

Hi, I would quickly suggest saving those values ​​in a table:

FlagUG (User or Group Flag) (PK)
IdUG (User or Group ID) (PK)
VariableName (PK)
Detail
Value01
Value02

Then you would have functions to retrieve and update the records.

1 Like
4

With you on that last point. I too find the Save\Restore to be less than convenient most times.
Also yes, if the requirements are diverse/complex I’d opt to manage them via a database table.
I do that and keep a “secret” admin screen to manage the settings as need be. Not much of a secret really just that I don’t tell users that is exists or how to access it :smiley:

5

The iniclass can also be used to store data in the registry.

AppGen> Global Properties tab> Actions button> Non Volatile Storage Settings, change Location drop down from INI file to System Registry.

This then brings into play the HKCU aka Current User, which could/should generate the least amount of work, provided you have been using the iniclass to put and read from the ini file instead of the clarion functions Put and Get.

Hive Files

The permanent parts of the registry are stored as a set of files called the hive files. You can find a list of locations for these files in the hivelist subkey in HKLM\SYSTEM\CurrentControlSet\Control. These files are saved in systemroot\System32\Config and updated with each login. They consist of the following files, which store four of the five keys in HKEY_LOCAL_MACHINE and one key in HKEY_USERS:

  • SAM Contains information stored in the key HKLM\SAM about the Security Accounts Manager (SAM) service.
  • SECURITY Contains the security information stored in the key HKLM\SECURITY.
  • SOFTWARE Contains information stored in the key HKLM\SOFTWARE about the computer’s software configuration.
  • SYSTEM Contains information stored in the HKLM\SYSTEM about the computer’s system configuration.
  • DEFAULT Contains the default system information that is stored in the key HKEY_USERS\.DEFAULT.

The HKEY_CURRENT_USER subtree does not contain any data. It just stores a pointer to the content of the HKEY_USERS*Security ID (SID) of current user subkey.* Therefore, the content of that subkey also appears in HKEY_CURRENT_USER, and it can be viewed and changed in either location. The HKEY_CURRENT_USER subtree just provides easier access to the data.

A new HKEY_CURRENT_USER subtree is created each time a user logs on. The data for the subtree comes from the profile of the current user. If no profile is available, then the subtree is built from the user profile settings established for a default user, which are stored in System drive\Documents and Settings\Default User (WINNT)\Ntuser.dat.

6

Just off the top of my head, how about a variable for the ini file name which you set when the user logs in.

You’ll need to update all your relevant GETINI and PUTINI calls to use the variable filename, but that’s all?

7

We create an INI file for each user. We use %USERNAME%.ini and pass it as a parameter when the program starts or we locate it by program at start.
The problem with “computer-independent” is that, for example, the resolution or the number of monitors can vary.
Additionally, you can store the INI files centrally on the server and either access them directly or synchronize them when the program starts/shuts down.
The registry is more up-to-date, but you only have local access to it.
Alternatively, you can do this via a database table; the columns are then like in an INI file: Section, Entry, Value.
Note that the entry entries are limited in length; for example, we also save the list format, and that can be quite long.
I hope I understood your problem :see_no_evil: