X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/36c9828f702fb504b07968703bcd82f04196070a..a25a17732c2d4d34d5d35a5318053dd8c6e29722:/docs/doxygen/overviews/config.h?ds=inline diff --git a/docs/doxygen/overviews/config.h b/docs/doxygen/overviews/config.h index 2a3ab2c93d..89a159deb1 100644 --- a/docs/doxygen/overviews/config.h +++ b/docs/doxygen/overviews/config.h @@ -1,58 +1,62 @@ ///////////////////////////////////////////////////////////////////////////// -// Name: config +// Name: config.h // Purpose: topic overview // Author: wxWidgets team // RCS-ID: $Id$ // Licence: wxWindows license ///////////////////////////////////////////////////////////////////////////// -/*! - - @page config_overview wxConfig classes overview - - Classes: #wxConfig - 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: - - - Typed, i.e. strings or numbers for the moment. You can not store - binary data, for example. - Small. For instance, it is not recommended to use the Windows - registry for amounts of data more than a couple of kilobytes. - 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 /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 @b 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. - - */ +/** +@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 can not 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. + +*/