An INI file doesn't load automatically with an EXE, you use either FILETOSTR() to read it or Windows API functions deicated to INIs:
Code:
*-- DECLARE DLL statements for reading/writing to INI files
DECLARE INTEGER GetPrivateProfileString IN Win32API ;
String cSection, String cKey, String cDefault, String @cBuffer, ;
Integer nBufferSize, String cINIFile
DECLARE INTEGER WritePrivateProfileString IN Win32API ;
String cSection, String cKey, String cValue, String cINIFile
DECLARE INTEGER GetProfileString IN Win32API ;
String cSection, String cKey, String cDefault, ;
String @cBuffer, Integer nBufferSize
DECLARE INTEGER WriteProfileString IN Win32API ;
String cSection, String cKey, String cValue
You'll likely find this in your project, if using Code References search for GetProfileString.
The advantage of GetProfileString is to explicitly get at the value of a key in a section, which are defined as follows:
Code:
[section1]
key1="value1"
key2="value2"
key3=3
[section2]
key1=42
If you have this in your.ini, reading key1 from section2 would mean using
Code:
Local lcBuffer, lnRet
lcBuffer=space(10)
lnRet = GetProfileString("section2","key1","0",@lcBuffer,LEN(lcBuffer),"c:\program files (x86)\your applilcation\your.ini")
If lnRet <0
Error "Buffer too short for GetProfileString"
Else
? Left(lcBuffer,lnRet) && lnRet is the length of the returned string
Endif
Notice, even if your value is numeric in the INI, like key1=42, GetProfileString always returns a string, so in the sample case Left(lcBuffer,lnRet) is the string "42" not the number 42. A complete way to handle this will need to know the wanted result dat type, i.e. you better know what you store and want to get back from your INI. There are, by the way, no functions I know of that would simply list all section and key names within a given ini, that points out how writing and reading an ini is an "inside job", something you need to know yourself. It's not hard at all, you determine how you organize your ini entries, what sections you define and what keys, when you write out an ini and therefore it's always straight forward what you want to get back from it. You're prone to errors a user makes when changing a section or key name, intentionally or not.
That's one con, but could be handled by verifying that you get all from an INI you need and otherwise pointing out the INI is broken, incomplete, or in detail what section/key is missing. The other two bog Pros and cons are... Pro: An INI is easy to maintain with just notepad at hand, Con: Your code has it easier to get values from a DBF, where you can define fields in the data types you actually need (i.e. that's a pro for DBFs instead of INI and therefore a con for INIs)
And of course I have to disappoint you about what you think is automatically loaded. I have no idea whether you used some VFP based class/framework or even a third party tool, an EXE or anything else that makes reading in an INI easier for you, you have to look into your project and search it. I already gave one pointer to search for, the names of the API functions, you could also search for "INI", the section names and key names you find in your INI to likely find where you read them in, so even if you use some third party library for that, those detail searches should find them, shouldn't they?
Edit: I forgot to mention that an obvious place where you generate an INI is within your application setup, which could also be in places your EXE with no admin elevation later can either only read or not access at all, if that's badly designed. The usual place of an INI is the application folder, and that's write protected unless you install outside of the program files system directory or store your ini in system directories for which your EXE finally has sufficent permissions. Anyway it is, your EXE is typically only concerend with reading and writing to an existing ini file.
And the other thing I didn't explain yet is how the "Private" flavors of the functons differ. Well, see in detail:
My personal opinion is you won't need this variants, they are not what "private" suggests concerning private (i.e. user specific) INI files.
Chriss
