Introduction

In every program I have written, I end up using some sort of INI file to keep settings from one run to the next. Instead of implementing it separately in each program, I finally got around to writing this class, CIniFile. It is simple to set up and use.

After you create your CIniFile object, call the member function SetPath(CString newpath) to set the path/filename for the INI file to read from and write to.

To read the INI file data into the class, call ReadFile().

To retrieve data from the class, use GetValue or one of its overloads:

Updates

5 May 2000

Updated source and demo files.

2 March 2003

It has been a long time since I've looked at this article, but as there has been a lot of interest in the non-MFC version of this class, I decided to go ahead and upload it here. As the non-MFC version, rewritten by Shane Hill, contains many more features, I've decided to remove the original MFC class from here. This means a couple things. First - the demo picture at the top of this article is wrong. There are no spaces surrounding the '=' sign. Also, even though the class contains many more features, the basic operation of the class remains the same for the most part. New features include the ability to enumerate existing keys and values and to add comments into the INI file. For the new additions, see the well documented header file.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

About the Author

Comments and Discussions

Well, I'm not too familiar with Builder, but if you are using a project of some form, make sure iniFile.cpp is added to it. Just having iniFile.cpp in the directory isn't enough - you have to tell the compiler to actually compile it.

If that doesn't work, then you will need to do some rearranging with my class.
Keep the #include "iniFile.h" from your main.cpp as it is. Open iniFile.h and at the END of that file, add #include "iniFile.cpp". In iniFile.cpp, REMOVE the line #include "iniFile.h"
I think that should work... (maybe...). Might need a couple other minor changes, not sure.

What kind of problems are you having getting CString to work with std::string?

Conversions between the two should be easy:

string s;
CString s2;

s = (LPCSTR)s2;

and

s2 = s.c_str();

The reason I took the old code off was because the new code contains the same functionality plus new additional features (that and the fact that it is much more portable). If you'd like, I can email the old code. I no longer actually use it in any projects though.

Well,
The problem is memory managment. since both string implementations use reference counts to manage memory (or so i'm told) mixing the two means that i need to start worying about allocating memory and freeing stuff when i return std:string from a function and assign it to CString variable.

I know it's not big, but it's something.

As for sending the code, i already got it (and modified it, and using it quite successfully), so thank anyway. The reason i suggested you post the old code as well is to give future generations a chance to see how similar functionallity can be done using CString.

anyways, no need to ponder over the matter, if you prefer to keep only the new code, well, hey, it's YOUR code

In Solution Explorer, right click on iniFile.cpp and go to properties. On the left, click the folder for C/C++ and then select Precompiled Headers. Now on the right, change where it says "Use Precompiled Header" to "Not Using Precompiled Header".

The update looks good. I have been using the MFC version of the class for a while. It is very nice and I have actually ended up using it for a log of my projects as well... The one feature I felt was missing was the ability to store lists of values. I ended up modifying the class slightly to include SetValueList, and GetValueList functions. A list would be identified by a key name, and the values in the list would just appear in the ini file as n0, n1, n2, ... Is this an update that has been considered?

No, I hadn't really considered doing that. I guess I figured it would be just as easy to either parse the string value returned. I've also seen other programs use a format similar to this (not with my class, though it could easily be done):