CIniFile: Difference between revisions

m
minor corrections
No edit summary
m (minor corrections)
Line 29: Line 29:
  Description=MyFirstProject
  Description=MyFirstProject


Here only a single section - [Workspace] - is defined, however the fact that an INI file can have have as many sections as it needs means that you can use this very file to set up options for how you want your program to behave.
Here only a single section - [Workspace] - is defined, however the fact that an INI file can have as many sections as it needs means that you can use this very file to set up options for how you want your program to behave.


Note that section names (the ones in the square brackets), key names ("Home", "AppSrcPath", etc.) and key values can all contain spaces (although for my own part I prefer not to use those and depend on [http://en.wikipedia.org/wiki/Camelcase camelCase] to supply readability).
Note that section names (the ones in the square brackets), key names ("Home", "AppSrcPath", etc.) and key values can all contain spaces (although for my own part I prefer not to use those and depend on [http://en.wikipedia.org/wiki/Camelcase camelCase] to supply readability).
Line 55: Line 55:
  Password=letmein
  Password=letmein
  Database=Accounting
  Database=Accounting
  Driver=MSSQL
  Driver=MSSQLDRV


Combining these factors - the fact that there is probably no need to have more than one INI file, and the fact that [[Visual DataFlex]] requres one anyway - means that for most purposes you can just add what you need to the existing workspace configuration file.
Combining these factors - the fact that there is probably no need to have more than one INI file, and the fact that [[Visual DataFlex]] requres one anyway - means that for most purposes you can just add what you need to the existing workspace configuration file.
Line 63: Line 63:
For most purposes the information in an INI file will only be read at program start-up.  This means that (a) the oApplication object is a good place to do such things (see the article in  "See Also" below for some guidance on sub-classing the cApplicatiion class) and (b) the cIniFile object need not be retained after it has been used.  (Of course you might have different requirements, but here we will assume these are true.)
For most purposes the information in an INI file will only be read at program start-up.  This means that (a) the oApplication object is a good place to do such things (see the article in  "See Also" below for some guidance on sub-classing the cApplicatiion class) and (b) the cIniFile object need not be retained after it has been used.  (Of course you might have different requirements, but here we will assume these are true.)


So... in your oApplication object (perhaps in the "OnCreate" procedure, perhaps elsewhere, such as "Construct_Object" or "End_Construct_Object") what you need to do is dynamically create a cIniFile object, use it to get the information you want, then destroy it again.  You also want to be able to access the workspace configuration file for the application, perhaps without knowing ahead of time what that is actually called.
So... in your oApplication object (perhaps in the "OnCreate" procedure, perhaps elsewhere, such as in "Construct_Object" or "End_Construct_Object") what you need to do is dynamically create a cIniFile object, use it to get the information you want, then destroy it again.  You also want to be able to access the workspace configuration file for the application, perhaps without knowing ahead of time what that is actually called.


Here is one way of doing it ('''''note''' - this code is assumed to be in the oApplication object or a sub-class of the cApplication class; the only place this matters is in the "Set psFileName ..." line, where "Self" will refer to the oApplication object, and where the various properties are held''):
Here is one way of doing it ('''''note''' - this code is assumed to be in the oApplication object or a sub-class of the cApplication class; the only place this matters is in the "Set psFileName ..." line, where "Self" will refer to the oApplication object, and where the various properties are held''):
Line 102: Line 102:
   Get pbDoLogin  to bDB
   Get pbDoLogin  to bDB


The above code will retrieve the values set in the second workspace file example above.  Note that in that example, the "DoLogin" value is not present - the "''ReadString''" method of the cIniFile class lets you supply a default value if the setting is not present, and here we have used the bLogin variable, which was set from the pbDoLogin property, and which is then used to set that property again... so the fact that the setting is absent (not "''missing''" - it is deliberate!) means that the default property remains unchanged.
The above code will retrieve the values set in the second workspace file example above.  Note that in that example, the "DoLogin" value is not present - the "''ReadString''" method of the cIniFile class lets you supply a default value to use if the setting is not present, and here we have used the bLogin variable, which was set from the pbDoLogin property, and which is then used to set that property again... so the fact that the setting is absent (not "''missing''" - it is deliberate!) means that the default property remains unchanged.


You could save some code by not retrieving the properties into local variables first, but using the properties as defaults directly:
You could save some code by not retrieving the properties into local variables first, but using the properties as defaults directly:
Line 131: Line 131:


== External references ==
== External references ==
*http://en.wikipedia.org/wiki/INI_file
* http://en.wikipedia.org/wiki/INI_file