\section{Config classes overview}\label{wxconfigoverview}
-Classes: \helpref{wxConfig}{wxconfig}, \helpref{wxConfigBase}{wxconfigbase},
-\helpref{wxRegConfig}{wxregconfig}, \helpref{wxFileConfig}{wxfileconfig},
-\helpref{wxIniConfig}{wxiniconfig}
+Classes: \helpref{wxConfig}{wxconfigbase}
-This overview briefly describes what the config classes are and what are the
+This overview briefly describes what the config classes are and what they are
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
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
+
+\begin{enumerate}
+\item 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
+\item 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
+\item Not performance critical, neither from speed nor from a memory
consumption point of view.
-\end{itemize}
+\end{enumerate}
-On the other hand, the provided features make them very useful for storing all
-kind of small to medioum volumes of hierarchically organized heterogenous
+On the other hand, the features provided make them very useful for storing all
+kinds of small to medium 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
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.
+understand GTK resource files or their analogues on the KDE side.
-In any case, each implementation of wxConfigBase does its best (although due
+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
-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
+wxIniConfig, 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
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
+path are the group names, and 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.
+even though some implementations use the backslash internally. Further
+details (including how to read/write these entries) may be found in
+the documentation for \helpref{wxConfigBase}{wxconfigbase}.
+
projects / wxWidgets.git / blobdiff