wxConfigBase class defines the basic interface of all config classes. It can
not be used by itself (it is an abstract base class) and you will always use one
-of its derivations: wxIniConfig, \helpref{wxFileConfig}{wxfileconfig},
+of its derivations: \helpref{wxFileConfig}{wxfileconfig},
wxRegConfig or any other.
However, usually you don't even need to know the precise nature of the class
Windows 3.1 .INI files if you're really unlucky). To make writing the portable
code even easier, wxWidgets provides a typedef wxConfig
which is mapped onto the native wxConfigBase implementation on the given
-platform: i.e. wxRegConfig under Win32 (optionally wxIniConfig) and
+platform: i.e. wxRegConfig under Win32 and
wxFileConfig otherwise.
See \helpref{config overview}{wxconfigoverview} for the descriptions of all
<wx/config.h> (to let wxWidgets choose a wxConfig class for your platform)\\
<wx/confbase.h> (base config class)\\
<wx/fileconf.h> (wxFileConfig class)\\
-<wx/msw/regconf.h> (wxRegConfig class)\\
-<wx/msw/iniconf.h> (wxIniConfig class)
+<wx/msw/regconf.h> (wxRegConfig class)
\wxheading{Example}
understand GTK resource files or their analogues on the KDE side.
In any case, each implementation of wxConfigBase does its best to
-make the data look the same way everywhere. Due
-to the limitations of the underlying physical storage as in the case of
-wxIniConfig, it may not implement 100\% of the base class functionality.
+make the data look the same way everywhere. Due to limitations of the underlying
+physical storage, it may not implement 100\% of the base class functionality.
There are groups of entries and the entries themselves. Each entry contains either a string or a number
(or a boolean value; support for other types of data such as dates or