Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

This commit was manufactured by cvs2svn to create tag 'M_STABLE'.

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/tags/M_STABLE@40387 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Bryan Petty
2006-07-30 23:36:38 +00:00
parent 6a06841c34
commit 9aea121b6c
4223 changed files with 1680500 additions and 3876 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4961
docs/html/gettext/gettext.htm Normal file
View File

File diff suppressed because it is too large Load Diff

222
docs/html/gettext/msgfmt.htm Normal file
View File

@@ -0,0 +1,222 @@
<!-- manual page source format generated by PolyglotMan v3.0.3a12, -->
<!-- available via anonymous ftp from ftp.cs.berkeley.edu:/ucb/people/phelps/tcltk/rman.tar.Z -->
<HTML>
<HEAD>
<TITLE>msgfmt(1) manual page</TITLE>
</HEAD>
<BODY>
<A HREF="#toc">Table of Contents</A><P>
<H2><A NAME="sect0" HREF="#toc0">NAME </A></H2>
msgfmt - create a message object from a message file
<H2><A NAME="sect1" HREF="#toc1">SYNOPSIS
</A></H2>
<B>msgfmt</B> [ <B>-v</B> ] [ <B>-o</B><I> output-file</I> ] ...
<H2><A NAME="sect2" HREF="#toc2">DESCRIPTION </A></H2>
<P>
<B>msgfmt</B> creates message
object files from portable object files (<I>filename<B>.po </B></I>), without changing
the portable object files. <P>
The <B>.po </B> file contains messages displayed to
users by system commands or by application programs. <B>.po</B> files can be edited,
and the messages in them can be rewritten in any language supported by
the system. <P>
The <B><A HREF="http://hoth.stsci.edu/man/man1/xgettext.html">xgettext</B>(1)</A>
command can be used to create <B>.po</B> files from
script or programs. <P>
<B>msgfmt</B> interprets data as characters according to the
current setting of the <FONT SIZE=-1><B>LC_CTYPE </B></FONT>
locale category.
<H3><A NAME="sect3" HREF="#toc3">Portable Object Files
</A></H3>
<P>
Formats for all <B>.po</B> files are the same. Each <B>.po</B> file contains one or
more lines, with each line containing either a comment or a statement.
Comments start the line with a hash mark (#) and end with the newline
character. All comments are ignored. The format of a statement is:
<DL>
<DT><I>directive</I>
value </DT>
<DD></DD>
</DL>
<P>
Each directive starts at the beginning of the line and is separated
from <I>value</I> by white space (such as one or more space or tab characters).
<I>value</I> consists of one or more quoted strings separated by white space.
Use any of the following types of directives: <P>
<blockquote><B>domain</B> <I>domainname</I> <BR>
<B>msgid</B>
<I>message_identifier</I> <BR>
<B>msgstr</B> <I>message_string</I> </blockquote>
<P>
The behavior of the <B>domain</B>
directive is affected by the options used. See <FONT SIZE=-1>OPTIONS</FONT>
for the behavior
when the <B>-o</B> option is specified. If the <B>-o</B> option is not specified, the
behavior of the <B>domain</B> directive is as follows: <blockquote>
<UL>
&#183;<LI>All <I>msgids</I> from the beginning
of each <B>.po</B> file to the first domain directive are put into a default
message object file, <B>messages.mo</B>. </LI>&#183;<LI>When <B>msgfmt</B> encounters a <B>domain</B><I> domainname</I>
directive in the <B>.po</B> file, all following <I>msgids</I> until the next <B>domain</B> directive
are put into the message object file </LI>&#183;<LI>Duplicate <I>msgids</I> are defined in
the scope of each domain. That is, a <I>msgid</I> is considered a duplicate only
if the identical <I>msgid</I> exists in the same domain. </LI>&#183;<LI>All duplicate <I>msgids</I>
are ignored. </LI>
</UL>
</blockquote>
<P>
The <B>msgid</B> directive specifies the value of a message identifier
associated with the directive that follows it. The <I>message_identifier</I> string
identifies a target string to be used at retrieval time. Each statement
containing a <B>msgid</B> directive must be followed by a statement containing
a <B>msgstr</B> directive. <P>
The <B>msgstr</B> directive specifies the target string associated
with the <I>message_identifier</I> string declared in the immediately preceding
<B>msgid</B> directive. <P>
Message strings can contain the escape sequences <B>\n</B> for
newline, <B>\t</B> for tab, <B>\v</B> for vertical tab, <B>\b</B> for backspace, <B>\r</B> for carriage
return, <B>\f</B> for formfeed, <B>\\</B> for backslash, \" for double quote, <B>\ddd</B> for octal
bit pattern, and <B>\xDD</B> for hexadecimal bit pattern.
<H2><A NAME="sect4" HREF="#toc4">OPTIONS </A></H2>
<DL>
<DT><B>-v</B> </DT>
<DD>Verbose.
List duplicate message identifiers. Message strings are not redefined.
</DD>
<DT><B>-o</B><I> output-file</I> </DT>
<DD>Specify output file name as <I>output-file</I>. All <B>domain</B> directives
and duplicate <I>msgids</I> in the <B>.po</B> file are ignored. </DD>
</DL>
<H2><A NAME="sect5" HREF="#toc5">EXAMPLES </A></H2>
In this example
<B>module1.po</B> and <B>module2.po</B> are portable message objects files. <P>
<blockquote> example%
cat module1.po <BR>
# default domain "messages.mo" <BR>
msgid "msg 1" <BR>
msgstr "msg
1 translation" <BR>
# <BR>
domain "help_domain" <BR>
msgid "help 2" <BR>
msgstr "help
2 translation" <BR>
# <BR>
domain "error_domain" <BR>
msgid "error 3" <BR>
msgstr "error
3 translation" <BR>
<P>
example% cat module2.po <BR>
# default domain "messages.mo"
<BR>
msgid "mesg 4" <BR>
msgstr "mesg 4 translation" <BR>
# <BR>
domain "error_domain"
<BR>
msgid "error 5" <BR>
msgstr "error 5 translation" <BR>
# <BR>
domain "window_domain"
<BR>
msgid "window 6" <BR>
msgstr "window 6 translation" <BR>
</blockquote>
<P>
The following command
will produce the output files, <B>messages.mo</B>, <B>help_domain.mo</B>, and <B>error_domain.mo</B>.
<DL>
<DT><B>example% msgfmt module1.po</B> </DT>
<DD></DD>
</DL>
<P>
The following command will produce the output
files, <B>messages.mo</B>, <B>help_domain.mo</B>, <B>error_domain.mo</B>, and <B>window_domain.mo</B>.
<DL>
<DT><B>example% msgfmt module1.po module2.po</B> </DT>
<DD></DD>
</DL>
<P>
The following example will produce
the output file <B>hello.mo</B>.
<DL>
<DT><B>example% msgfmt -o hello.mo module1.po module2.po</B>
</DT>
<DD></DD>
</DL>
<P>
Install message object files in <B>/usr/lib/locale/</B><I>locale</I><B><FONT SIZE=-1>/LC_MESSAGES/</FONT>
</B><I>domain</I><B>.mo</B>
where <I>locale</I> is the message locale as set by <B><A HREF="http://hoth.stsci.edu/man/man3C/setlocale.html">setlocale</B>(3C)</A>
, and <I>domain</I>
is text domain as set by <B>textdomain()</B>. The <B>/usr/lib/locale</B> portion can
optionally be changed by calling <B>bindtextdomain()</B>. See <B><A HREF="http://hoth.stsci.edu/man/man3C/gettext.html">gettext</B>(3C)</A>
.
<H2><A NAME="sect6" HREF="#toc6">ENVIRONMENT
</A></H2>
See <B><A HREF="http://hoth.stsci.edu/man/man5/environ.html">environ</B>(5)</A>
for descriptions of the following environmental variables
that affect the execution of <B>msgfmt</B>: <FONT SIZE=-1><B>LC_CTYPE</FONT>
</B>, <FONT SIZE=-1><B>LC_MESSAGES</FONT>
</B>, <FONT SIZE=-1><B>NLSPATH</FONT>
</B>.
<H2><A NAME="sect7" HREF="#toc7">ATTRIBUTES </A></H2>
See <B><A HREF="http://hoth.stsci.edu/man/man5/attributes.html">attributes</B>(5)</A>
for descriptions of the following attributes:
<P>
<TABLE BORDER=0>
<TR> <TD ALIGN=CENTER><B>ATTRIBUTE TYPE</B> </TD> <TD ALIGN=CENTER><B>ATTRIBUTE VALUE</B> </TD> </TR>
<TR> <TR> <TD ALIGN=LEFT>Availability </TD> <TD ALIGN=LEFT>SUNWloc </TD> </TR>
<TR> <TD ALIGN=LEFT>CSI
</TD> <TD ALIGN=LEFT>Enabled </TD> </TR>
</TABLE>
<H2><A NAME="sect8" HREF="#toc8">SEE ALSO </A></H2>
<B><A HREF="http://hoth.stsci.edu/man/man1/xgettext.html">xgettext</B>(1)</A>
, <B><A HREF="http://hoth.stsci.edu/man/man3C/gettext.html">gettext</B>(3C)</A>
, <B><A HREF="http://hoth.stsci.edu/man/man3C/setlocale.html">setlocale</B>(3C)</A>
, <B><A HREF="http://hoth.stsci.edu/man/man5/attributes.html">attributes</B>(5)</A>
,
<B><A HREF="http://hoth.stsci.edu/man/man5/environ.html">environ</B>(5)</A>
<H2><A NAME="sect9" HREF="#toc9">NOTES </A></H2>
<P>
Neither <B>msgfmt</B> nor any <B>gettext()</B> routine imposes a limit
on the total length of a message. However, each line in the <B>*.po</B> file is
limited to <FONT SIZE=-1><B>MAX_INPUT </B></FONT>
(512) bytes. <P>
Installing message catalogs under the
C locale is pointless, since they are ignored for the sake of efficiency.
<P>
<HR><P>
<A NAME="toc"><B>Table of Contents</B></A><P>
<UL>
<LI><A NAME="toc0" HREF="#sect0">NAME</A></LI>
<LI><A NAME="toc1" HREF="#sect1">SYNOPSIS</A></LI>
<LI><A NAME="toc2" HREF="#sect2">DESCRIPTION</A></LI>
<UL>
<LI><A NAME="toc3" HREF="#sect3">Portable Object Files</A></LI>
</UL>
<LI><A NAME="toc4" HREF="#sect4">OPTIONS</A></LI>
<LI><A NAME="toc5" HREF="#sect5">EXAMPLES</A></LI>
<LI><A NAME="toc6" HREF="#sect6">ENVIRONMENT</A></LI>
<LI><A NAME="toc7" HREF="#sect7">ATTRIBUTES</A></LI>
<LI><A NAME="toc8" HREF="#sect8">SEE ALSO</A></LI>
<LI><A NAME="toc9" HREF="#sect9">NOTES</A></LI>
</UL>
</BODY></HTML>

144
docs/html/gettext/xgettext.htm Normal file
View File

@@ -0,0 +1,144 @@
<!-- manual page source format generated by PolyglotMan v3.0.3a12, -->
<!-- available via anonymous ftp from ftp.cs.berkeley.edu:/ucb/people/phelps/tcltk/rman.tar.Z -->
<HTML>
<HEAD>
<TITLE>xgettext(1) manual page</TITLE>
</HEAD>
<BODY>
<A HREF="#toc">Table of Contents</A><P>
<H2><A NAME="sect0" HREF="#toc0">NAME </A></H2>
xgettext - extract gettext call strings from C programs
<H2><A NAME="sect1" HREF="#toc1">SYNOPSIS
</A></H2>
<B>xgettext</B> [ <B>-ns</B> ] [ <B>-a</B> [ <B>-x</B><I> exclude-file</I> ] ] [ <B>-c</B><I> comment-tag</I> ] [ <B>-d</B><I> default-domain</I>
] [ <B>-j</B> ] [ <B>-m</B><I> prefix</I> ] [ <B>-M</B><I> suffix</I> ] [ <B>-p</B><I> pathname</I> ] <B>-</B>| <I>filename</I> ... <BR>
<B>xgettext</B>
<B>-h</B>
<H2><A NAME="sect2" HREF="#toc2">DESCRIPTION </A></H2>
<P>
<B>xgettext</B> is used to automate the creation of portable
message files (<B>.po</B>). A <B>.po</B> file contains copies of `C' strings that are found
in ANSI C source code in <I>filename</I> or the standard input if `<B>-</B>' is specified
on the command line. The <B>.po</B> file can be used as input to the <B><A HREF="http://hoth.stsci.edu/man/man1/msgfmt.html">msgfmt</B>(1)</A>
utility, which produces a binary form of the message file that can be
used by application during run-time. <P>
<B>xgettext</B> writes <I>msgid</I> strings from
<B><A HREF="http://hoth.stsci.edu/man/man3C/gettext.html">gettext</B>(3C)</A>
calls in <I>filename</I> to the default output file <B>messages.po</B>. The
default output file name can be changed by <B>-d</B> option. <I>msgid</I> strings in
<B>dgettext()</B> calls are written to the output file where <I>domainname</I> is the
first parameter to the <B>dgettext()</B> call. <P>
By default, <B>xgettext</B> creates a
<B>.po</B> file in the current working directory, and each entry is in the same
order the strings are extracted from <I>filenames</I>. When the <B>-p</B> option is specified,
the <B>.po</B> file is created in the <I>pathname</I> directory. An existing <B>.po</B> file
is overwritten. <P>
Duplicate <I>msgid</I>s are written to the <B>.po</B> file as comment
lines. When the <B>-s </B> option is specified, the <B>.po</B> is sorted by the <I>msgid</I>
string, and all duplicated <I>msgid</I>s are removed. All <I>msgstr</I> directives in
the <B>.po</B> file are empty unless the <B>-m </B> option is used.
<H2><A NAME="sect3" HREF="#toc3">OPTIONS </A></H2>
<DL>
<DT><B>-n</B> </DT>
<DD>Add comment
lines to the output file indicating file name and line number in the source
file where each extracted string is encountered. These lines appear before
each <I>msgid</I> in the following format: <blockquote><B>#</B> <B># File: </B><I>filename</I><B>, line: </DD>
</DL>
</B><I>line-number</I>
</blockquote>
<DL>
<DT><B>-s</B> </DT>
<DD>Generate output sorted by <I>msgid</I>s with all duplicate <I>msgid</I>s removed.
</DD>
<DT><B>-a</B> </DT>
<DD>Extract all strings, not just those found in <B><A HREF="http://hoth.stsci.edu/man/man3C/gettext.html">gettext</B>(3C)</A>
, and <B>dgettext
()</B> calls. Only one <B>.po</B> file is created. </DD>
<DT><B>-c</B><I> comment-tag</I> </DT>
<DD>The comment block
beginning with <I>comment-tag</I> as the first token of the comment block is
added to the output <B>.po</B> file as <I>#</I> delimited comments. For multiple domains,
<B>xgettext</B> directs comments and messages to the prevailing text domain. </DD>
<DT><B>-d</B><I>
default-domain</I> </DT>
<DD>Rename default output file from <B>messages.po</B> to <I>default-domain</I>
<B>.po</B>. </DD>
<DT><B>-j</B> </DT>
<DD>Join messages with existing message files. If a <B>.po</B> file does not
exist, it is created. If a <B>.po</B> file does exist, new messages are appended.
Any duplicate <B>msgid</B>s are commented out in the resulting <B>.po</B> file. Domain
directives in the existing <B>.po</B> file are ignored. Results not guaranteed
if the existing message file has been edited. </DD>
<DT><B>-m</B><I> prefix</I> </DT>
<DD>Fill in the <I>msgstr</I>
with <I>prefix</I>. This is useful for debugging purposes. To make <I>msgstr</I> identical
to <I>msgid</I>, use an empty string (<B>"" </B>) for <I>prefix</I>. </DD>
<DT><B>-M</B><I> suffix</I> </DT>
<DD>Fill in the
<I>msgstr</I> with <I>suffix</I>. This is useful for debugging purposes. </DD>
<DT><B>-p</B><I> pathname</I>
</DT>
<DD>Specify the directory where the output files will be placed. This option
overrides the current working directory. <BR>
</DD>
<DT><B>-x</B><I> exclude-file</I> </DT>
<DD>Specify a <B>.po</B>
file that contains a list of <I>msgid</I>s that are not to be extracted from
the input files. The format of <I>exclude-file</I> is identical to the <B>.po</B> file.
However, only the <I>msgid</I> directive line in <I>exclude-file</I> is used. All other
lines are simply ignored. The <B>-x</B> option can only be used with the <B>-a</B> option.
</DD>
<DT><B>-h</B> </DT>
<DD>Print a help message on the standard output. </DD>
</DL>
<H2><A NAME="sect4" HREF="#toc4">ATTRIBUTES </A></H2>
See <B><A HREF="http://hoth.stsci.edu/man/man5/attributes.html">attributes</B>(5)</A>
for descriptions of the following attributes: <P>
<TABLE BORDER=0>
<TR> <TD ALIGN=CENTER><B>ATTRIBUTE TYPE</B> </TD> <TD ALIGN=CENTER><B>ATTRIBUTE
VALUE</B> </TD> </TR>
<TR> <TR> <TD ALIGN=LEFT>Availability </TD> <TD ALIGN=LEFT>SUNWloc </TD> </TR>
</TABLE>
<H2><A NAME="sect5" HREF="#toc5">SEE ALSO </A></H2>
<B><A HREF="http://hoth.stsci.edu/man/man1/msgfmt.html">msgfmt</B>(1)</A>
, <B><A HREF="http://hoth.stsci.edu/man/man3C/gettext.html">gettext</B>(3C)</A>
, <B><A HREF="http://hoth.stsci.edu/man/man5/attributes.html">attributes</B>(5)</A>
<H2><A NAME="sect6" HREF="#toc6">NOTES </A></H2>
<B>xgettext</B> is not able to extract cast strings, for example ANSI
C casts of literal strings to <B>(const char *)</B>. This is unnecessary anyway,
since the prototypes in <B>&lt;libintl.h&gt;</B> already specify this type. <P>
<HR><P>
<A NAME="toc"><B>Table of Contents</B></A><P>
<UL>
<LI><A NAME="toc0" HREF="#sect0">NAME</A></LI>
<LI><A NAME="toc1" HREF="#sect1">SYNOPSIS</A></LI>
<LI><A NAME="toc2" HREF="#sect2">DESCRIPTION</A></LI>
<LI><A NAME="toc3" HREF="#sect3">OPTIONS</A></LI>
<LI><A NAME="toc4" HREF="#sect4">ATTRIBUTES</A></LI>
<LI><A NAME="toc5" HREF="#sect5">SEE ALSO</A></LI>
<LI><A NAME="toc6" HREF="#sect6">NOTES</A></LI>
</UL>
</BODY></HTML>

BIN
docs/html/icons/no.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 298 B

BIN
docs/html/icons/somewhat.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 290 B

BIN
docs/html/icons/yes.gif Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 290 B

225
docs/html/roadmap.htm Normal file
View File

@@ -0,0 +1,225 @@
<HTML>
<HEAD>
<TITLE>wxWindows Roadmap</TITLE>
</HEAD>
<BODY>
<a name="top"></a>
<font face="Arial, Lucida Sans, Helvetica">
<table width=100% border=4 cellpadding=5 cellspacing=0>
<tr>
<td bgcolor="#660000">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#FFFFFF">
wxWindows Roadmap
</font>
</td>
</tr>
</table>
<P>
<CENTER>
<a href="#schedule">Schedule</a> | <a href="#todo">To-Do List</a>
</CENTER>
<P>
This page represents current thinking about where wxWindows is going in the near,
medium and long-term. It also serves as a schedule for new releases so
that both developers and users can know what to expect when, at least approximately.<P>
We are adopting the Linux kernel style of numbering system where odd minor version numbers are development
versions, and even numbers are stable versions. For example, 2.1.x are development releases,
and the next 'stable' or final release of it would be 2.2.<P>
Bug-fix patches to the stable release (if made) then become point
releases of 2.2 (2.2.x) while development continues with wild abandon
on 2.3.x until the end of the next development cycle when it is
released as 2.4.<P>
Development versions that end up on the FTP site or CD-ROM, as opposed to remaining
in the CVS archive, are semi-stable -- i.e. they are checked for compilation and
run-time problems, but not as thoroughly as the stable versions.<P>
Note that since the wxWindows effort is voluntary, these are not hard-and-fast deadlines:
but we will endeavour to follow them as closely as possible.<P>
Note also that the releases described are for wxGTK, wxMSW and wxMotif ports. wxMac currently follows
its own development path but is due to merge with the main code base in November/December.
Also, minor snapshot releases for specific platforms may be
available at dates convenient to the developers.<P>
<CENTER>
<HR> <FONT SIZE=+2><I><B><a name="schedule">Schedule</a></B></I></FONT> <HR>
</CENTER>
<P>
<H4>Release 2.1.14</H4>
Release date: March 21st, 2000<P>
This will be the final beta release before the final 2.2 release. It will be
synchronized for as many platforms as possible (at least Windows and GTK,
probably Motif and hopefully Mac).
Changes since the last synchronized release (2.1.11):
<ul>
<li>First beta release of wxBase
<li>New or significantly improved base classes: wxDateTime, wxLongLong,
wxCmdLineParser, wxDir, wxStopWatch
<li>Much better i18n support, encoding conversion on the fly, wxFontMapper
<li>New wxGrid class
<li>New wxCalendarCtrl class
<li>Dynamic toolbar/menubar management
<li>Better image formats support: TIFF (new), PCX (8 and 24 bit saving added)
<li>Attributes (custom colours/font) support in wxTreeCtrl, wxListCtrl
<li>Impressive number of fixed bugs in wxMSW and wxGTK including various
incompatibilities between the two
<li>wxIPCxxx classes reworked.
<li>Several new samples and demos.
</ul>
<P>
<H4>Release 2.2 (stable)</H4>
Release date: mid. April, 2000.<P>
This is the next stable version of wxWindows. No new features since
2.1.14 beta.
<ul>
<li>bugs found during 2.1.14 will be fixed.
<li>translations of text strings used in wxWindows.
<li>documentation updated to include all new classes.
</ul>
<P>
<H4>Release 2.3</H4>
Release date: ?
<ul>
<li>Context sensitive help.
<li>More i18n issues: dates, times, ...
<li>POSIX-like regular expressions support for all platforms.
<li>Encryption support (interface to OpenSSL).
<li>Full UDP support in wxSocket
<li>wxPlot
<li>XML for resource files.
<li>Built-in support for configuring key bindings
</ul>
<P>
<H4>Release 2.4 (stable)</H4>
Release date: ?
Stable version of 2.3.
<ul>
<li>wxMac release.
<li>wxBeOS port.
</ul>
<P>
<CENTER>
<HR> <FONT SIZE=+2><I><B><a name="todo">To-Do List</a></B></I></FONT> <HR>
</CENTER>
<P>
Developers: please feel free to add to these, and delete them when they are done.
<P>
<B><I>Already done</I></B><P>
<P>
<ul>
<li>wxHTML printing. When finished, this will allow an application to generate
printed reports with very little effort.
<li>Split library into several, for base (classes and functions usable by console and GUI
applications), console (classes and functions usable by console application only)
and GUI (classes and functions usable by GUI application only).
<li>wxSocket.
<li>wxImage handlers in separate .h and .cpp files.
<li>PCX writing code.
<li>Tidying of timer code, addition of wxStopWatch class.
<li>wxDateTime class.
<li>Rotated text support (might still be improved)
<li>Bug tracking system.
</ul>
<B><I>General</I></B><P>
<ul>
<li>Extend and unify drag and drop handling (e.g. we need to specify multiple drop targets
that can handle multiple formats).
<li>Expand the number of controls that can be specified in a WXR file;
add constraint specification to WXR syntax and Dialog Editor; add multilanguage support to WXR.
May be we'd better change the format completely and replace WXR with XML
(providing conversion utility for old files)?
<li>Context sensitive help: we need to have wxHelpEvent which would be
generated when the help for a given control is requested and a standard
handler for it in wxWindow which would invoke the default help system with the
correct help id.
<li>Rewrite Dialog Editor.
<li>Modem-oriented classes: wxDialUpManager for dialing up the ISP and
determining if there is a connection to Internet on the machine and
wxPhoneDialer for dialing arbitrary phone numbers and otherwise communicating
with the modem.
<li>GIF animation code (support is already there, but wxAnimation is not yet complete)
<li>Debug wxPostScriptDC further.
<li>Regular expressions support.
<li>Expansion of wxHTML to support further tags, and frames.
<li>MGL port (see Backroom/Future Ports page).
<li>FreeType support.
<li>Support for 'skins', perhaps using a set of alternative control and window classes
written generically in wxWindows.
<li>Serial and parallel port support.
<li>Modem and telephony support.
<li>Book, tutorial.
<li>More examples.
</ul>
<P>
<B><I>wxMSW</I></B><P>
<ul>
<li>Windows CE port.
<li>Write a RC to WXR converter.
</ul>
<P>
<B><I>wxGTK</I></B><P>
<ul>
<li>GNOME/KDE integration libraries.
</ul>
<P>
<B><I>wxMotif</I></B><P>
<ul>
<li>Fix menu accelerators
<li>Fix refresh problems
<li>Allow wxSystemSettings to be configurable, perhaps via a control
panel application.
</ul>
</BODY>
</HTML>

953
docs/html/standard.htm Normal file
View File

@@ -0,0 +1,953 @@
<HTML>
<HEAD>
<TITLE>wxWindows Programmer Style Guide</TITLE>
</HEAD>
<BODY>
<a name="top"></a>
<font face="Arial, Lucida Sans, Helvetica">
<table width=100% border=0 cellpadding=5 cellspacing=0>
<tr>
<td bgcolor="#C4ECF9">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#000000">
wxWindows Programmer Style Guide
</font>
</td>
</tr>
</table>
<P>
by <A HREF=mailto:zeitlin@dptmaths.ens-cachan.fr>Vadim Zeitlin</A><P>
This guide is intended for people who are (or intending to start) writing code
for <A HREF="http://www.wxwindows.org" target=_top>wxWindows</A> class library.
<P>
The guide is separated into two parts: the first one addresses the general
compatibility issues and is not wxWindows-specific. The advises in this part
will hopefully help you to write programs which compile and run on greater
variety of platforms. The second part details the wxWindows code organization and
its goal it to make wxWindows as uniform as possible without imposing too
many restrictions on the programmer.
<P>
Acknowledgements: This guide is partly based on <A
HREF="http://www.mozilla.org/hacking/portable-cpp.html" target=_top>
C++ portability guide</A> by David Williams.
<P>
<H3>General C++ Rules</H3>
<UL>
<LI>New or not widely supported C++ features</LI>
<OL>
<LI><A HREF="#no_templates">Don't use C++ templates</A></LI>
<LI><A HREF="#no_exceptions">Don't use C++ exceptions</A></LI>
<LI><A HREF="#no_rtti">Don't use RTTI</A></LI>
<LI><A HREF="#no_namespaces">Don't use namespaces</A></LI>
<LI><A HREF="#no_stl">Don't use STL</A></LI>
<LI><A HREF="#no_fordecl">Don't declare variables inside <TT>for()</TT></A></LI>
<LI><A HREF="#no_nestedclasses">Don't use nested classes</A></LI>
<LI><A HREF="#no_newlogicalops">Don't use new logical operators keywords</A></LI>
</OL>
<BR>
<LI>Other compiler limitations</LI>
<OL>
<LI><A HREF="#no_ternarywithobjects">Use ternary operator ?: carefully</A></LI>
<LI><A HREF="#no_autoaggregate">Don't use initializers with automatic arrays</A></LI>
<LI><A HREF="#no_dtorswithoutctor">Always have at least one constructor in a class with destructor</A></LI>
</OL>
<BR>
<LI>General recommendations</LI>
<OL>
<LI><A HREF="#no_cppcommentsinc">No C++ comments in C code></A></LI>
<LI><A HREF="#no_globals">No global variables with constructor</A></LI>
<LI><A HREF="#no_warnings">Turn on all warnings and eradicate them</A></LI>
<LI><A HREF="#no_assume_sizeof">Don't rely on <TT>sizeof(int) == 2</TT>...</A></LI>
<LI><A HREF="#no_assignment_in_if">No assignments in conditional expressions</A></LI>
<LI><A HREF="#no_comment_code">Use <TT>#if 0</TT> rather than comments to temporarily disable blocks of code</A></LI>
<LI><A HREF="#no_overloaded_virtuals">Avoid overloaded virtual functions</A></LI>
<LI><A HREF="#no_extra_semicolon">Don't use extra semi-colons on top level</A></LI>
</OL>
<BR>
<LI>Unix/DOS differences</LI>
<OL>
<LI><A HREF="#use_cpp_ext">Use .cpp for C++ source file extension</A></LI>
<LI><A HREF="#no_backslash">Don't use backslash ('\\') in &#35;includes</A></LI>
<LI><A HREF="#no_carriagereturn">Avoid carriage returns in cross-platform code</A></LI>
<LI><A HREF="#no_caps_in_filenames">Use only lower letter filenames</A></LI>
<LI><A HREF="#no_incomplete_files">Terminate the files with a new-line</A></LI>
<LI><A HREF="#no_case_only_diff">Avoid globals differing by case only</A></LI>
</OL>
<BR>
<LI>Style choices</LI>
<OL>
<LI><A HREF="#naming_conv">Naming conventions: use <TT>m_</TT> for members</A></LI>
<LI><A HREF="#no_void_param">Don't use <TT>void</TT> for functions without arguments</A></LI>
<LI><A HREF="#no_const_int">Don't use <TT>const</TT> for non pointer/reference arguments</A></LI>
</OL>
</UL>
<P>
<H3>wxWindows Rules</H3>
<UL>
<LI>Files location and naming conventions</LI>
<OL>
<LI><A HREF="#file_locations">File locations</A></LI>
<LI><A HREF="#include_guards">Include guards</A></LI>
<LI><A HREF="#pch">Precompiled headers</A></LI>
</OL>
<BR>
<LI>File layout and indentation</LI>
<OL>
<LI><A HREF="#wxwin_header">wxWindows standard header</A></LI>
<LI><A HREF="#indentation">Indent your code with 4 spaces (no tabs!)</A></LI>
<LI><A HREF="#class_decl">Order of parts in a class declarations</A></LI>
</OL>
<BR>
<LI>More about naming conventions</LI>
<OL>
<LI><A HREF="#wx_prefix">Use wx or WX prefix for all public symbols</A></LI>
<LI><A HREF="#wxdllexport">Use WXDLLEXPORT with all classes/functions in wxMSW/common code</A></LI>
<LI><A HREF="#set_get">Use Set/Get prefixes for accessors</A></LI>
<LI><A HREF="#constants">wxNAMING_CONSTANTS</A></LI>
</OL>
<BR>
<LI>Miscellaneous</LI>
<OL>
<LI><A HREF="#forward_decl">Use forward declarations whenever possible</A></LI>
<LI><A HREF="#debug_macros">Use debugging macros</A></LI>
</OL>
</UL>
<HR>
<H3>General C++ Rules</H3>
<UL>
<LI>New or not widely supported C++ features</LI>
<P>The usage of all features in this section is not recommended for one reason: they appeared in C++ relatively recently and are not yet
supported by all compilers. Moreover, when they're supported, there are
differences between different vendor's implementations. It's understandable that
you might love one (or all) of these features, but you surely can write C++
programs without them. Where possible, workarounds to compensate for absence
of your favourite C++ abilities are indicated.
<P>Just to suppress any doubts that there are compilers which don't support
these new features, you can think about Win16 (a.k.a. Win 3.1) compilers,
<I>none</I> of which supports <I>any</I> feature from the list below.
<OL>
<P><LI><A NAME="no_templates"></A><B>Don't use C++ templates</B></LI><P>
Besides the reasons mentioned above, template usage also makes the
program compile much slower (200%-300% is not uncommon) and their support
even in the compilers which have had it for a long time is far from perfect
(the best example is probably gcc).
<P><U>Workaround</U>: The things you would like to use templates for are,
most commonly, polymorphic containers (in the sense that they can contain objects of
any type without compromising C++ type system, i.e. using <TT>void *</TT>
is out of question). wxWindows provides <A HREF="TODO">dynamic
arrays and lists</A> which are sufficient in 99% of cases - please don't hesitate
to use them. Lack of template is not a reason to use static arrays or
type-less (passing by <TT>void *</TT>) containers.
<P><LI><A NAME="no_exceptions"></A><B>Don't use C++ exceptions</B></LI><P>
The C++ exception system is an error-reporting mechanism. Another reasons not to use it,
besides portability, are the performance penalty it imposes (small, but, at least for
current compilers, non-zero), and subtle problems with
memory/resource deallocation it may create (the place where you'd like to use
C++ exceptions most of all are the constructors, but you need to be very
careful in order to be able to do it).
<P><U>Workaround</U>: there is no real workaround, of course, or the exceptions
wouldn't have been added to the language. However, there are several rules which
might help here:<P>
<OL>
<LI>Every function returns an integer (or at least boolean) error code.
<P>There is no such thing as a function that never fails - even if it can't
fail now, it might do it later, when modified to be more powerful/general.
Put the <TT>int</TT> or <TT>bool</TT> return type from the very beginning!<P>
</LI><LI>Every function you call may fail - check the return code!
<P>Never rely on the function's success, always test for a possible error.<P>
</LI><LI>Tell the user about the error, don't silently ignore them.
<P>Exceptions are always caught and, normally, processed when they're
caught. In the same manner, the error return code must always be processed
somehow. You may choose to ignore it, but at least tell the user that
something wrong happened using <A HREF="TODO"><TT>wxLogError</TT></A> or
<A HREF="TODO"><TT>wxLogWarning</TT></A> functions. All wxWindows
functions (must) log the error messages on failure - this can be disabled
by using <A HREF="TODO">wxLogNull</A> object before calling it.
<P>Examples:<UL>
<LI><I>Wrong</I>:
<PRE>
void ReadAddressBookFile(const wxString& strName)
{
wxFile file;
if ( !file.Open(strFile) )
return;
...process it...
}
</PRE>
</LI><LI><I>Correct</I>:
<PRE>
// returns false if the address book couldn't be read
bool ReadAddressBookFile(const wxString& strName)
{
wxFile file;
if ( !file.Open(strFile) ) {
// wxFile logged an error because file couldn't be opened which
// contains the system error code, however it doesn't know what
// this file is for and an error message "can't open $GLCW.ADB"
// can be quite confusing for the user. Here we say what we mean.
wxLogError("Can't read address book from '%s'!",
strName.c_str());
return false;
}
...process it...
return true;
}
</PRE>
or, if it's not an error if file doesn't exist (here we could just check
its existence, but let's suppose that there is no <TT>wxFile::Exists()</TT>)
we can also write:
<PRE>
// returns false if address book file doesn't exist
bool ReadAddressBookFile(const wxString& strName)
{
wxFile file;
// start a block inside which all log messages are suppressed
{
wxLogNull noLog;
if ( !file.Open(strFile) )
return false;
}
...process it...
return true;
}
</PRE></LI>
</UL>
</OL>
<P><LI><A NAME="no_rtti"></A><B>Don't use RTTI</B></LI><P>
RTTI stands for Run-Time Type Information and there is probably no other
reason not to use it except the portability issue and the fact that it adds
<TT>sizeof(void *)</TT> bytes to any class having virtual functions (at least,
in the implementations I'm aware of).
<P><U>Workaround</U>: use wxWindows RTTI system which allows you to do almost
everything which the new C++ RTTI, except that, of course, you have to use
macros instead of the (horrible looking, BTW) <TT>dynamic_cast</TT>.
<P><LI><A NAME="no_namespaces"></A><B>Don't use namespaces</B></LI><P>
This topic is subject to change with time, however for the moment all wxWindows
classes/functions live in the global namespace.
<P><U>Workaround</U>: None.
<P><LI><A NAME="no_stl"></A><B>Don't use STL</B></LI><P>
STL is the new C++ standard library, proposing all kinds of template containers
and generic algorithm implementations. Templates are the heart (and almost
everything else) of the library, so its usage is out of question. Besides, even
with the compilers which do support templates, STL has many of its own problems,
there are many "not 100% standard compatible" vendor implementations, none of existing debuggers understands its
complicated data structures, ... the list can go on (almost) forever.
<P><U>Workaround</U>: Use wxString, dynamic arrays and lists and other wxWindows
classes. wxString has many of the most often used functions of std::string STL
class (typedef to be precise).
<P><LI><A NAME="no_fordecl"></A><B>Don't declare variables inside <TT>for()
</TT></B></LI><P>
The scope of a variable declared inside <TT>for()</TT> statement changed several
years ago, however many compilers still will complain about second declaration
of <TT>i</TT> in the following code:
<PRE>
for ( int i = 0; i &lt; 10; i++ ) {
...
}
...
for ( int i = 0; i &lt; 10; i++ ) {
...
}
</PRE>
even though if it's perfectly legal now.
<P><U>Workaround</U>: write this instead:
<PRE>
int i;
for ( i = 0; i &lt; 10; i++ ) {
...
}
...
for ( i = 0; i &lt; 10; i++ ) {
...
}
</PRE>
or, even better, use different names for the variables in the different for
loops (in particular, avoid mute variable names like <tt>i<tt> above) - then
you can declare them in the loop statement and don't pollute the outer name
space with local loop variables.
<P><LI><A NAME="no_nestedclasses"></A><B>Don't use nested classes</B></LI><P>
Nested classes are, without doubt, a very good thing because they allow to hide
"private" (in the sense that they're used only inside the library) classes and,
generally, put the related things together.
<P>Unfortunately, some compilers have trouble understanding them, so we must
sacrifice the ideals of software design to get a working program in this case.
<P><U>Workaround</U>: instead of
<PRE>
// in the header
class PublicLibClass {
...
private:
class PrivateLibClass { ... } m_object;
};
</PRE>
you can try the following:
<PRE>
// in the header
class PrivateLibClass; // fwd decl
class PublicLibClass {
...
private:
class PrivateLibClass *m_pObject;
};
// in the .cpp file
class PrivateLibClass { ... };
PublicLibClass::PublicLibClass()
{
m_pObject = new PrivateLibClass;
...
}
PublicLibClass::~PublicLibClass()
{
delete m_pObject;
}
</PRE>
<P>A nice side effect is that you don't need to recompile all the files
including the header if you change the PrivateLibClass declaration (it's
an example of a more general interface/implementation separation idea).
<P><LI><A NAME="no_newlogicalops"></A><B>Don't use new logical operators keywords</B></LI><P>
The C++ standard has introduced the following new reserved words: <tt>or</tt>,
<tt>and</tt>, <tt>not</tt>, <tt>xor</tt>, <tt>bitand</tt>, <tt>bitor</tt>,
<tt>compl</tt>, <tt>and_eq</tt>, <tt>or_eq</tt>, <tt>not_eq</tt>,
<tt>or_eq</tt> which can be used instead of the usual C operations &#38;&#38;,
&#124;&#124;, &#126; etc.
<P>This wonderful (and not backwards compatible in addition to being
absolutely useless) new feature means that these new keywords should not be
used as the variable names - even if current compilers usually will accept
this, your code will break in the future. For most of the keywords, using them
as variable names is quite unlikely, but <tt>or</tt> and <tt>compl</tt> were
used in the wxWindows sources which seems to indicate that they are the most
likely candidates.
<P>It goes without saying that these new keywords should not be used instead
of the tradional C operators neither both because most compilers don't accept
them and because using them in C code makes it less readable.
</OL>
<BR>
<LI>Other compiler limitations</LI><P>
This section lists the less obvious limitations of the current C++ compilers
which are less restrictive than the ones mentioned in the previous section but
are may be even more dangerous as a program which compiles perfectly well on
some platform and seems to use only standard C++ featurs may still fail to
compile on another platform and/or with another compiler.
<OL>
<P><LI><A NAME="no_ternarywithobjects"></A><B>Use ternary operator ?: carefully</B></LI><P>
The ternary operator <TT>?:</TT> shouldn't be used with objects (i.e. if any
of its operands are objects) because some compilers (notably Borland C++) fail
to compile such code.
<P><U>Workaround</U>: use <TT>if/else</TT> instead.
<PRE>
wxString s1, s2;
// Borland C++ won't compile the line below
wxString s = s1.Len() &lt; s2.Len() ? s1 : s2;
// but any C++ compiler will compile this
wxString s;
if ( s1.Len() &lt; s2.Len() )
s = s1;
else
s = s2;
</PRE>
<P><LI><A NAME="no_autoaggregate"></A><B>Don't use initializers with automatic arrays</B></LI><P>
The initializers for automatic array variables are not supported by some older
compilers. For example, the following line
<PRE>
int daysInMonth[12] = { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 };
</PRE>
will fail to compile with HP-UX C++ compiler.
<P><U>Workaround</U>: either make the array static or initialize each item
separately: in the (stupid) example above, the array should be definitely
declared as <TT>static const</TT> (assuming that the leap years are dealt with
elsewhere somehow...) which is ok. When an array is really not const, you
should initialize each element separately.
<P><LI><A NAME="no_dtorswithoutctor"></A><B>Always have at least one constructor in a class with destructor</B></LI><P>
It is a good rule to follow in general, but some compilers (HP-UX) enforce it.
So even if you are sure that the default constructor for your class is ok but
it has a destructor, remember to add an empty default constructor to it.
</OL>
<BR>
<LI>General recommendations</LI><P>
While the recommendations in the previous section may not apply to you if you're
only working with perfect compilers which implement the very newest directives of
C++ standard, this section contains compiler- (and language-) independent advice
which <B>must</B> be followed if you wish to write correct, i.e. working, programs. It
also contains some C/C++ specific remarks in the end which are less
important.
<OL>
<P><LI><A NAME="no_cppcommentsinc"><B>No C++ comments in C code></B></LI><P>
Never use C++ comments in C code - not all C compilers/preprocessors
understand them. Although we're mainly concerned with C++ here, there are
several files in wxWindows sources tree which are compiled with C compiler.
Among them are <TT>include/wx/setup.h</TT> and <TT>include/wx/expr.h</TT>.
Another thing related to C vs C++ preprocessor differences is that some old C
preprocessors require that all directives start in the first column (while
it's generally allowed to have any amount of whitespace before them in C++),
so you should start them in the beginning of the line in files which are
compiled with C compiler.
<P><LI><A NAME="no_globals"></A><B>No global variables with constructors</B></LI><P>
In C++, the constructors of global variables are called before the
<TT>main()</TT> function (or <TT>WinMain()</TT> or any other program entry point)
starts executing. Thus, there is no possibility to initialize <I>anything</I>
before the constructor call. The order of construction is largely
implementation-defined, meaning that there is no guarantee that one global
object will be initialized before another one (except if they are both defined
in the same translation unit, i.e. .cpp file). Most importantly, no custom
memory allocation operators are installed at the moment of execution of global
variables constructors, so a (less restrictive) rule is that you should have
no global variables which allocate memory (or do anything else non-trivial) in
the constructor. Of course, if an object doesn't allocate memory in its constructor
right now, it may start making it later, so you can only be sure about this if
you don't use <I>any</I> variables of object (as opposed to simple:
<TT>int</TT>, ...) types. Example: currently, wxString doesn't allocate memory
in its default constructor, so you might think that having a global (initially)
empty wxString is safe. However, if wxString starts allocating some minimal
amount of memory in its default constructor (which doesn't look unreasonable),
you would have all kinds of problems with <TT>new</TT>
and <TT>delete</TT> operators (overloaded in wxWindows), especially because the first <TT>new</TT> called
is the standard one (before wxWindows overloads them) and <TT>delete</TT> will
be the overloaded operator.
<P><LI><A NAME="no_warnings"></A><B>Turn on all warnings and eradicate them</B></LI><P>
Give the compiler a chance to help you - turn on all warnings! You should always
use the maximum available warning level of your compiler and understand and
correct each of them. If, for whatever reasons, a compiler gives a warning on
some perfectly legal line of code and you can't change it, please insert a
comment indicating it in the code. Most oftenly, however, all compiler warnings
may be avoided (not suppressed!) with minimal changes to your code.
<P><LI><A NAME="no_assume_sizeof"></A><B>Don't rely on <TT>sizeof(int) == 2</TT>...</B></LI><P>
You should never assume any absolute constraints on data type sizes. Currently,
we have 16-bit, 32-bit and 64-bit machines and even inside each class data type
sizes are different. A small table illustrates it quite well:
<TABLE BORDER COLS=5 WIDTH="100%" NOSAVE >
<TR>
<TD>Architecture/OS</TD>
<TD>sizeof(short)</TD>
<TD>sizeof(int)</TD>
<TD>sizeof(long)</TD>
<TD>sizeof(void *)</TD>
</TR>
<TR>
<TD>i386/Windows 3.1</TD>
<TD>2</TD>
<TD>2</TD>
<TD>4</TD>
<TD>2 or 4</TD>
</TR>
<TR>
<TD>i386/Windows 95</TD>
<TD>2</TD>
<TD>4</TD>
<TD>4</TD>
<TD>4</TD>
</TR>
<TR>
<TD>Merced/Win64</TD>
<TD>2</TD>
<TD>4</TD>
<TD>4</TD>
<TD>8</TD>
</TR>
<TR>
<TD>Alpha/Linux</TD>
<TD>???</TD>
<TD>???</TD>
<TD>???</TD>
<TD>???</TD>
</TR>
</TABLE>
<P><LI><A NAME="no_assignment_in_if"></A><B>No assignments in conditional expressions</B></LI><P>
Although close to the heart of many C programmers (I plead guilty), code like
classical <TT>if ( (c = getchar()) != EOF )</TT> is bad because it prevents you
from enabling "assignment in conditional expression" warning (see also
<A HREF="#no_warnings">above</A>) which is helpful to detect common
mistypes like <TT>if ( x = 2 )</TT> instead of <TT>if ( x == 2 )</TT>.
<P><LI><A NAME="no_comment_code"></A><B>Use <TT>#if 0</TT> rather than comments to temporarily
disable blocks of code</B></LI><P>
If you have to temporarily disable some code, use
<PRE>
#if 0 // VZ: I think this code is unneeded, it probably must be removed
...
#endif // 0
</PRE>
instead of
<PRE>
/*
...
*/
</PRE>
The reason is simple: if there are any <TT>/* ... */</TT> comments inside
<TT>...</TT> the second version will, of course, miserably fail.
<P><LI><A NAME="no_overloaded_virtuals"></A><B>Avoid overloaded virtual functions</B></LI><P>
You should avoid having overloaded virtual methods in a base class because if
any of them is overriden in a derived class, then all others must be overriden
as well or it would be impossible to call them on an object of derived class.
For example, the following code:
<PRE>
class Base
{
public:
virtual void Read(wxFile& file);
virtual void Read(const wxString& filename);
};
class Derived : public Base
{
public:
virtual void Read(wxFile& file) { ... }
};
...
Derived d;
d.Read("some_filename"); // compile error here!
</PRE>
will fail to compile because the base class function taking <TT>filename</TT>
is hidden by the virtual function overriden in the derived class (this is
known as [virtual] function name hiding problem in C++).
<P>
The standard solution to this problem in wxWindows (where we have such
situations quite often) is to make both <TT>Read()</TT> functions not virtual
and introduce a single virtual function <TT>DoRead()</TT>. Usually, it makes
sense because the function taking a filename is (again, usually) implemented
in terms of the function reading from a file anyhow (but making only this
functions not virtual won't solve the above problem!).
<P>
So, the above declarations should be written as:
<PRE>
class Base
{
public:
void Read(wxFile& file);
void Read(const wxString& filename);
protected:
virtual void DoRead(wxFile& file);
};
class Derived : public Base
{
protected:
virtual void DoRead(wxFile& file) { ... }
};
</PRE>
This technique is widely used in many of wxWindows classes - for example,
<TT>wxWindow</TT> has more than a dozen of <TT>DoXXX()</TT> functions which
allows to have many overloaded versions of commonly used methods such as
<TT>SetSize()</TT>
<P><LI><A NAME="no_extra_semicolon"></A><B>Don't use extra semi-colons on top level</B></LI><P>
Some compilers don't pay any attention to extra semicolons on top level, as in
<PRE>
class Foo { };;
</PRE>
while others complain loudly about it. Of course, you would rarely put 2
semicolons yourself, but it may happen if you're using a macro
(<TT>IMPLEMENT_something</TT>, for example) which already has a ';' inside and
put another one after it.
</OL>
<BR>
<LI>Unix/DOS differences</LI><P>
Two operating systems supported by wxWindows right now are (different flavours
of) Unix and Windows 3.1/95/NT (although Mac, OS/2 and other ports exist/are
being developed as well). The main differences between them are summarized
here.
<OL>
<P><LI><A NAME="use_cpp_ext"></A><B>Use .cpp for C++ source file extension</B></LI><P>
There is, unfortunately, no standard exceptions for C++ source files. Different
people use .C, .cc, .cpp, .cxx, .c++ and probably several others I forgot. Some
compilers don't care about extension, but there are also other ones which can't
be made to compile any file with "wrong" extension. Such compilers are very
common in DOS/Windows land, that's why the .cpp extension is the least likely to
cause any problems - it's the standard one under DOS and will probably be
accepted by any Unix compiler as well (any counter examples?). The extension
for the header files is .h.
<P><LI><A NAME="no_backslash"></A><B>Don't use backslash ('\\') in &#35;includes</B></LI><P>
Although it's too silly to mention, please don't use backslashes in
<TT>&#35;include</TT> preprocessor statement. Even not all Windows compilers accept
it, without speaking about all other ones.
<P><LI><A NAME="no_carriagereturn"></A><B>Avoid carriage returns in cross-platform code</B></LI><P>
This problem will hopefully not arise at all, with CVS taking care of this
stuff, however it's perhaps not useless to remember that many Unix compilers
(including, but not limited to, gcc) don't accept carriage returns
(= <Ctrl-M> = '\r') in C/C++ code.
<P><LI><A NAME="no_caps_in_filenames"></A><B>Use only lower case filenames</B></LI><P>
DOS/Windows 3.1 isn't case sensitive, Windows 95/NT are case preserving, but not
case sensitive. To avoid all kinds of problems with compiling under Unix (or
any other fully case-sensitive OS), please use only lower case letters in the
filenames.
<P><LI><A NAME="no_incomplete_files"></A><B>Terminate the files with a new-line</B></LI><P>
While DOS/Windows compilers don't seem to mind, their Unix counterparts don't
like files without terminating new-line. Such files also give a warning message
when loaded to vim (the Unix programmer's editor of choice :-)), so please think
about terminating the last line.
<P><LI><A NAME="no_case_only_diff"></A><B>Avoid globals differing by case only</B></LI><P>
The linker on VMS is case-insensitive. Therefore all external variables and
functions which differ only in case are not recognized by the linker as
different, so all externals should differ in more than the case only:
i.e. <TT>GetId</TT> is the same as <TT>GetID</TT>.
</OL>
<BR>
<LI>Style choices</LI><P>
All wxWindows specific style guidelines are specified in the next
section, here are the choices which are not completely arbitrary,
but have some deeper and not wxWindows-specific meaning.
<OL>
<P><LI><A NAME="naming_conv"></A><B>Naming conventions: use <TT>m_</TT> for members</B></LI><P>
We all know how important it is to write readable code. One of the first steps
in this direction is the choice of naming convention. It may be quite vague or
strictly define the names of all the variables and function in the program,
however it surely must somehow allow the reader to distinguish between
variable and functions and local variables and member variables from the first
glance.
<P>The first requirement is commonly respected, but for some strange reasons, the
second isn't, even if it's much more important because, after all, the immediate
context usually allows you to distinguish a variable from a function in
C/C++ code. On the other hand, you <I>cannot</I> say what <TT>x</TT> in the
following code fragment is:
<PRE>
void Foo::Bar(int x_)
{
...
x = x_;
...
}
</PRE>
It might be either a local variable (unluckily the function is too long so you
don't see the variable declarations when you look at <TT>x = x_</TT> line), a
member variable or a global variable - you have no way of knowing.
<P>The wxWindows naming convention gives you, the reader of the code, much more
information about <TT>x</TT>. In the code above you know that it's a local
variable because:<P>
<OL>
<LI>global variables are always prefixed with <TT>g_</TT></LI>
<LI>member variables are always prefixed with <TT>m_</TT></LI>
<LI>static variables are always prefixed with <TT>s_</TT></LI>
</OL>
<P>Examples:
<PRE>
extern int g_x; // of course, 'x' is not the best name for a global...
void Bar()
{
int x;
}
class Foo {
public:
void SetX(int x) { m_x = x; }
private:
int m_x;
};
</PRE>
As you see, it also solves once and for all the old C++ programmer's question:
how to call <TT>SetX()</TT> parameter? The answer is simple: just call it
<TT>x</TT> because there is no ambiguity with <TT>Foo::m_x</TT>.
<P>The prefixes can be combined to give <TT>ms_</TT> and <TT>gs_</TT> for static
member (a.k.a. class) variables and static global variables.
<P>The convention is, of course, completely worthless if it is not followed:
nothing like being sure that <TT>x</TT> is a local variable in the code fragment
above and discovering later the following lines in the header:
<PRE>
class Foo {
...
int x; // I don't like wxWindows naming convention
};
</PRE>
Please do use these prefixes, they make your code much easier to read. Also
please notice that it has nothing to do with the so-called <I>Hungarian notation</I>
which is used in wxMSW part of wxWindows code and which encodes the <I>type</I>
of the variable in its name - it is actually quite useful in C, but has little
or no sense in C++.
<P><LI><A NAME="no_void_param"></A><B>Don't use <TT>void</TT> for functions without
arguments</B></LI><P>
In ANSI C, <TT>void Foo()</TT> takes an arbitrary number of arbitrarily typed
arguments (although the form <TT>void Foo(...)</TT> is preferred) and <TT>void
Foo(void)</TT> doesn't take any arguments. In C++, however, the situation is
different and both declarations are completely equivalent. As there is no need
to write <TT>void</TT> in this situation, let's not write it - it can only be
confusing and create an impression that it really means something when it's not
at all the case.
<P><LI><A NAME="no_const_int"></A><B>Don't use <TT>const</TT> for non pointer/reference
arguments</B></LI><P>
In both C and C++ an argument passed by value cannot be modified - or, more
precisely, if it is modified in the called function, only the local copy is
really changed, not the caller's variable. So, semantically speaking, there is
no difference between <TT>void Foo(int)</TT> and <TT>void Foo(const int)</TT>.
However, the <TT>const</TT> keyword is confusing here, adds nothing to the code
and even cannot be removed if <TT>Foo()</TT> is virtual and overridden (because
the names are mangled differently). So, <I>for arguments passed by value</I>
you shouldn't use <TT>const</TT>.
<P>Of course, it doesn't apply to functions such as
<TT>void PrintMessage(const char *text)</TT> where <TT>const</TT> is mandatory.
</OL>
</UL>
<P>
<H3>wxWindows rules</H3>
<UL>
<P><LI>File location and naming conventions</LI><P>
<OL>
<P><LI><A NAME="file_locations"></LI><B>File locations</B><P>
The wxWindows files for each supported platform have their own subdirectories
in "include" and "src". So, for example, there is "src/msw", "include/gtk"
etc. There are also two special subdirectories called "common" and
"generic". The common subdirectory contains the files which are platform
independent (wxObject, wxString, ...) and the generic one the generic
implementations of GUI widgets, i.e. those which use only other wxWindows
classes to implement them. For the platforms where the given functionality
cannot be implemented natively, the generic implementation is used and the native
one is used for the others. As I feel that it becomes a bit too confusing,
here is an example: wxMessageBox function is implemented natively under
Windows (where it just calls MessageBox API), but there is also a generic
implementation which is used under, for example, GTK. A generic class should
normally have a name that distinguishes it from any platform-specific implementation.
A #define will allow wxGenericMessageDialog to be wxMessageDialog on some
platforms, for example.
<P>This scheme applies not only for the .cpp files, but also for the headers.
However, as the program using wxWindows should (ideally) not use any
"<TT>&#35;ifdef &lt;platform&gt;</TT>" at all, the headers are always included with
"<TT>&#35;include &lt;wx/msgdlg.h&gt;</TT>" (for example). This file, in turn, includes
the right header for given platform. Any new headers should conform to this
setup as well to allow including <TT>&lt;wx/foo.h&gt;</TT> on any platform.<P>
Note that wxWindows implementation files should use quotes when including wxWindows
headers, not angled brackets. Applications should use angled brackets. This
ensures that the dependencies are correctly handled by the compiler.
<P><LI><A NAME="include_guards"></LI><B>Include guards</B><P>
To minimize the compile time C++ programmers often use so called include
guards: for example, in the header file foo.h you might have
<PRE>
&#35;ifndef _FOO_H_
&#35;define _FOO_H_
... all header contents ...
&#35;endif
//_FOO_H_
</PRE>
In this way, the header will only be included once for the compilation
of any .cpp (of course, it still will be included many times for the
compilation of the whole project, so it has nothing to do with precompiled
headers). wxWindows is no exception and also uses include guards which should use
the above form, except for top-level headers which include files with identical
names, in which case you should use _FOO_H_BASE_.
<P><LI><A NAME="pch"></LI><B>Precompiled headers</B><P>
The precompiled headers greatly (we're speaking about orders of hundreds of
percent here) reduce the compilation time. wxWindows uses them if the target
compiler supports them (it knows about MS Visual C++, Borland C++ and g++).
You should include all the headers included from <TT><wx/wx_prec.h></TT> only
inside "<TT>&#35;if !USE_PRECOMP</TT>" to avoid unnecessary overhead in the case
when the precompiled headers are used.<P>
The start of a cpp implementation file after the heading might look like this:<P>
<PRE>
&#35;ifdef __GNUG__
&#35;pragma implementation "bitmap.h"
&#35;endif
// For compilers that support precompilation, includes "wx.h".
&#35;include "wx/wxprec.h"
&#35;ifdef __BORLANDC__
&#35;pragma hdrstop
&#35;endif
&#35;ifndef WX_PRECOMP
&#35;include &lt;stdio.h&gt;
&#35;include "wx/setup.h"
&#35;include "wx/list.h"
&#35;include "wx/utils.h"
&#35;include "wx/app.h"
&#35;include "wx/palette.h"
&#35;include "wx/bitmap.h"
&#35;include "wx/icon.h"
&#35;endif
&#35;include "wx/msw/private.h"
&#35;include "assert.h"
</PRE>
<P>Any header file should containg the following lines:
<PRE>
&#35;ifdef __GNUG__
&#35;pragma interface "foo.h"
&#35;endif
</PRE>
and the corresponding .cpp file:
<PRE>
&#35;ifdef __GNUG__
&#35;pragma implementation "foo.h"
&#35;endif
</PRE> for g++ compilation.
</OL>
<P><LI>File layout and indentation</LI><P>
<OL>
<P><LI><A NAME="wxwin_header"></LI><B>wxWindows standard header</B> <a href="header.txt">here</a>. The
copyright holder is the original author. It is assumed the author does not assert copyright,
under the terms of the wxWindows licence. This is a legal interpretation of the informal
usage 'public domain' (the copyright holder does not assert the copyright).<P>
<P><LI><A NAME="indentation"></LI><B>Indent your code with 4 spaces (no tabs!)</B>
<P><LI><A NAME="class_decl"></LI><B>Order of parts in a class declarations</B><P>
</OL>
<P><LI>More about naming conventions</LI><P>
<OL>
<P><LI><A NAME="wx_prefix"></LI><B>Use wx or WX prefix for all public symbols</B>.
wx should be used for functions and classes, WX for macros.
<P><LI><A NAME="wxdllexport"</LI><B>Use WXDLLEXPORT with all classes/functions in
wxMSW/common code</B>
The title says it all - every public (in the sense that it is not internal to
the library) function or class should have WXDLLEXPORT macro in its
declaration to allow compilation of wxWindows as shared library. For example:<P>
<pre>
bool WXDLLEXPORT wxYield(void);
class WXDLLEXPORT MyClass; // (for forward declarations and real declarations)
WXDLLEXPORT_DATA(extern wxApp*) wxTheApp;
</pre>
The reason for the strange syntax for data is that some compilers use different
keyword ordering for exporting data.
<P><LI><A NAME="set_get"></LI><B>Use Set/Get prefixes for accessors</B><P>
There is a convention in wxWindows to prefix the accessors (i.e. any simple, in
general, inline function which does nothing else except changing or returning
the value of a member variable) with either <TT>Set</TT> or <TT>Get</TT>.
<P><LI><A NAME="constants"></LI><B>wxNAMING_CONSTANTS</B><P>
The constants in wxWindows code should be defined using <TT>enum</TT> C++
keyword (and not with <TT>#define</TT> or <TT>static const int</TT>). They
should be declared in the global scope (and not inside class declaration) and
their names should start with a <TT>wx</TT> prefix. Finally, the constants
should be in all capital letters (except the first 2) to make it easier to
distinguish them from the variables with underscores separating the words.
<P>For example, file-related constants should be declared like this:
<pre>
enum
{
wxFILEOPEN_READ,
wxFILEOPEN_WRITE,
wxFILEOPEN_READWRITE
};
</pre>
</OL>
<P><LI>Miscellaneous</LI><P>
<OL>
<P><LI><A NAME="forward_decl"></LI><B>Use forward declarations whenever possible</B><P>
It's really a trivial piece of advice, but remember that using forward declarations
instead of including the header of corresponding class is better because not
only does it minimize the compile time, it also simplifies the dependencies
between different source files.
<P>On a related subject, in general, you should try not to include other
headers from a header file.
<P><LI><A NAME="debug_macros"></LI><B>Use debugging macros</B><P>
wxWindows provides the debugging macros <TT>wxASSERT, wxFAIL</TT> and
<TT>wxCHECK_RET</TT> in <TT><wx/wx.h></TT> file. Please use them as often as
you can - they will never do you any harm but can greatly simplify the bug
tracking both for you and for others.
<P>Also, please use <TT>wxFAIL_MSG("not implemented")</TT> instead of writing
stubs for not (yet) implemented functions which silently return incorrect
values - otherwise, a person using a not implemented function has no idea that
it is, in fact, not implemented.
<P>As all debugging macros only do something useful if the symbol
<TT>__WXDEBUG__</TT> is defined, you should compile your programs in debug mode to profit
from them.
</OL>
</UL>
<P>
<HR>
Please send any comments to <A HREF=mailto:zeitlin@dptmaths.ens-cachan.fr>Vadim Zeitlin</A>.
</font>
</BODY>
</HTML>

315
docs/html/wxbook.htm Normal file
View File

@@ -0,0 +1,315 @@
<HTML>
<HEAD>
<TITLE>wxWindows Book</TITLE>
</HEAD>
<BODY BGCOLOR=#FFFFFF TEXT=#000000 LINK=#FF0000 VLINK=#000000>
<font face="Arial, Lucida Sans, Helvetica">
<table width=100% border=0 cellpadding=5 cellspacing=0>
<tr>
<td bgcolor="#C4ECF9">
<font size=+1 face="Arial, Lucida Sans, Helvetica" color="#000000">
wxWindows Book
</font>
</td>
</tr>
</table>
<P>
<center>
<a href="#about">About</a> |
<a href="#participants">Participants</a> |
<a href="#publication">Publication</a> |
<!-- <a href="#suggestions">Suggestions</a> | -->
<a href="#format">Format</a> |
<a href="#style">Style guide</a> |
<a href="#titles">Titles</a> |
<a href="#contents">Contents</a>
</center>
<p>
<hr>
<p>
<H3><a name="about">About the wxWindows book</a></H3>
August 2000: the 'wxBook' project is getting going again,
with a good response from potential contributors.<P>
Robin Dunn has set up a <a href="http://wxwindows.org/mailman/listinfo/wxbook">wxBook mailing list</a>.<P>
The book will comprise 30 or so chapters dealing with progressively
more advanced areas of wxWindows; each chapter will be as stand-alone as
possible. The book will
not include the API reference, though this could be a
separate project. The book will be accompanied by a CD-ROM with
wxWindows and its documentation. It will initially be
available on-line, and when enough is done we will look for a
publisher.<P>
There will also be a separate small booklet which can easily be printed
out and which gives an overview of wxWindows facilities by taking
the reader through a single worked example. Guillermo Rodriguez
Garcia has volunteered to write this, and will use his Life!
demo to illustrate it.<P>
Goals for the book:<P>
<ol>
<li> to allow users to become accomplished wxWindows developers rapidly;
<li> to be useful over a longer period than just the first few weeks, since
there are a lot of complex areas to address and not all features will be
used up-front in a project;
<li> to promote wxWindows to a wider audience;
<li> to make at least some money for the authors.
</ol>
<P>
Audience: beginners + experienced wxWindows users, but with reasonable C++
knowledge.<P>
It is suggested that any financial return from the book be allocated on a points system,
with a predefined number of points for chapters, indexing, editing, proof-reading etc.<P>
<p>
<hr>
<p>
<H3><a name="participants">Participants</a></H3>
So far, the following people are interested in taking part in this project:<P>
<ul>
<li><a href="mailto:julian.smart@ukonline.co.uk">Julian Smart</a> -
editor and coordinator of the project; introductory chapter, some other
chapters.
<li><a href="mailto:guille@iies.es">Guillermo Rodriguez Garcia</a> - Separate tutorial booklet;
communication classes (wxSocket, wxXXXServer, some protocol stuff); timing and timers.
<li><a href="mailto:robin@alldunn.com">Robin Dunn</a> - wxPython chapter.
</i>
<li><a href="mailto:zeitlin@dptmaths.ens-cachan.fr">Vadim Zeitlin</a> - drag and drop, several other chapters.
<li><a href="mailto:roebling@uni-freiburg.de">Robert Roebling</a> - not known.
<li><a href="mailto:slavik2@czn.cz">Vaclav Slavik</a> - wxHTML section.
<li><a href="mailto:gtasker@fastpicsystems.com">George Tasker</a> - database chapter.
<li><a href="mailto:moreno@mochima.com">Carlos Moreno</a> - wxImage, wxBitmap.
<li><a href="mailto:Shiv@pspl.co.in">Shiv Shankar Ramakrishnan</a> - wxWindows advocacy, convincing your manager,
container classes and strings, comparison with STL
<li><a href="mailto:markusneifer@my-Deja.com">Markus Neifer</a> - user-defined events.
<!--
<li><a href="mailto:csomor@advancedconcepts.ch">Stefan Csomor</a>. The sequence of events i.e. which action provokes which event sequence,
this is implicit for the use on MSW, but very important for other systems; and porting to new platforms
-->
<!--
<li><a href="mailto:tomr@scitechsoft.com">Tom Ryan</a>, SciTech Software.
-->
<!--
<li><a href="mailto:karsten@phy.hw.ac.uk">Karsten Ballueder</a>. Short tutorials on some useful
GNU tools, like autoconf/configure/make, programming
strategies, etc.
-->
<!--
<li><a href="mailto:mheck@www.surveyorcorp.com">Matt Heck</a>, SurveyorCorp Inc.
<i>
<ol>
<li>a case study of how and why we've used wxWindows at Surveyor Corp., and
how it's worked out so far;
<li>an appendix something similar about how to use wxLIVID for video capture and display;
<li>proofreading
</ol>
-->
</ul>
<P>
Others welcome! Please contact <a href="mailto:julian.smart@ukonline.co.uk">Julian Smart</a>
if you would like to contribute.
<p>
<hr>
<p>
<H3><a name="publication">Publication</a></H3>
We will investigate publishers, especially O'Reilly. We will have to get together
several sample chapters to convince a publisher that the many-author approach will
work.<P>
<!--
Tom Ryan originally wrote:<P>
<PRE>
Hi Guys,
I just wanted to let you know that I have spoken with officials here
at California State University, Chico and they are potentially
interested in publishing a book on wxWindows! A wxWindows
book would give wxWindows a great deal of exposure.
These discussions came out of the fact that CSUC wanted to
switch from MFC to wxWindows in their GUI programming classes,
but there was not a book available for students to work with.
I was thinking that the first edition could be primarily the reference
documentation combined with a basic wxTutorial and examples. In
this case, it would be fairly straightforward to get something out
initially and then we could take it from there.
</PRE>
<p>
<a href="mailto:benles@powernet.net">Ben Allfree</a> has also expressed an interest
in publishing a wxWindows book, and distributing it via Amazon. Ben was thinking
in terms of a quickie job using the existing reference manual.<P>
Another publishing name to think of is O'Reilly. They would probably give us a lot
of guidance for style, formatting, etc.<P>
<a href="mailto:Roald.Ribe@winlink.no">Roald Ribe</a> writes:
"<a href="http://www.bruceeckel.com/javabook.html" target=_new>Thinking in Java</a>
is published both as a PDF for internet (by the author) and in print by Prentice Hall."<P>
-->
<P>
<hr>
<P>
<!--
<H3><a name="suggestions">Suggestions and comments</a></H3>
<ul>
<li>Chapter on converting from MFC. (Julian Smart)
<li>A chapter on why some inconsistencies are almost always going to show up in a
multiplatform toolkit, how to avoid them, how to deal with when you have
no choice, and (if wxBook explains the internals or philosophy of
wxWindows at all) how wxWindows attempts to minimize the number we
encounter. (Matt Heck)
<li>Creating the shortest possible path to writing "Hello World" from scratch in wxWindows. (Matt Heck)
<li>How will royalties for subsequent editions be shared out? (Tom Ryan)
<li>"My personal feeling is that this project will wind up being developed
by a small team, led by an editor that will wind up doing about half
of the total amount of work." (Tom Ryan)
</ul>
<P>
<hr>
<P>
-->
<H3><a name="format">File format</a></H3>
Possible formats:
<ul>
<li>Word
<li><a href="http://www.abisource.com" target=_top>Abiword</a>: possibly not developed enough yet, but
it can output Latex which would make conversion to Tex2RTF format quite simple
<li>Latex: favoured format so far. The LyX near-WYSIWYG word processor (Unix only) can output Latex.
See also <a href="http://www.esat.kuleuven.ac.be/~minten/NTTeXing/NTTeXing.html" target=_top>NTTex</a>
which uses EMACS as an editor. For an introduction to Latex, see <a href="ftp://ftp.tex.ac.uk/tex-archive/info/lshort" target=_top>here</a>.
A free TeX for Windows: see <a href="http://www.miktex.org/" target=_top>MikTex</a>. More TeX info: <a href="http://www.tug.org/" target=_top>TUG</a>.
<li>XML: hard to read/write
<li>SGML: ditto
<li>DocBook: don't have any information about this, but <a href="http://www.LinuxNinja.com/linux-admin/" target=_top>Linux Admin Made Easy</a>
uses it.
<li><a href="http://www.zope.org//Members/jim/StructuredTextWiki/StructuredTextNG" target=_top>Structured text</a> -
plain text with indentation and other elements to provide structure. The tools seem under-developed and there
doesn't seem to be a simple way of getting them without using the CVS Zope archive.
<li>troff - favoured by O'Reilly
</ul>
<P>
<hr>
<P>
<H3><a name="style">Style guide</a></H3>
We should write a style and formatting guide.<P>
<P>
<hr>
<P>
<H3><a name="titles">Book Titles</a></H3>
It would be good to include certain buzzwords such as Linux and open source, to get
a publisher's (and the potential reader's) attention. The trick is to do that and
not narrow the scope unduly.<P>
Suggestions for the main book:<P>
<ul>
<li>Multiplatform GUI development with wxWindows
<li>wxWindows: an open source multiplatform toolkit
<li>wxWindows: GUI development for Linux and other platforms
</ul>
<P>
Other book titles that a publisher might be interested (but would be distinct projects):<P>
<ul>
<li>Writing GTK+ Application Using wxWindows
<li>Migrating MFC Apps to Linux Using wxWindows
</ul>
<P>
<hr>
<P>
<H3><a name="contents">Contents</a></H3>
The following is open to discussion.<P>
<ul>
<li>Chapter 01: Introduction to wxWindows: history, advocacy, future developments
<li>Chapter 02: Installing wxWindows (and what tools to use)
<li>Chapter 03: C++ and wxWindows. Summarises the sorts of constructs used/not used, plus wxString class,
some conventions. Vadim suggests putting it in 1st chapter but I think it deserves a chapter of its own.
<li>Chapter 04: Getting started: Hello World. Introduces app class, frames, menus, status bar, message box
<li>Chapter 05: Basic event handling
<li>Chapter 06: Frames and menubars. The components of a frame, menubars.
<li>Chapter 07: Toolbars and status bars
<li>Chapter 08: Basic controls
<li>Chapter 09: Common dialogs
<li>Chapter 10: Custom dialogs and resources (XML + WXR)
<li>Chapter 11: Drawing on device contexts
<li>Chapter 12: Handling input (mouse, keyboard, joystick)
<li>Chapter 14: Sizers
<li>Chapter 15: Images and bitmaps
<li>Chapter 16: Clipboard and drag and drop
<li>Chapter 17: Advanced controls (list,tree,notebook,splitter,wxWizard,wxCalCtrl...)
<li>Chapter 18: Document/view classes
<li>Chapter 19: Scrolling
<li>Chapter 20: MDI
<li>Chapter 21: Printing
<li>Chapter 22: Providing help in your applications
<li>Chapter 23: Strings and internationalization
<li>Chapter 24: Collection and container classes
<li>Chapter 25: Memory management and debugging (including wxLog)
<li>Chapter 26: Run-time class information
<li>Chapter 27: Advanced event handling (user-defined events, ...)
<li>Chapter 28: Communication classes, including wxSocket
<li>Chapter 29: Database classes
<li>Chapter 30: File and stream classes
<li>Chapter 31: Configuration classes
<li>Chapter 32: Time, timers and idle processing
<li>Chapter 33: Writing multithreading applications
<li>Chapter 34: Perfecting your UI (Adapting to system settings, accelerators, ...)
<li>Chapter 35: Platform-specific programming (metafiles, OLE automation, taskbar, ...)
<li>Chapter 36: Using wxHTML
<li>Chapter 37: Using wxPython
<li>Chapter 38: wxBase?
<li>Appendix: Comparison with other toolkits: MFC, Qt etc.
</ul>
</font>
</BODY>
</HTML>