INI File Behavior Strange?

1

I am reading and writing some global variables to an INI file and while the read/writes SEEM to be working (variables are saved/recalled from session to session), I don’t see the variables in the INI file. Where are they saved??

The Global INI File Options:

image
image563×407 35.7 KB

APP Name: GuildTraining
INI File Name: GuildTraining.INI

I write with this: PUTINI('AppSettings','RegistrationOpenDays',GLO:RegistrationOpenDays)

I read with this:
GLO:RegistrationOpenDays = GETINI('AppSettings','RegistrationOpenDays')

here’s the INI file section named AppSettings:

[AppSettings]
Maximize=No
Minimize=No
XPos=250
YPos=93
Width=260
Height=160
[MultiView]
2

Time to read GETINI/PUTINI help topic.

1 Like
3

Been there, done that

4

Although the program offers the option of storing in the App directory, if your app is stored in c:\Program Files then that’s “not allowed”. So it’ll get moved elsewhere.
Better to store it in a proper data location, like c:\ProgramData or wherever.

5

Your stated problem is the values are not in the File you expect.
Did you read the Help about the File in PUTINI?

Your problem is you’re missing the 4th parameter the INI File Name.

Note: Since Windows Vista Standard Users cannot write to the Windows Directory. It puts in something like the Virtual Store folder. So always have a path, at least '.\'

1 Like
6

and the help says “If omitted, PUTINI places the entry in the WIN.INI file” so definitely specify the filename as Carl suggests.

1 Like
7

The Virtual Store does not get used if the app is manifested, btw. Not sure if there’s an ERRORCODE(), but it doesn’t go to the virtual store. I read somewhere that it could end up in the registry somewhere too. Not sure.

8

Jeff, i think uou are remembering that the templates allow the “saved stuff” to be stored in the registty instead of an ini file.

But thats a template-level feature (using GETREG and PUTREG), not a feature of the GETINI or PUTINI functions.

9

Assuming you are using the ABC templates, these options are used to configure the ABC object INIMgr. You should use INIMgr.Update(...) and INIMgr.TryFetch(...) to save and load values.

Since you’re using GETINI(...) and PUTINI(...), the global IKNI options aren’t applied. You need to pass the filename as the fourth parameter to these commands; otherwise the values are saved to WIN.INI.

If you are saving values to WIN.INI, or the INI file name you’re using points to a protected folder like C:\Program Files\Your App\yourapp.ini, Windows will prevent your program from writing to that folder and will create the ini file elsewhere.

HTH

1 Like
10

Hi Bruce - I was more referring to whether IniFileMapping could be enabled. I’ve never encountered it, but read about it. WritePrivateProfileStringA function (winbase.h) - Win32 apps | Microsoft Learn

11

Thank you all for your responses. You guys nailed it - I was missing the file name spec at the end. As usual, my speed read of the help topic caused me to miss that fact. Funny thing is, I would have thought the GLOBAL INI FILE OPTIONS would have set the default ini file location without having to specify it and that naming file location (in PUT/GET) would have been for read/write to other non CW ini files. I gues not …

12

The global settings are applied to an object called INIMgr.
You can use this instead of GETINI/PUTINI to save/restore values. Using INIMgr.Fetch/Update will be sensitive to changes to the global settings in the INI File Options tab.

1 Like
13

In LibSrc I often edit BuiltIns.clw to change GETINI and PUTINI so the File parameter is Not <Omittable> that way code as posted would cause an error.

You can always code 'Win.Ini' as the file name if you need it, and that makes it possible to find that rare code. Only thing I recall doing that for is the C5,C6 install settings and registration.

In BuiltIns I also remove the DIRECTORY() using FF_:Queue for only short file names.