SN>
  >  DN> I tend to agree with Jonathan here. Using a binary .INI format keeps
  >  DN> grubby little fingers out of places they don't belong. Furthermore,
  >
  > Why thinking in this terms? O.K., to edit textmode INIs is
  > a bit easier, but out there are so many INI-Editors that
  > everyone who want's to put his grubby little fingers in the
  > INIs can do so.
SN>

  But since an INI file editor goes through the system APIs to access the
  INI file, it cannot corrupt the format of the file.

  Whereas errant user with text editor and text-format INI file can quite
  easily do quite silly things that break the syntax of the INI file and
  cause a lot of damage, such as deleting a section header, missing out an
  equals sign, or deleting a square bracket.

  "Keeping grubby little fingers out" in this context means preventing the
  user from ruining the format of the INI file, by forcing him to go
  through an API which will ensure that the INI file structure itself is
  not damaged, no matter what is done to the INI file contents.

  > JdeBP <
___
 X MegaMail 2.10 #0:

--- Maximus/2 3.01