note about comctl32.dll bug with tree ctrl colours added

[wxWidgets.git] / docs / latex / wx / config.tex

\section{\class{wxConfigBase}}\label{wxconfigbase}

wxConfigBase class defines the basic interface of all config classes. It can
not be used by itself (it's an abstract base class) and you'll always use one
of its derivations: wxIniConfig, wxFileConfig, wxRegConfig or any other.

However, usually you don't even need to know the precise nature of the class
you're working with but you would just use the wxConfigBase methods. This
allows you to write the same code regardless of whether you're working with
the registry under Win32 or text-based config files under Unix (or even
Windows 3.1 .INI files if you're really unlucky). To make writing the portable
code even easier, wxWindows provides a typedef wxConfig
which is mapped onto the native wxConfigBase implementation on the given
platform: i.e. wxRegConfig under Win32, wxIniConfig under Win16 and
wxFileConfig otherwise.

See \helpref{config overview}{wxconfigoverview} for the descriptions of all
features of this class.

It is highly recommended to use static functions {\it Get()} and/or {\it Set()}, 
so please have a \helpref{look at them.}{wxconfigstaticfunctions}

\wxheading{Derived from}

No base class

\wxheading{Include files}

<wx/config.h> (to let wxWindows 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)

\wxheading{Example}

Here is how you would typically use this class:

\begin{verbatim}
  // using wxConfig instead of writing wxFileConfig or wxRegConfig enhances
  // portability of the code
  wxConfig *config = new wxConfig("MyAppName");

  wxString str;
  if ( config->Read("LastPrompt", &str) ) {
    // last prompt was found in the config file/registry and its value is now
    // in str
    ...
  }
  else {
    // no last prompt...
  }

  // another example: using default values and the full path instead of just
  // key name: if the key is not found , the value 17 is returned
  long value = config->Read("/LastRun/CalculatedValues/MaxValue", -1);
  ...
  ...
  ...
  // at the end of the program we would save everything back
  config->Write("LastPrompt", str);
  config->Write("/LastRun/CalculatedValues/MaxValue", value);

  // the changes will be written back automatically
  delete config;
\end{verbatim}

This basic example, of course, doesn't show all wxConfig features, such as
enumerating, testing for existence and deleting the entries and groups of
entries in the config file, its abilities to automatically store the default
values or expand the environment variables on the fly. However, the main idea
is that using this class is easy and that it should normally do what you
expect it to.

NB: in the documentation of this class, the words "config file" also mean
"registry hive" for wxRegConfig and, generally speaking, might mean any
physical storage where a wxConfigBase-derived class stores its data.

\latexignore{\rtfignore{\wxheading{Function groups}}}

\membersection{Static functions}\label{wxconfigstaticfunctions}

These functions deal with the "default" config object. Although its usage is
not at all mandatory it may be convenient to use a global config object
instead of creating and deleting the local config objects each time you need
one (especially because creating a wxFileConfig object might be a time
consuming operation). In this case, you may create this global config object
in the very start of the program and {\it Set()} it as the default. Then, from
anywhere in your program, you may access it using the {\it Get()} function. Of
course, you should delete it on the program termination (otherwise, not only a
memory leak will result, but even more importantly the changes won't be
written back!).

As it happens, you may even further simplify the procedure described above:
you may forget about calling {\it Set()}. When {\it Get()} is called and there
is no current object, it will create one using {\it Create()} function. To
disable this behaviour {\it DontCreateOnDemand()} is provided.

{\bf Note:} You should use either {\it Set()} or {\it Get()} because wxWindows
library itself would take advantage of it and could save various information
in it. For example \helpref{wxFontMapper}{wxfontmapper} or Unix version
of \helpref{wxFileDialog}{wxfiledialog} have ability to use wxConfig class.

\helpref{Set}{wxconfigbaseset}\\
\helpref{Get}{wxconfigbaseget}\\
\helpref{Create}{wxconfigbasecreate}\\
\helpref{DontCreateOnDemand}{wxconfigbasedontcreateondemand}

\membersection{Constructor and destructor}

\helpref{wxConfigBase}{wxconfigbasector}\\
\helpref{\destruct{wxConfigBase}}{wxconfigbasedtor}

\membersection{Path management}

As explained in \helpref{config overview}{wxconfigoverview}, the config classes
support a file system-like hierarchy of keys (files) and groups (directories).
As in the file system case, to specify a key in the config class you must use
a path to it. Config classes also support the notion of the current group,
which makes it possible to use the relative paths. To clarify all this, here
is an example (it's only for the sake of demonstration, it doesn't do anything
sensible!):

\begin{verbatim}
  wxConfig *config = new wxConfig("FooBarApp");

  // right now the current path is '/'
  conf->Write("RootEntry", 1);

  // go to some other place: if the group(s) don't exist, they will be created
  conf->SetPath("/Group/Subgroup");

  // create an entry in subgroup
  conf->Write("SubgroupEntry", 3);

  // '..' is understood
  conf->Write("../GroupEntry", 2);
  conf->SetPath("..");

  wxASSERT( conf->Read("Subgroup/SubgroupEntry", 0l) == 3 );

  // use absolute path: it's allowed, too
  wxASSERT( conf->Read("/RootEntry", 0l) == 1 );
\end{verbatim}

{\it Warning}: it's probably a good idea to always restore the path to its
old value on function exit:

\begin{verbatim}
  void foo(wxConfigBase *config)
  {
    wxString strOldPath = config->GetPath();

    config->SetPath("/Foo/Data");
    ...

    config->SetPath(strOldPath);
  }
\end{verbatim}

because otherwise the assert in the following example will surely fail
(we suppose here that {\it foo()} function is the same as above except that it
doesn't save and restore the path):

\begin{verbatim}
  void bar(wxConfigBase *config)
  {
    config->Write("Test", 17);

    foo(config);

    // we're reading "/Foo/Data/Test" here! -1 will probably be returned...
    wxASSERT( config->Read("Test", -1) == 17 );
  }
\end{verbatim}

Finally, the path separator in wxConfigBase and derived classes is always '/',
regardless of the platform (i.e. it's {\bf not} '$\backslash\backslash$' under Windows).

\helpref{SetPath}{wxconfigbasesetpath}\\
\helpref{GetPath}{wxconfigbasegetpath}

\membersection{Enumeration}

The functions in this section allow to enumerate all entries and groups in the
config file. All functions here return FALSE when there are no more items.

You must pass the same index to GetNext and GetFirst (don't modify it).
Please note that it's {\bf not} the index of the current item (you will have
some great surprizes with wxRegConfig if you assume this) and you shouldn't
even look at it: it's just a "cookie" which stores the state of the
enumeration. It can't be stored inside the class because it would prevent you
from running several enumerations simultaneously, that's why you must pass it
explicitly.

Having said all this, enumerating the config entries/groups is very simple:

\begin{verbatim}
  wxArrayString aNames;

  // enumeration variables
  wxString str;
  long dummy;

  // first enum all entries
  bool bCont = config->GetFirstEntry(str, dummy);
  while ( bCont ) {
    aNames.Add(str);

    bCont = GetConfig()->GetNextEntry(str, dummy);
  }

  ... we have all entry names in aNames...

  // now all groups...
  bCont = GetConfig()->GetFirstGroup(str, dummy);
  while ( bCont ) {
    aNames.Add(str);

    bCont = GetConfig()->GetNextGroup(str, dummy);
  }

  ... we have all group (and entry) names in aNames...

\end{verbatim}

There are also functions to get the number of entries/subgroups without
actually enumerating them, but you will probably never need them.

\helpref{GetFirstGroup}{wxconfigbasegetfirstgroup}\\
\helpref{GetNextGroup}{wxconfigbasegetnextgroup}\\
\helpref{GetFirstEntry}{wxconfigbasegetfirstentry}\\
\helpref{GetNextEntry}{wxconfigbasegetnextentry}\\
\helpref{GetNumberOfEntries}{wxconfigbasegetnumberofentries}\\
\helpref{GetNumberOfGroups}{wxconfigbasegetnumberofgroups}

\membersection{Tests of existence}

\helpref{HasGroup}{wxconfigbasehasgroup}\\
\helpref{HasEntry}{wxconfigbasehasentry}\\
\helpref{Exists}{wxconfigbaseexists}\\
\helpref{GetEntryType}{wxconfigbasegetentrytype}

\membersection{Miscellaneous accessors}

\helpref{GetAppName}{wxconfigbasegetappname}\\
\helpref{GetVendorName}{wxconfigbasegetvendorname}

\membersection{Key access}

These function are the core of wxConfigBase class: they allow you to read and
write config file data. All {\it Read} function take a default value which
will be returned if the specified key is not found in the config file.

Currently, only two types of data are supported: string and long (but it might
change in the near future). To work with other types: for {\it int} or {\it
bool} you can work with function taking/returning {\it long} and just use the
casts. Better yet, just use {\it long} for all variables which you're going to
save in the config file: chances are that \verb$sizeof(bool) == sizeof(int) == sizeof(long)$ anyhow on your system. For {\it float}, {\it double} and, in
general, any other type you'd have to translate them to/from string
representation and use string functions.

Try not to read long values into string variables and vice versa: although it
just might work with wxFileConfig, you will get a system error with
wxRegConfig because in the Windows registry the different types of entries are
indeed used.

Final remark: the {\it szKey} parameter for all these functions can contain an
arbitrary path (either relative or absolute), not just the key name.

\helpref{Read}{wxconfigbaseread}\\
\helpref{Write}{wxconfigbasewrite}\\
\helpref{Flush}{wxconfigbaseflush}

\membersection{Rename entries/groups}

The functions in this section allow to rename entries or subgroups of the
current group. They will return FALSE on error. typically because either the
entry/group with the original name doesn't exist, because the entry/group with
the new name already exists or because the function is not supported in this
wxConfig implementation.

\helpref{RenameEntry}{wxconfigbaserenameentry}\\
\helpref{RenameGroup}{wxconfigbaserenamegroup}

\membersection{Delete entries/groups}

The functions in this section delete entries and/or groups of entries from the
config file. {\it DeleteAll()} is especially useful if you want to erase all
traces of your program presence: for example, when you uninstall it.

\helpref{DeleteEntry}{wxconfigbasedeleteentry}\\
\helpref{DeleteGroup}{wxconfigbasedeletegroup}\\
\helpref{DeleteAll}{wxconfigbasedeleteall}

\membersection{Options}

Some aspects of wxConfigBase behaviour can be changed during run-time. The
first of them is the expansion of environment variables in the string values
read from the config file: for example, if you have the following in your
config file:

\begin{verbatim}
  # config file for my program
  UserData = $HOME/data

  # the following syntax is valud only under Windows
  UserData = %windir%\\data.dat
\end{verbatim}

the call to \verb$config->Read("UserData")$ will return something like
\verb$"/home/zeitlin/data"$ if you're lucky enough to run a Linux system ;-)

Although this feature is very useful, it may be annoying if you read a value
which containts '\$' or '\%' symbols (\% is used for environment variables
expansion under Windows) which are not used for environment variable
expansion. In this situation you may call SetExpandEnvVars(FALSE) just before
reading this value and SetExpandEnvVars(TRUE) just after. Another solution
would be to prefix the offending symbols with a backslash.

The following functions control this option:

\helpref{IsExpandingEnvVars}{wxconfigbaseisexpandingenvvars}\\
\helpref{SetExpandingEnvVars}{wxconfigbasesetexpandingenvvars}\\
\helpref{SetRecordDefaults}{wxconfigbasesetrecorddefaults}\\
\helpref{IsRecordingDefaults}{wxconfigbaseisrecordingdefaults}

%%%%% MEMBERS HERE %%%%%
\helponly{\insertatlevel{2}{

\wxheading{Members}

}}

\membersection{wxConfigBase::wxConfigBase}\label{wxconfigbasector}

\func{}{wxConfigBase}{\param{const wxString\& }{appName = wxEmptyString},
 \param{const wxString\& }{vendorName = wxEmptyString},
 \param{const wxString\& }{localFilename = wxEmptyString},
 \param{const wxString\& }{globalFilename = wxEmptyString},
 \param{long}{ style = 0}}

This is the default and only constructor of the wxConfigBase class, and
derived classes.

\wxheading{Parameters}

\docparam{appName}{The application name. If this is empty, the class will
normally use \helpref{wxApp::GetAppName}{wxappgetappname} to set it. The
application name is used in the registry key on Windows, and can be used to
deduce the local filename parameter if that is missing.}

\docparam{vendorName}{The vendor name. If this is empty, it is assumed that
no vendor name is wanted, if this is optional for the current config class.
The vendor name is appended to the application name for wxRegConfig.}

\docparam{localFilename}{Some config classes require a local filename. If this
is not present, but required, the application name will be used instead.}

\docparam{globalFilename}{Some config classes require a global filename. If
this is not present, but required, the application name will be used instead.}

\docparam{style}{Can be one of wxCONFIG\_USE\_LOCAL\_FILE and
wxCONFIG\_USE\_GLOBAL\_FILE. The style interpretation depends on the config
class and is ignored by some. For wxFileConfig, these styles determine whether
a local or global config file is created or used. If the flag is present but
the parameter is empty, the parameter will be set to a default. If the
parameter is present but the style flag not, the relevant flag will be added
to the style. For wxFileConfig you can also add wxCONFIG\_USE\_RELATIVE\_PATH 
by logicaly or'ing it to either of the \_FILE options to tell wxFileConfig to 
use relative instead of absolute paths.  }

\wxheading{Remarks}

By default, environment variable expansion is on and recording defaults is
off.

\membersection{wxConfigBase::\destruct{wxConfigBase}}\label{wxconfigbasedtor}

\func{}{\destruct{wxConfigBase}}{\void}

Empty but ensures that dtor of all derived classes is virtual.

\membersection{wxConfigBase::Create}\label{wxconfigbasecreate}

\func{static wxConfigBase *}{Create}{\void}

Create a new config object: this function will create the "best"
implementation of wxConfig available for the current platform, see comments
near the definition of wxCONFIG\_WIN32\_NATIVE for details. It returns the
created object and also sets it as the current one.

\membersection{wxConfigBase::DontCreateOnDemand}\label{wxconfigbasedontcreateondemand}

\func{void}{DontCreateOnDemand}{\void}

Calling this function will prevent {\it Get()} from automatically creating a
new config object if the current one is NULL. It might be useful to call it
near the program end to prevent new config object "accidental" creation.

\membersection{wxConfigBase::DeleteAll}\label{wxconfigbasedeleteall}

\func{bool}{DeleteAll}{\void}

Delete the whole underlying object (disk file, registry key, ...). Primarly
for use by desinstallation routine.

\membersection{wxConfigBase::DeleteEntry}\label{wxconfigbasedeleteentry}

\func{bool}{DeleteEntry}{\param{const wxString\& }{ key}, \param{bool}{
bDeleteGroupIfEmpty = TRUE}}

Deletes the specified entry and the group it belongs to if it was the last key
in it and the second parameter is true.

\membersection{wxConfigBase::DeleteGroup}\label{wxconfigbasedeletegroup}

\func{bool}{DeleteGroup}{\param{const wxString\& }{ key}}

Delete the group (with all subgroups)

\membersection{wxConfigBase::Exists}\label{wxconfigbaseexists}

\constfunc{bool}{Exists}{\param{wxString\& }{strName}}

returns TRUE if either a group or an entry with a given name exists

\membersection{wxConfigBase::Flush}\label{wxconfigbaseflush}

\func{bool}{Flush}{\param{bool }{bCurrentOnly = FALSE}}

permanently writes all changes (otherwise, they're only written from object's
destructor)

\membersection{wxConfigBase::Get}\label{wxconfigbaseget}

\func{wxConfigBase *}{Get}{\param{bool }{CreateOnDemand = TRUE}}

Get the current config object. If there is no current object and
{\it CreateOnDemand} is TRUE, creates one
(using {\it Create}) unless DontCreateOnDemand was called previously.

\membersection{wxConfigBase::GetAppName}\label{wxconfigbasegetappname}

\constfunc{wxString}{GetAppName}{\void}

Returns the application name.

\membersection{wxConfigBase::GetEntryType}\label{wxconfigbasegetentrytype}

\constfunc{enum wxConfigBase::EntryType}{GetEntryType}{\param{const wxString\& }{name}}

Returns the type of the given entry or {\it Unknown} if the entry doesn't
exist. This function should be used to decide which version of Read() should
be used because some of wxConfig implementations will complain about type
mismatch otherwise: e.g., an attempt to read a string value from an integer
key with wxRegConfig will fail.

The result is an element of enum EntryType:

\begin{verbatim}
  enum EntryType
  {
    Unknown,
    String,
    Boolean,
    Integer,
    Float
  };
\end{verbatim}

\membersection{wxConfigBase::GetFirstGroup}\label{wxconfigbasegetfirstgroup}

\constfunc{bool}{GetFirstGroup}{\param{wxString\& }{str}, \param{long\&}{
index}}

Gets the first group.

\pythonnote{The wxPython version of this method returns a 3-tuple
consisting of the continue flag, the value string, and the index for
the next call.}

\membersection{wxConfigBase::GetFirstEntry}\label{wxconfigbasegetfirstentry}

\constfunc{bool}{GetFirstEntry}{\param{wxString\& }{str}, \param{long\&}{
index}}

Gets the first entry.

\pythonnote{The wxPython version of this method returns a 3-tuple
consisting of the continue flag, the value string, and the index for
the next call.}

\membersection{wxConfigBase::GetNextGroup}\label{wxconfigbasegetnextgroup}

\constfunc{bool}{GetNextGroup}{\param{wxString\& }{str}, \param{long\&}{
index}}

Gets the next group.

\pythonnote{The wxPython version of this method returns a 3-tuple
consisting of the continue flag, the value string, and the index for
the next call.}

\membersection{wxConfigBase::GetNextEntry}\label{wxconfigbasegetnextentry}

\constfunc{bool}{GetNextEntry}{\param{wxString\& }{str}, \param{long\&}{
index}}

Gets the next entry.

\pythonnote{The wxPython version of this method returns a 3-tuple
consisting of the continue flag, the value string, and the index for
the next call.}

\membersection{wxConfigBase::GetNumberOfEntries}\label{wxconfigbasegetnumberofentries}

\constfunc{uint }{GetNumberOfEntries}{\param{bool }{bRecursive = FALSE}}

\membersection{wxConfigBase::GetNumberOfGroups}\label{wxconfigbasegetnumberofgroups}

\constfunc{uint}{GetNumberOfGroups}{\param{bool }{bRecursive = FALSE}}

Get number of entries/subgroups in the current group, with or without its
subgroups.

\membersection{wxConfigBase::GetPath}\label{wxconfigbasegetpath}

\constfunc{const wxString\&}{GetPath}{\void}

Retrieve the current path (always as absolute path).

\membersection{wxConfigBase::GetVendorName}\label{wxconfigbasegetvendorname}

\constfunc{wxString}{GetVendorName}{\void}

Returns the vendor name.

\membersection{wxConfigBase::HasEntry}\label{wxconfigbasehasentry}

\constfunc{bool}{HasEntry}{\param{wxString\& }{strName}}

returns TRUE if the entry by this name exists

\membersection{wxConfigBase::HasGroup}\label{wxconfigbasehasgroup}

\constfunc{bool}{HasGroup}{\param{const wxString\& }{strName}}

returns TRUE if the group by this name exists

\membersection{wxConfigBase::IsExpandingEnvVars}\label{wxconfigbaseisexpandingenvvars}

\constfunc{bool}{IsExpandingEnvVars}{\void}

Returns TRUE if we are expanding environment variables in key values.

\membersection{wxConfigBase::IsRecordingDefaults}\label{wxconfigbaseisrecordingdefaults}

\func{bool}{IsRecordingDefaults}{\void} const

Returns TRUE if we are writing defaults back to the config file.

\membersection{wxConfigBase::Read}\label{wxconfigbaseread}

\constfunc{bool}{Read}{\param{const wxString\& }{key}, \param{wxString*}{
str}}

Read a string from the key, returning TRUE if the value was read. If the key
was not found, {\it str} is not changed.

\constfunc{bool}{Read}{\param{const wxString\& }{key}, \param{wxString*}{
str}, \param{const wxString\& }{defaultVal}}

Read a string from the key. The default value is returned if the key was not
found.

Returns TRUE if value was really read, FALSE if the default was used.

\constfunc{wxString}{Read}{\param{const wxString\& }{key}, \param{const
wxString\& }{defaultVal}}

Another version of {\it Read()}, returning the string value directly.

\constfunc{bool}{Read}{\param{const wxString\& }{ key}, \param{long*}{ l}}

Reads a long value, returning TRUE if the value was found. If the value was
not found, {\it l} is not changed.

\constfunc{bool}{Read}{\param{const wxString\& }{ key}, \param{long*}{ l},
\param{long}{ defaultVal}}

Reads a long value, returning TRUE if the value was found. If the value was
not found, {\it defaultVal} is used instead.

\constfunc{long }{Read}{\param{const wxString\& }{key}, \param{long}{
defaultVal}}

Reads a long value from the key and returns it. {\it defaultVal} is returned
if the key is not found.

NB: writing

{\small \begin{verbatim} conf->Read("key", 0); \end{verbatim} }

won't work because the call is ambiguous: compiler can not choose between two
{\it Read} functions. Instead, write:

{\small \begin{verbatim} conf->Read("key", 0l); \end{verbatim} }

\constfunc{bool}{Read}{\param{const wxString\& }{ key}, \param{double*}{ d}}

Reads a double value, returning TRUE if the value was found. If the value was
not found, {\it d} is not changed.

\constfunc{bool}{Read}{\param{const wxString\& }{ key}, \param{double*}{ d},
 \param{double}{ defaultVal}}

Reads a double value, returning TRUE if the value was found. If the value was
not found, {\it defaultVal} is used instead.

\constfunc{bool}{Read}{\param{const wxString\& }{ key}, \param{bool*}{ b}}

Reads a bool value, returning TRUE if the value was found. If the value was
not found, {\it b} is not changed.

\constfunc{bool}{Read}{\param{const wxString\& }{ key}, \param{bool*}{ d},
\param{bool}{ defaultVal}}

Reads a bool value, returning TRUE if the value was found. If the value was
not found, {\it defaultVal} is used instead.

\pythonnote{In place of a single overloaded method name, wxPython
implements the following methods:\par
\indented{2cm}{\begin{twocollist}
\twocolitem{{\bf Read(key, default="")}}{Returns a string.}
\twocolitem{{\bf ReadInt(key, default=0)}}{Returns an int.}
\twocolitem{{\bf ReadFloat(key, default=0.0)}}{Returns a floating point number.}
\end{twocollist}}
}

\membersection{wxConfigBase::RenameEntry}\label{wxconfigbaserenameentry}

\func{bool}{RenameEntry}{\param{const wxString\& }{ oldName}, \param{const wxString\& }{ newName}}

Renames an entry in the current group. The entries names (both the old and
the new one) shouldn't contain backslashes, i.e. only simple names and not
arbitrary paths are accepted by this function.

Returns FALSE if the {\it oldName} doesn't exist or if {\it newName} already
exists.

\membersection{wxConfigBase::RenameGroup}\label{wxconfigbaserenamegroup}

\func{bool}{RenameGroup}{\param{const wxString\& }{ oldName}, \param{const wxString\& }{ newName}}

Renames a subgroup of the current group. The subgroup names (both the old and
the new one) shouldn't contain backslashes, i.e. only simple names and not
arbitrary paths are accepted by this function.

Returns FALSE if the {\it oldName} doesn't exist or if {\it newName} already
exists.

\membersection{wxConfigBase::Set}\label{wxconfigbaseset}

\func{wxConfigBase *}{Set}{\param{wxConfigBase *}{pConfig}}

Sets the config object as the current one, returns the pointer to the previous
current object (both the parameter and returned value may be NULL)

\membersection{wxConfigBase::SetExpandingEnvVars}\label{wxconfigbasesetexpandingenvvars}

\func{void}{SetExpandEnvVars }{\param{bool }{bDoIt = TRUE}}

Determine whether we wish to expand environment variables in key values.

\membersection{wxConfigBase::SetPath}\label{wxconfigbasesetpath}

\func{void}{SetPath}{\param{const wxString\& }{strPath}}

Set current path: if the first character is '/', it's the absolute path,
otherwise it's a relative path. '..' is supported. If the strPath doesn't
exist it is created.

\membersection{wxConfigBase::SetRecordDefaults}\label{wxconfigbasesetrecorddefaults}

\func{void}{SetRecordDefaults}{\param{bool }{bDoIt = TRUE}}

Sets whether defaults are written back to the config file.

If on (default is off) all default values are written back to the config file.
This allows the user to see what config options may be changed and is probably
useful only for wxFileConfig.

\membersection{wxConfigBase::Write}\label{wxconfigbasewrite}

\func{bool}{Write}{\param{const wxString\& }{ key}, \param{const wxString\& }{
value}}

\func{bool}{Write}{\param{const wxString\& }{ key}, \param{long}{ value}}

\func{bool}{Write}{\param{const wxString\& }{ key}, \param{double}{ value}}

\func{bool}{Write}{\param{const wxString\& }{ key}, \param{bool}{ value}}

These functions write the specified value to the config file and return TRUE
on success.

\pythonnote{In place of a single overloaded method name, wxPython
implements the following methods:\par
\indented{2cm}{\begin{twocollist}
\twocolitem{{\bf Write(key, value)}}{Writes a string.}
\twocolitem{{\bf WriteInt(key, value)}}{Writes an int.}
\twocolitem{{\bf WriteFloat(key, value)}}{Writes a floating point number.}
\end{twocollist}}
}