xmlconf

Unit XMLConf provides the XMLConfig component. It uses a TXMLDocument object to do the work of reading and writing the XMLfile, but descends directly from TComponent.

Disclaimer

This documentation is not authoritative, it is based on the usual process of (1) examining the source code (2) experimentation (3) pondering "I wonder if that is what the author had in mind ?"

Configuration

property Filename: String (published)

The file name of the xml file. Setting the filename to a different name:

• Flushes the current xml file.
• Frees the xmldocument object
• If Filename exists and StartEmpty is false:
  • A new xmldocument is created by reading the file, which must have the same root element as RootName otherwise an exception is raised.
  • Otherwise, a new xmldocument object is created with root element RootName

I have not checked this by experiment, but it appears that an empty xmldocument is created (in memory) when the component is created, and this can be modified. However, it cannot be saved until it has a file name - there is no default file name - hence all modifications will inevitably be lost when the file name is set.

property StartEmpty: Boolean (published)

Controls whether an existing xmlfile is read from Filename.

• Default is false - an existing file is read.

property RootName: DOMString (published)

The name of the root element in the file. Must match the value in the file when an existing file is read.

• Default is 'CONFIG'. It is simplest to leave this alone unless you have a good reason to change it.

procedure Flush (public)

Writes the xml file - as long as there is a file name set.

procedure Clear (public)

Recreates the xmldocument as an empty document.

Working with keys and paths

XMLConfig maintains a "stack" of paths (as an array of widestrings). The overall path to an element might be

 <rootName>/key1/key2/key3/key4/value="some_value".  

This would appear in the file

 <CONFIG><key1><key2><key3><key4 value="some_vale"/></key3></key2></key1></CONFIG

(neglecting an other elements). However, the path stack can contain paths, not just nodes, so it could be four elements deep as key1;key2; key3;key4, but just as well only two elements as key1/key2;key3/key4, or three elements as key1;key2/key3;key4.

Further, when reading or setting a value, a complete path can then be specified, so the path "stack" can be completely ignored and the full path (past RootName) specified for each value. Each value has an effective path, and the path stack is just a convenient way of getting to a specific effective path.

   procedure OpenKey(const aPath: WideString);
   procedure CloseKey;
   procedure ResetKey;

   function  GetValue(const APath: WideString; const ADefault: WideString): WideString; overload;
   function  GetValue(const APath: WideString; ADefault: Integer): Integer; overload;
   function  GetValue(const APath: WideString; ADefault: Boolean): Boolean; overload;
   procedure SetValue(const APath: WideString; const AValue: WideString); overload;
   procedure SetValue(const APath: WideString; AValue: Integer); overload;
   procedure SetValue(const APath: WideString; AValue: Boolean); overload;

   procedure SetDeleteValue(const APath: WideString; const AValue, DefValue: WideString); overload;
   procedure SetDeleteValue(const APath: WideString; AValue, DefValue: Integer); overload;
   procedure SetDeleteValue(const APath: WideString; AValue, DefValue: Boolean); overload;

   procedure DeletePath(const APath: WideString);
   procedure DeleteValue(const APath: WideString);
   property Modified: Boolean read FModified;
 published
   
 end;     

---

Back to fcl-xml