| 12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061 |
- /////////////////////////////////////////////////////////////////////////////
- // Name: config.h
- // Purpose: topic overview
- // Author: wxWidgets team
- // Licence: wxWindows licence
- /////////////////////////////////////////////////////////////////////////////
- /**
- @page overview_config wxConfig Overview
- Classes: wxConfigBase
- 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 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:
- @li Typed, i.e. strings or numbers for the moment. You cannot store binary
- data, for example.
- @li Small. For instance, it is not recommended to use the Windows registry for
- amounts of data more than a couple of kilobytes.
- @li Not performance critical, neither from speed nor from a memory consumption
- point of view.
- On the other hand, the features provided make them very useful for storing all
- kinds of small to medium volumes of hierarchically-organized, heterogeneous
- 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 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 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 timestamps is planned) and is identified by the full path
- to it: something like @c /MyApp/UserPreferences/Colors/Foreground.
- The previous elements in the path are the group names, and each name may
- contain an arbitrary number of entries and subgroups.
- The path components are @e always separated with a slash, even though some
- implementations use the backslash internally. Further details (including how to
- read/write these entries) may be found in the documentation for wxConfigBase.
- */
|
