|
|
 |
|
|
| NOTE: This Design document is subject to change at any time. |
Syntax: <INIFILE property-list/>
The zIniStore object implements storage in a Windows INI file.
The Connection property should be set to the name of the ini file to be created. If no path information is given, the current directory is used. If the Access argument is 0 (read-only) then the file must already exist, and Open returns false if it doesn't. For other access values, the Open method will create the INI file if it doesn't already exist.
All data is stored and retrieved as strings from the INI file. The KeyValue property indicates the INI file Section value. The FieldName is the name of the field within that section.
For example:
| Code: |
| IniStore.Set( 'Section', 'Key', 'Value') |
would create an entry in the Ini file that looks like this:
| Code: |
[Section]
Key=Value |
You could then retrieve this value with the code:
| Code: |
| S = IniStore.Get( 'Section', 'Key') |
Normally, the Ini file data is kept in memory. Using the Set method does not write any information to the disk. Use the Flush method to flush all changes to the disk.
A special Access value of 16 or "disk" can be used to create a disk-based INI file. In this case, data is written to disk as soon as possible. The main difference between this and the normal Ini file is that the Flush method of the normal Ini file will completely rewrite the entire file, removing any comments or other information. The Access=16 files only update fields as needed, and therefore maintain any comments or other information. However, the Access=16 files are much slower to read and write. |
| User comments |
| The Raven: Sun Oct 31, 2004 9:51 pm |
|
Would it be possible to create enumerated or named inputs for the Integer 'Value'? I'm not a fan of unnamed integer inputs to anything. Why 16 and 32, and not 1, 2, and 3? I realize you're probably using this as a passthrough object to already written code, but I think that if you're trying to make an easy to use scripting environment, cleaning up awkward inputs would be an important part of this.
If 0, 16 and 32 are the only values we're expected to use, why not use 0, 1, and 2? If 1, 2, 4, and 8 are valid inputs then they should be documented (even if it's just a reference to see the full list on another sites documentation for the original object). |
|
 |
| Zugg: Mon Nov 01, 2004 12:19 am |
|
Right now there are not any easy ways to add "constants" to any of the scripting languages. If I can figure out how to add constants, then I can add names for these. This is a general problem with any enumerated types in the scripting language that is on my list to work on.
Typically when you see stuff like 16 or 32 or other powers of 2, it means you are dealing with a "set" where multiple options can be combined into a single integer value. |
|
|
| Zugg: Thu Feb 10, 2005 7:15 pm |
|
| I've updated this so that the Access property can have string values, such as "read", "write", "all", or "disk". |
|
|
| The Raven: Thu Feb 10, 2005 9:38 pm |
|
| Woot, thanks Zugg. |
|
|
|
DataSource