42ff6409d9
by standard names. git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@811 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
49 lines
2.7 KiB
TeX
49 lines
2.7 KiB
TeX
\section{Config classes overview}\label{wxconfigoverview}
|
|
|
|
Classes: \helpref{wxConfig}{wxconfigbase}
|
|
|
|
This overview briefly describes what the config classes are and what are the
|
|
for. All the details about how to use them may be found in the description of
|
|
the \helpref{wxConfigBase}{wxconfigbase} class and the documentation of the
|
|
file, registry and INI file based implementations mentions all the
|
|
features/limitations specific to each one of these versions.
|
|
|
|
The config classes provide a way to store some application configuration
|
|
information. They were especially designed for this usage and, although may
|
|
probably be used for many other things as well, should be limited to it. It
|
|
means that this information should be:
|
|
\begin{itemize}
|
|
\item{1.} Typed, i.e. strings or numbers for the moment. You can not store
|
|
binary data, for example.
|
|
\item{2.} Small. For instance, it is not recommended to use the Windows
|
|
registry for amounts of data more than a couple of kilobytes.
|
|
\item{3.} Not performance critical, neither from speed nor from memory
|
|
consumption point of view.
|
|
\end{itemize}
|
|
|
|
On the other hand, the provided features make them very useful for storing all
|
|
kind of small to medioum volumes of hierarchically organized heterogenous
|
|
data. In short, this is a place where you can conveniently stuff all your data
|
|
(numbers and strings) organizing it in a tree where you use the
|
|
filesystem-like paths to specify the location of a piece of data. In
|
|
particular, these classes were designed to be as easy to use as possible.
|
|
|
|
From another point of view, they provide an interface which hides the
|
|
differences between the Windows registry and the standard Unix text format
|
|
configuration files. Other (future) implementations of wxConfigBase might also
|
|
understand GTK ressource files or their analogues on the KDE side.
|
|
|
|
In any case, each implementation of wxConfigBase does its best (although due
|
|
to the limitations of the underlying physical storage as in the case of
|
|
wxIniConfigs it may not implement 100\% of the base class functionality) to
|
|
make the data look the same way everywhere. So you have the 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
|
|
timestamps is planned) and is identified by the full path to it: something
|
|
like /MyApp/UserPreferences/Colors/Foreground. The previous elements in the
|
|
path are the group names, each name may contain an arbitrary number of entries
|
|
and subgroups. The path components are {\bf always} separated with a slash,
|
|
even though some implementations use the backslash internally. The further
|
|
details (including how to read/write these entries) may be found in
|
|
\helpref{wxConfigBase}{wxconfigbase} documentation.
|