INI Look Up Logic: Program Folder First?

[MVV]

I'm using UseIniInProgramDir and don't worry, all is right. And for every user who just installs TC all works fine.

And, as I said, no one will change logic that was here for years because too much plugins and tools use it.

[HolgerK]

So, my logic would work:

Option (1)
Is INI on program folder? Yes
Load from there.

Option (2)
Is INI on program folder? No
Is INI on Windows folder? No
Is INI on users data folder? Yes.
Load from there.

Hmm...
Which location should be used to save wincmd.ini for the first time if there is no wincmd.ini at all in any of these locations?

Regards
Holger

[kwanbis]

The one the user selects on install.

[MVV]

The one the user selects on install.

And how TC will know which one user selected on install if you suggest not to use registry at all?

[kwanbis]

By checking all the places sequentially, when starting up:

TC Starts up, 1st thing it does is check for INI precense:
Is there an INI in Documents and Settings for current user?
Yes? Load from there.
No? Is there an INI in Application Data for current user?
Yes? Load from there.
No? Is there an INI in Program Directory (systemwide)?
Yes? Load from there.
No? Is there an INI in Windows Directory (systemwide)?
Yes? Load from there.
No? Ask user where he wants the INI.

[HolgerK]

... Ask user where he wants the INI.

Hmm...
I'm a user and i want the ini-files placed inside a sub folder of the program directory.

Regards
Holger

[kwanbis]

me2. That is the point of this post

[HolgerK]

... placed inside a sub folder of the program directory...

not inside the program directory!
The question is how will you handle such locations (without an registry entry) which are not covered by your suggestion?

Regards
Holger

[Sob]

Make the first check be the following, i.e. insert it before what you suggest and you have my vote (not that it matters at all ;).

- Is there custom INI path defined in registry for current user?
- Yes? Load from there.

I like the option to have ini files in completely independent directory without having to specify the paths as command-line parameter.

Otherwise your proposed order makes sense. E.g. currently if no path in registry is set and ini files exist in both %SystemRoot% (C:\Windows) and %APPDATA%\GHISLER, TC prefers the first one and personally it feels wrong. But at the same time, it could be meant as some admin set defaults for new users.
So the most important thing we're missing here, is some complete official description of how the ini files are searched. Is there one somewhere? In theory paths could be read not only from HKEY_CURRENT_USER branch in registry, but also from HKEY_LOCAL_MACHINE, also looking in %ALLUSERSPROFILE% could make sense in some cases, there are many possibilities...

[kwanbis]

Yeah, that makes sense.

[ghisler(Author)]

Originally TC looked in the Windows directory, because when you call the ini functions without a path, the ini will be stored in the Windows directory. So in fact you can say "thanks" to Microsoft that TC originally stored them there.

With TC 7.50, I changed the behaviour where TC looks for the ini. If there is no command line switch, no ini in the program dir with UseIniInProgramDir, and no registry entry, TC will look first in the Windows dir as older version.

But if there is no ini file there, TC will create the new one in %APPDATA%\GHISLER. This is done for backwards compatibility, e.g. for companies who do not want to let their users change settings, or for users who have made their wincmd.ini in Windows dir writable.

So in the end, the order is the following:
1. Command line switches /i= or /f=
2. In program dir, if UseIniInProgramDir was set and 4 was added to the value (e.g. 7 for both inis)
3. In HKEY_CURRENT_USER branch
4. In HKEY_LOCAL_MACHINE branch
5. In program dir, if UseIniInProgramDir was set and 4 was NOT added to the value (e.g. 3 for both inis)
6. In Windows dir, if present
7. In %APPDATA%\GHISLER

For plugins or programs started from TC, it's easy to detect where the ini is: Look for environment variable %COMMANDER_INI%. This is of course not set if the program was started outside of TC.

[harrismail]

So correct me if I've got this wrong....

If I place this line in my wincmd.ini UseIniInProgramDir=7 (which is in my program directory)

then when I launch TC the program first looks in the program directory to see if there's a wincmd.ini file and then if it doesn't find one it looks to the registry to see where it has been placed?

The thing I don't understand is that if it looks in the launch directory first.... why if there is a wincmd.ini file there doesn't it just use that instead of needing UseIniInProgramDir=7 to force it to read it ??

It seems very odd to me that it needs UseIniInProgramDir=7 to make it "read itself" if you see what I mean ??

Steve

[MVV]

harrismail, only if wincmd.ini file in TC folder has UseIniInProgramDir key, TC will use it even if registry contains another path or doesn't contain it at all.

E.g. one user can have wincmd.ini in TC dir and another can have wincmd.ini in another place - and they both can use same TC installation because TC will read path to INI from registry.

If you want TC to use only wincmd.ini in its dir, just add this parameter once and forgot about it.

[petermad]

2MVV

E.g. one user can have wincmd.ini in TC dir and another can have wincmd.ini in another place - and they both can use same TC installation because TC will read path to INI from registry.

Only when UseIniInProgramDir=3 | 2 | 1, not with UseIniInProgramDir=7 - I guess.


2harrismail
You can also use this in your reistry:

Code: Select all

[HKEY_CURRENT_USER\Software\Ghisler\Total Commander]
"IniFileName"=".\\wincmd.ini"
"FtpIniName"=".\\wcx_ftp.ini"

Then wincmd.ini will always be used from the dir where you started TC from, just as if UseIniInProgramDir=7 had been used.