\hy-9{0}{
}










\hy-5{2}{User Manual for wxWindows 1.50: a portable C++ GUI toolkit}

\hy-6{3}{Julian Smart
Artificial Intelligence Applications Institute

University of Edinburgh
EH1 1HN}

April 1994






\hy-5{1}{

Contents

}
\hy-6{4}{Copyright notice}

\hy-6{6}{Introduction}

\hy-6{56}{Resource guide}

\hy-6{78}{Overview and comparison with other GUI models}

\hy-6{204}{Multi-platform development with wxWindows}

\hy-6{372}{Utilities supplied with wxWindows}

\hy-6{408}{Bugs and future developments for wxWindows}

\hy-6{428}{Troubleshooting}

\hy-6{457}{Tutorial}

\hy-6{519}{wxWindows Class Reference}

\hy-6{4491}{Glossary}




\hy-10{5}{Copyright notice}



Copyright (c) 1994 Artificial Intelligence Applications Institute,
The University of Edinburgh



Permission to use, copy, modify, and distribute this software and its
documentation for any purpose is hereby granted without fee, provided that the
above copyright notice, author statement and this permission notice appear in
all copies of this software and related documentation.

THE SOFTWARE IS PROVIDED ``AS-IS'' AND WITHOUT WARRANTY OF ANY KIND, EXPRESS,
IMPLIED OR OTHERWISE, INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

IN NO EVENT SHALL THE ARTIFICIAL INTELLIGENCE APPLICATIONS INSTITUTE OR THE
UNIVERSITY OF EDINBURGH BE LIABLE FOR ANY SPECIAL, INCIDENTAL, INDIRECT OR
CONSEQUENTIAL DAMAGES OF ANY KIND, OR ANY DAMAGES WHATSOEVER RESULTING FROM
LOSS OF USE, DATA OR PROFITS, WHETHER OR NOT ADVISED OF THE POSSIBILITY OF
DAMAGE, AND ON ANY THEORY OF LIABILITY, ARISING OUT OF OR IN CONNECTION WITH
THE USE OR PERFORMANCE OF THIS SOFTWARE.


\hy-10{7}{Introduction}


\hy-8{8}{What is wxWindows?}

\hy-8{10}{Why another cross-platform development tool?}

\hy-8{40}{wxWindows requirements}

\hy-8{48}{Availability and location of wxWindows}

\hy-8{53}{Acknowledgments}


\hy-10{57}{Resource guide}


This is a list of other sources of information and software
related to wxWindows.

\hy-8{58}{wxCLIPS}

\hy-8{60}{WinSock for wxWindows}

\hy-8{62}{GWX: DevGuide to wxWindows}

\hy-8{64}{wxXPM}

\hy-8{66}{CURSES port}

\hy-8{68}{wxWindows mailing list}

\hy-8{71}{World Wide Web}

\hy-8{74}{Ongoing projects}


\hy-10{79}{Overview and comparison with other GUI models}


wxWindows takes elements of other GUI APIs, and adds some elements of
its own.  Of course, it cannot hope to cover every (or even one) native
API completely.  The following sections discuss different GUI models
and compare these with what wxWindows provides.

\hy-8{80}{Windows}

\hy-8{102}{Dialog boxes}

\hy-8{107}{Menus}

\hy-8{111}{Events}

\hy-8{125}{Keyboard input}

\hy-8{131}{Repainting of windows}

\hy-8{134}{Scrolling}

\hy-8{140}{Printing}

\hy-8{142}{Programmatic versus interactive GUI building}

\hy-8{145}{Dimensions}

\hy-8{148}{Colour}

\hy-8{151}{On-line help}

\hy-8{155}{User preferences}

\hy-8{159}{Interprocess Communication}


\hy-10{205}{Multi-platform development with wxWindows}


This chapter describes the practical details of using wxWindows. Please
see the file install.txt for up-to-date installation instructions, and
changes.txt for differences between versions.

\hy-8{206}{Code structure}

\hy-8{223}{Include files}

\hy-8{267}{Libraries}

\hy-8{269}{Configuration}

\hy-8{276}{Makefiles}

\hy-8{302}{Windows-specific files}

\hy-8{311}{Memory models and memory allocation}

\hy-8{322}{Dynamic Link Libraries}

\hy-8{325}{Conditional compilation}

\hy-8{336}{Building on-line help}

\hy-8{342}{C++ issues}

\hy-8{360}{File handling}

\hy-8{365}{Large amounts of global data}


\hy-10{373}{Utilities supplied with wxWindows}


A number of `extras' are supplied with wxWindows, to complement
the GUI functionality in the main class library. These are found
below the utils directory and usually have their own source, library
and documentation directories. For larger user-contributed packages,
see the directory /pub/wxwin/contrib and \hy-13{374}{Resource Guide}.

\hy-8{375}{wxBuilder}

\hy-8{377}{wxToolBar}

\hy-8{380}{wxHelp}

\hy-8{384}{hyText}

\hy-8{386}{wxCLIPS}

\hy-8{388}{PROLOGIO}

\hy-8{396}{Tex2RTF}

\hy-8{402}{wxTreeLayout}

\hy-8{404}{wxGraphLayout}

\hy-8{406}{rcParser}


\hy-10{409}{Bugs and future developments for wxWindows}


\hy-8{410}{Bugs}

\hy-8{422}{Future developments}


\hy-10{429}{Troubleshooting}


\hy-8{430}{General}

\hy-8{435}{Motif-specific problems}

\hy-8{439}{Windows-specific problems}

\hy-8{450}{XView-specific problems}


\hy-10{458}{Tutorial}


This short tutorial takes a look at some of the supplied demonstration
programs.  The tutorial is incomplete and may be expanded in later
releases.

\hy-8{459}{The demo programs}


\hy-10{520}{wxWindows Class Reference}


In the following descriptions of the wxWindows classes and their member
functions, note that descriptions of inherited member functions are not
duplicated in derived classes unless their behaviour is different. So in
using a class such as wxCanvas, be aware that wxWindow functions may be
relevant.

Note also that arguments with default values may be omitted from a
function call, for brevity. Size and position arguments may usually be
given a value of -1 (the default), in which case wxWindows will choose a
suitable value.

The member functions are given in alphabetical order except for the
constructors and destructors which appear first.

\hy-8{521}{A Rough Guide}

\hy-8{573}{wxApp: wxObject}

\hy-8{619}{wxBitmap: wxObject}

\hy-8{656}{wxBrush: wxObject}

\hy-8{698}{wxBrushList: wxList}

\hy-8{722}{wxButton: wxItem}

\hy-8{796}{wxCanvas: wxWindow}

\hy-8{1056}{wxCanvasDC: wxDC}

\hy-8{1064}{wxCheckBox: wxItem}

\hy-8{1134}{wxChoice: wxItem}

\hy-8{1212}{wxClient: wxIPCObject}

\hy-8{1244}{wxColour: wxObject}

\hy-8{1271}{wxColourDatabase: wxObject}

\hy-8{1290}{wxColourMap: wxObject}

\hy-8{1298}{wxCommandEvent: wxEvent}

\hy-8{1352}{wxConnection: wxObject}

\hy-8{1459}{wxCursor: wxObject}

\hy-8{1504}{wxDC: wxObject}

\hy-8{1773}{wxDialogBox: wxPanel}

\hy-8{1856}{wxEnhDialogBox: wxDialogBox}

\hy-8{1919}{wxEvent: wxObject}

\hy-8{1950}{wxFont: wxObject}

\hy-8{1998}{wxFontList: wxList}

\hy-8{2021}{wxForm: wxObject}

\hy-8{2187}{wxFrame: wxWindow}

\hy-8{2341}{wxFunction}

\hy-8{2350}{wxIcon: wxObject}

\hy-8{2369}{wxHashTable: wxObject}

\hy-8{2424}{wxHelpInstance: wxClient}

\hy-8{2471}{wxItem: wxWindow}

\hy-8{2494}{wxKeyEvent: wxEvent}

\hy-8{2521}{wxList: wxObject}

\hy-8{2609}{wxListBox: wxItem}

\hy-8{2731}{wxMemoryDC: wxObject}

\hy-8{2750}{wxMenu: wxItem}

\hy-8{2828}{wxMenuBar: wxItem}

\hy-8{2907}{wxMessage: wxItem}

\hy-8{2936}{wxMetaFile: wxObject}

\hy-8{2952}{wxMetaFileDC: wxDC}

\hy-8{2968}{wxMouseEvent: wxEvent}

\hy-8{3073}{wxMultiText: wxText}

\hy-8{3082}{wxNode: wxObject}

\hy-8{3097}{wxObject}

\hy-8{3104}{wxPanel: wxWindow}

\hy-8{3217}{wxPathList: wxList}

\hy-8{3240}{wxPen: wxObject}

\hy-8{3289}{wxPenList: wxList}

\hy-8{3314}{wxPoint: wxObject}

\hy-8{3328}{wxPostScriptDC: wxDC}

\hy-8{3349}{wxPrinterDC: wxDC}

\hy-8{3363}{wxRadioBox: wxItem}

\hy-8{3471}{wxServer: wxIPCObject}

\hy-8{3486}{wxSlider: wxItem}

\hy-8{3533}{wxStringList: wxList}

\hy-8{3566}{wxText: wxWindow}

\hy-8{3614}{wxTextWindow: wxWindow}

\hy-8{3750}{wxTimer: wxObject}

\hy-8{3774}{wxTypeTree: wxList}

\hy-8{3846}{wxWindow: wxObject}

\hy-8{4043}{File functions}

\hy-8{4135}{String functions}

\hy-8{4154}{Dialog functions}

\hy-8{4242}{GDI functions}

\hy-8{4266}{System event functions}

\hy-8{4315}{Miscellaneous}


\hy-10{4492}{Glossary}

\hy-8{4493}{API}

\hy-8{4495}{Canvas}

\hy-8{4498}{DDE}

\hy-8{4500}{Device context}

\hy-8{4502}{Dialog box}

\hy-8{4504}{Frame}

\hy-8{4506}{GNU C++}

\hy-8{4508}{GUI}

\hy-8{4510}{Menu bar}

\hy-8{4512}{Metafile}

\hy-8{4514}{Open Look}

\hy-8{4516}{Panel}

\hy-8{4518}{RPC}

\hy-8{4520}{Status line}

\hy-8{4523}{Text subwindow}

\hy-8{4525}{XView}


\hy-10{9}{What is wxWindows?}

wxWindows is a class library for C++ providing GUI (Graphical User
Interface) and other facilities on more than one platform.  It currently
supports subsets of Open Look (XView), Motif and Windows 3.1 (including
Windows NT).  It was originally developed at the Artificial Intelligence
Applications Institute, University of Edinburgh, for internal use on a
medium-sized project: a hypertext-based knowledge-acquisition
and diagramming tool called HARDY. wxWindows has been released into
the public domain in the hope that others will also find it useful.

This manual discusses wxWindows in the context of multi-platform
development. For more detail on the wxWindows version 1.50 API
(Application Programming Interface) please refer to the separate
wxWindows reference manual.

Please note that in the following, ``Windows 3.1" refers to all
platforms related to Microsoft Windows, including 16-bit and 32-bit
variants. All trademarks are acknowledged.


\hy-10{11}{Why another cross-platform development tool?}

wxWindows was developed to provide a cheap and flexible way to maximize
investment in GUI application development.  While a number of commercial
class libraries already exist for cross-platform development (such as
CommonView and XVT++), none met all of the following criteria:


\hy-8{12}{1.}  low price
\hy-8{13}{2.}  source availability
\hy-8{14}{3.}  simplicity of programming
\hy-8{15}{4.}  support for GCC (GNU C++)
\hy-8{16}{5.}  support for interprocess communication


As public domain software and a project open to everyone, wxWindows has
benefited from comments, ideas, bug fixes, enhancements and the sheer
enthusiasm of users, especially via the InterNet. This gives wxWindows a
certain advantage over its commercial brothers, and a robustness against
the transience of one individual or company. This openness and
availability of source code is especially important when the future of
thousands of lines of application code may depend upon the longevity of
the underlying class library. wxWindows is likely to evolve to allow
more sophisticated GUI use on an increasing number of platforms.

In writing wxWindows, completeness has inevitably been traded for
portability and simplicity of programming. For projects which do not
need uncompromisingly polished interfaces, this tradeoff seems well
worthwhile given the productivity benefits.

wxWindows currently maps to four native APIs: XView (Open Look), Motif,
Windows 3.1 and Windows NT. Under UNIX, wxWindows has been tested most
thoroughly on Sun workstations, but users have confirmed that it
compiles on other machines (including some running UNIX System V). This
covers a very large proportion of machines in use today.

In addition to GUI needs, wxWindows also supports a subset of DDE
(Dynamic Data Exchange) on both the PC and UNIX. A simple
object-oriented model of clients, servers and connections is used,
making it easy to write programs which communicate synchronously. Under
Windows, other non-wxWindows programs may still communicate with
wxWindows programs and vice versa; under UNIX, non-wxWindows programs
just have to conform to a simple protocol when communicating via sockets
with wxWindows programs.

On the PC, the tested compilers for wxWindows are Microsoft C/C++
Version 7 and (to a lesser extent) Borland C++ 3.1 and Turbo C++ for
Windows. Makefiles for MS C++ (Windows 3.1 and NT), and project files
for Turbo C++ for Windows, are provided.

Under UNIX, Sun C++, GNU C++ (GCC) and AT&T C++ are known to work with
wxWindows.  See also \hy-13{17}{Requirements}.

The importance of using a platform-independent class library cannot be
overstated, since GUI application development is very time-consuming,
and sustained popularity of particular GUIs cannot be guaranteed.
Code can very quickly become obsolete if it addresses the wrong
platform or audience.  wxWindows helps to insulate the programmer from
these winds of change. Although wxWindows may not be suitable for
every application, it provides access to most of the functionality a
GUI program normally requires, plus some extras such as form
construction, interprocess communication and PostScript output, and
can of course be extended as needs dictate.  As a bonus, it provides
an arguably cleaner interface to XView, Motif and Windows 3.1 than the native
APIs. Programmers may find it worthwhile to use wxWindows even if they
are developing on only one platform.

Here is a summary of some of the advantages of wxWindows:


\hy-8{18}{o}  Low cost (free, in fact!)
\hy-8{19}{o}  You get the source.
\hy-8{20}{o}  Several example programs.
\hy-8{21}{o}  Over 200 pages of printable and on-line documentation.
\hy-8{22}{o}  Simple-to-use, object-oriented API.
\hy-8{23}{o}  No more messing with arcane X window calls under XView or Motif.
\hy-8{24}{o}  Graphics calls include splines, polylines, rounded rectangles, etc.
\hy-8{25}{o}  XView-style panel item layout.
\hy-8{26}{o}  Status line facility.
\hy-8{27}{o}  Easy, object-oriented interprocess comms (DDE subset) under UNIX and
Windows 3.1.
\hy-8{28}{o}  Encapsulated PostScript generation under UNIX, normal Windows 3.1 printing on the
PC.
\hy-8{29}{o}  Virtually automatic MDI support under Windows.
\hy-8{30}{o}  Can be used to create DLLs under Windows, dynamic libraries on the Sun.
\hy-8{31}{o}  Support for Windows 3.1 printer and file common dialogs, with
equivalents for UNIX.
\hy-8{32}{o}  Under Windows 3.1, support for creating metafiles and copying
them to the clipboard.
\hy-8{33}{o}  Programmatic form facility for building form-like screens fast,
with constraints on values.
\hy-8{34}{o}  Hypertext help facility, with an API for invocation from applications.
\hy-8{35}{o}  wxBuilder for building simple interfaces interactively, and generating
C++ code.


And here are the important downsides, so you can assess wxWindows's
applicability to your needs:


\hy-8{36}{o}  No commercial support (but UseNet support can be better!)
\hy-8{37}{o}  XView-style separation of frames, panels, canvases and text.
\hy-8{38}{o}  No constraint-based panel item layout -- panel layout is
not especially pretty.
\hy-8{39}{o}  No colourmap support.


Figure 1.1 shows a demo application (described in the tutorial chapter)
running under X.

Figure 1.2 shows the demo application running under Microsoft Windows 3.1.


11cm;0cmhellox.ps
Figure 1.1: Demo program running under X



11cm;0cmhellow.ps
Figure 1.2: Demo program running under Windows 3.1



\hy-10{41}{wxWindows requirements}

To make use of wxWindows, you currently need one or both of the
following setups.

(a) PC:


\hy-8{42}{1.}  A 386SX or higher PC running Windows 3.1 or Windows NT.
\hy-8{43}{2.}  Microsoft C/C++ version 7 or above, or Borland C++
version 3.1 (other compilers may work).
\hy-8{44}{3.}  At least 5 MB of disk space.


(b) UNIX:


\hy-8{45}{1.}  GNU C++ version 2.1 or later, or compatible compiler (such as
Sun C++ or AT&T C++)
\hy-8{46}{2.}  A Sun or other workstation supporting GNU C++ and either XView 3.1
or Motif 1.1
\hy-8{47}{3.}  At least 5 MB of disk space.



\hy-10{49}{Availability and location of wxWindows}

wxWindows is currently available from the Artificial Intelligence
Applications Institute by anonymous FTP. FTP to:

\hy-14{50}{skye.aiai.ed.ac.uk,
}

log on as `anonymous', and give your user ID as password. Change
directory into pub/wxwin, change transmission method to binary, and get
wxwin150.tar.Z (UNIX) and/or wxwin150.zip (PC). Both archives contain
the source code for both platforms. The executable demos are available
as demo_ol.tar.Z (the Sun 4 Open Look version), demo_motif.tar.Z (the
Sun 4 Motif version) and demo.zip (the Windows version).

wxWindows 1.40 is in the \hy-14{51}{programr} directory the CICA Windows 3.1
archive at Indiana University (ftp.cica.indiana.edu). Version 1.20 is
available from the British HENSA public domain software archive at
pdsoft.lancs.ac.uk in the directory \hy-14{52}{x/a/a103}.

It is also available by post from:

Dr Julian Smart,

Artificial Intelligence Applications Institute,

University of Edinburgh,

80 South Bridge,

Edinburgh,

Scotland,

EH1 1HN.

Email J.Smart@ed.ac.uk, tel. 031-650-2746.

It is distributed in tar and/or zip format on a high-density 3.5" MS-DOS
disk, with on-line PostScript, LaTeX and DVI format documentation. We
regret we cannot supply printed documentation. Please supply your own disk
and return postage, or enclose something to cover distribution
costs.


\hy-10{54}{Acknowledgments}

Thanks are due to the AIAI for being willing to release wxWindows into
the public domain, and to my wife Harriet Smart for her patience while I
worked on wxWindows at weekends.

The UseNet has been an essential prop when coming up against tricky
XView, Motif and Windows 3.1 problems. Thanks to those who answered my
queries or submitted bug fixes and enhancements; wxWindows is very
much a team effort (although the bugs are mine!). In particular I
would like to mention: Jamshid Afshar, Patrick Albert, C. Buckley,
Robin Corbet, Harco de Hilster, Josep Fortiana, Torsten Liermann, Tatu
Mannisto, Ian Perrigo, Giordano Pezzoli, Petr Smilauer, Neil Smith,
Kari Systa, Jyrki Tuomi.

`Graphplace', the basis for the wxGraphLayout library, is copyright Dr. Jos
T.J. van Eijndhoven of Eindhoven University of Technology. The code has
been used in wxGraphLayout with his permission.

I also acknowledge the author of XFIG, the excellent UNIX drawing tool,
from the source of which I have pinched some spline drawing code.
His copyright is included below.

\hy-7{55}{XFig2.1 is copyright (c) 1985 by Supoj Sutanthavibul. Permission to
use, copy, modify, distribute, and sell this software and its
documentation for any purpose is hereby granted without fee, provided
that the above copyright notice appear in all copies and that both that
copyright notice and this permission notice appear in supporting
documentation, and that the name of M.I.T. not be used in advertising or
publicity pertaining to distribution of the software without specific,
written prior permission.  M.I.T. makes no representations about the
suitability of this software for any purpose.  It is provided ``as is''
without express or implied warranty.}

wxCLIPS (now distributed separately) builds on NASA's CLIPS expert
system shell, a paradigm of portability and a wonderful piece of
(nearly) free software.


\hy-10{59}{wxCLIPS}

wxCLIPS is distributed separately from wxWindows. It is available
from the /pub/wxclips directory of the AIAI ftp site; CLIPS2C,
a partial CLIPS to C++ converter, will be made available at the
same location.


\hy-10{61}{WinSock for wxWindows}

Giordano Pezzoli has implemented a WinSock version of the
wxWindows DDE implementation. This code enables client-server
applications to be written linking UNIX and PC platforms.

It is available in the /pub/wxwin/contrib directory of the AIAI ftp
site. as wxsocket.tar.Z or wxsocket.zip. Note that this is not
necessarily the most up-to-date version.


\hy-10{63}{GWX: DevGuide to wxWindows}

This is a Sun DevGuide to wxWindows generator. It is available in the
/pub/wxwin/contrib directory of the AIAI ftp site, as gwx10.zip.
Note that this is not necessarily the most up-to-date
version.


\hy-10{65}{wxXPM}

This package adds the ability for wxWindows programs to read in
XPM colour bitmaps under both X and Windows. There's a neat
little animation, and a large selection of colour pixmaps.

It is available in the /pub/wxwin/contrib directory of the AIAI ftp
site, as wxxpm01.zip. Note that this is not necessarily the most up-to-date
version.


\hy-10{67}{CURSES port}

Harco de Hilster is working on a CURSES port of wxWindows. A beta is
available in the /pub/wxwin/contrib directory of the AIAI ftp site, as
wxcurs.tar.gz. Note that this is not necessarily the most up-to-date
version.


\hy-10{69}{wxWindows mailing list}

There is an Internet mailing list for wxWindows discussion. Please
send email to:

\hy-14{70}{wxwin-users-request@aiai.ed.ac.uk or J.Smart@ed.ac.uk
}

to be added to either the discussion or the announcements list.


\hy-10{72}{World Wide Web}

You can view the documentation for wxWindows, and information on other
C++ libraries, on the World Wide Web using a viewer such as Mosaic. See:

\hy-14{73}{  http://info.desy.de/user/projects/C++.html
}

under the heading Packages.

If you wish to set up a local HTML version of the wxWindows
documentation, to be viewed with Mosaic in preference to wxHelp, you can
compile Tex2RTF in order to produce the HTML files from the LaTeX sources.
The target 'html' exists in the makefiles for most
packages in the wxWindows toolset, although they will need to be edited
to copy the resulting HTML files to a sensible place.


\hy-10{75}{Ongoing projects}

This is a list of wxWindows projects being undertaken
by Julian Smart and others.

\hy-12{76}{
\hy-14{77}{
-------------------------------------------------
List of on-going and potential wxWindows projects
-------------------------------------------------

The following is a list of current, proposed, and desired wxWindows
projects. Any contributions and suggestions are warmly welcomed!
Please contact me if I've left your contribution out of this list
or the information is inaccurate.

Julian Smart 24/2/94
J.Smart@ed.ac.uk


------------------------------------------------------------------

Name:                   wxBuilder
Participants:           Julian Smart <J.Smart@ed.ac.uk>
Main contact:           Julian Smart
Status:                 In progress
First release expected: Early to mid March 1994
Description:
  An interactive GUI builder generating wxWindows C++ code for
supported wxWindows platforms. It also generates makefiles
(no Imake!) and appropriate .RC and .DEF files. Windows are
manipulated on an editor canvas mirroring the real windows.
  Toolbars are used for speed of use, and a report window records
errors and warnings (such as bitmaps and icons not found.)
  A tree viewer shows the structure of the GUI.
  wxBuilder will run initially under Windows only, later under X.

------------------------------------------------------------------

Name:                   RC to wxWindows library
Participants:           Petr Smilauer <petrsm@cz.cas.entu>
                        Donavan Stanley <DSTANLEY@edu.muskingum>
                        Julian Smart <J.Smart@ed.ac.uk>
Main contact:           Julian Smart
Status:                 In progress
First release expected: April 1994 ?
Description:
  This is a C++ library to parse Windows resource files, returning
information to the calling application both in Windows format and an
approximation to wxWindows conventions. It will initially be used
in wxBuilder to help convert Windows programs (or GUIs built using
external resource editors) into wxWindows code.

------------------------------------------------------------------

Name:                   General enhancements
Participants:           Patrick Albert <als@barjov.frmug.fr.net>
Main contact:           Patrick Albert
Status:                 Continuing
First release expected:
Description:
  Patrick is enhancing many aspects of wxWindows, and current
contributions include panel item fonts, panel-in-panel support,
double-click support, middle mouse button support, WIN32 support,
drawing optimization, bitmap button support, enhanced dialog box,
general bug fixes, amongst others.

------------------------------------------------------------------

Name:                   gwx
Participants:           Kari Syst <ks@fi.tut.cs>
Main contact:           Kari Syst
Status:                 Beta released
Available:              /pub/wxwin/contrib/gwx10.tgz
Description:
  gwx converts a subset of DevGuide .G output to wxWindows code.
The above file is probably not the latest version, but does
include a Sun 4 executable (the sources are a little tricky to
compile and require a compiler with templates). Perhaps
someone might like to write a .G to wxBuilder library,
similar to the RC to wxWindows project.

------------------------------------------------------------------

Name:                   WinSock support for wxWindows
Participants:           Giordano Pezzoli <gio@it.crcc>
Main contact:           Giordano Pezzoli
Status:                 Released
Available:              /pub/wxwin/contrib/wxsocket.zip/.tgz
Description:
  This is a replacement for the standard wxWindows IPC
code, to WinSock.

  "The DDE module has been entirely rewritten and, now, is in C, so I
can develop Unix server programs without the needs for C++ supports.
The DDE protocol has changed since there was some fundamental flaw in
the implementation: like the assumption that a single read is able to
grab the full message (tcp ensure you only reliability and sequencing
but it do not preserve record boundaries!). Now, each message has a
header that says how large is the message, furthermore the buffer
messages are dynamically allocated so that there isn't any restriction
on messages length.

Under Windows you can choose between the local transport (Windows DDE)
or non local transport (Winsock DDE) in the same applications
(by the way, I build a simple program that route Windows DDE
request, and vice versa, to Unix servers on networked hosts)."

------------------------------------------------------------------

Name:                   CURSES text-only version of wxWindows
Participants:           Harco de Hilster <harcoh@cs.kun.nl>
Main contact:           Harco de Hilster
Status:                 Alpha released
Available:              ftp.cs.kun.nl,
                        /pub/school/wxwin/wxcurs.tar.gz,
                        demo_<machine>/tar.gz
Description:
  This is a remarkably functional CURSES implementation of wxWindows.

  "I think the state is usable if you know what you're doing and don't
expect your wxwin programs to run unaltered.
The major problem is that I'm out of sync with the latest wxwin
version, then there are minor problems like unimplemented features,
curses problems and plain bugs.

  I'm using it myself for an application and it has overlapping windows,
menus, listboxes, choices, buttons etc. I never had (or took) the time
to write documentation and a decent 'just type make' makefile.

It is ported to:
sun with '/usr/5lib' curses
ultrix with ncurses
sgi with standard curses
(not recently but possible) dos/djgpp with pdcurses"

------------------------------------------------------------------

Name:                   UNIX Metafile support
Participants:           Julian Smart <J.Smart@ed.ac.uk>
Main contact:           Julian Smart
Status:                 Static
First release expected: 
Description:
 Allows reading in and playing Windows metafiles under
both UNIX and Windows. So far I can read in all the records,
but some records will not map easily to wxWindows. Have used
this code in a mini-metafile implementation for a specific
project, which works quite nicely.

------------------------------------------------------------------

Name:                   wxCLIPS
Participants:           Julian Smart <J.Smart@ed.ac.uk>
Main contact:           Julian Smart
Status:                 Continuing
Available:              Binaries/source in /pub/wxwin/wxclips,
                        source in wxWindows distribution.
Description:
  
  Partial mapping between CLIPS functions and wxWindows GUI
functionality. CLIPS is NASA's expert system shell available at low
cost (free in USA), with functional language, rules, and objects.
Makes a very good embedded language.  wxCLIPS is both an X/Windows
interface to CLIPS, and an interpreted GUI development environment
which can be embedded in other wxWindows applications.
With the help of Rob Wylie <rob@ca.nrc.iit.ai> it has been made
compatible with CLIPS Version 6 (these modifications not yet
released.)

DDE support has recently been added; further functionality is expected
to be added in fits and starts.

########################################################################
########################################################################

People who have expressed interest in doing some work on wxWindows:

Jeff Hunter <jeff@man.mb.wiau>: image and colourmap enhancements
Ken Wessen <ken@ratree.psu.ac.th>: Mac port
Daniel Evans <dee@com.aisg>: RC to wxWindows
Petr Smilauer <petrsm@cz.cas.entu>: PostScript enhancements, .ICO reading
Dick JunJei Lin <b811014@tw.edu.ntu.math>: OS2 port
Hermann Dunkel <dunkel@de.uni-kiel.cul-ipn>: Pixmap reading/display code

Some suggested projects:

-- Image library (GIF, BMP, XPM, etc. reading/writing/display on X and Windows)
-- Better PostScript and Windows printer output
-- Proper combobox widget (a free X combobox widget exists for starters)
-- Decent, editable text subwindow for Windows (MicroEmacs for Windows as a
   base?)
-- font and colour selector dialogs
-- drag and drop support
-- wxToolBar buttons that depress properly
-- Partical OLE wrapper (we'll really need something SOON to combat this
   threat !!) Even thoughts and designs would be good. Any OLE experts
   out there?
-- Ports to other platforms (non-trivial!)
-- Constraint system for laying out panel items
-- Thinking about implementing Microsoft-like GUI tricks, such as
   'tabs' in dialog boxes (click on a tab for a different set of controls.)
-- Clipboard support under X and Motif.
-- Networking toolkit, based on WinSock support, with documentation,
   and examples.
}
}


\hy-10{81}{Windows}

An application presents the user primarily with a series of windows. A
window can be made up of a \hy-7{82}{frame} with one or more subwindows. This
is like the XView model, rather than Motif or Windows 3.1 where child
windows may be nested to any depth.  The frame method was chosen since
XView required it, and because it is a useful simplifying assumption,
imposing few restrictions in practise. Note that the splitting of views
beloved of the Open Look standard is not allowed in wxWindows.

A frame window may be parentless or a child of another frame, and may
be iconized. It may have a \hy-7{83}{menu bar}, a row of pull-down menus
along the top of the frame.  Subwindows within a frame come in three
varieties: the \hy-7{84}{panel}, \hy-7{85}{canvas} and \hy-7{86}{text subwindow}.  A
panel is used for buttons, lists and other such user input items, while
a canvas is used for drawing graphics such as lines and shapes.  Panel
items pass high-level notification of user interaction to the program,
whereas any interaction with objects on a canvas must be programmed at a
lower level.

In Windows 3.1, canvases need to be painted using a handle to a `device
context'. The purpose of this is to enable the same code to draw into a
number of different devices, such as printers, windows, bitmaps and
metafiles. wxWindows also has the notion of a device context, but most
drawing commands may also be directly issued to a canvas for
convenience. An application which implements a function to draw into the
base device context, \hy-8{87}{wxDC} will be able to pass any device context
object to this drawing function, including \hy-8{88}{wxPostScriptDC}, \hy-8{89}{wxCanvasDC},
\hy-8{90}{wxMetaFileDC}, and \hy-8{91}{wxMemoryDC}.

wxWindows defines several objects required for drawing on canvases:
colours, fonts, pens and brushes. Neither XView nor Motif provides pens
and brushes, which in Windows 3.1 allow the selection of different
predefined `drawing tools' with certain characteristics (line thickness,
colour, fill style etc.). Normally in X there is a limited range of
fonts (scaleable fonts are a recent addition), while in Windows 3.1 an
infinite selection of sizes is available thanks to the scaleable
TrueType font system. Under XView and Motif, wxWindows chooses the closest
matching font.

Windows 3.1 or Motif programmers may miss the ability to place panel items
in canvases (to use XView terminology), or to draw graphics in panels. A
future version of wxWindows may support drawing on panels, particularly
in the Motif and Windows versions, lifting these restrictions. Support
for displaying panel items and drawing graphics will probably be moved
up to the base \hy-8{92}{wxWindow} class, maintaining compatibility with
existing wxWindows programs but allowing new programs more flexibility.

\hy-8{93}{MDI versus SDI}


\hy-10{103}{Dialog boxes}

A \hy-7{104}{dialog box} is like a panel, with an implicit frame surrounding
it. A dialog box may be \hy-7{105}{modal} (no other window in this application
is active and the calling program flow is suspended) or \hy-7{106}{modeless}
(any window may be interacted with and control returns immediately to
the program). With dialog boxes, creation of separate frames and panels
is not necessary, and under Windows 3.1, additional functionality is added
`for free', such as tabbing between items. Any panel item may be
attached to a dialog box since wxDialogBox is derived from the wxPanel.

Note that under Windows 3.1, modal dialogs have to be emulated using
modeless dialogs and a message loop. This is because Windows 3.1 expects
the contents of a modal dialog to be loaded from a resource file or
created on receiving a dialog initialization message. This is too
restrictive for wxWindows, where any window may be created and possibly
displayed before its contents are created.

Standard dialogs are provided for printer settings, file selection,
short messages, single-line text string entry and scrolling
single-selection lists.


\hy-10{108}{Menus}

Menus are used in menu bars and popup menus. A menu bar is a sequence of
pull-down command menus near the top of the window, usually with a \hy-8{109}{
File} menu as the first menu. In Windows 3.1 and Motif, the menu bar is
a standard user interface component. Under XView, wxWindows must
simulate a menu bar with a series of menu buttons. Under wxWindows for
Motif and Windows 3.1, but not XView, placing and ampersand before a
letter in a menu name causes it to be underscored and interpreted as a
keyboard shortcut. Under XView such underscores are ignored. The Motif
version of wxWindows automatically right-justifies the help menu, if
there is one.

Menu items are identified by integer identifiers, and for menu bars,
when a menu item is selected, the parent frame is notified using the
\hy-8{110}{OnMenuCommand} member. For popup menus, a callback function is
executed.


\hy-10{112}{Events}

In XView and Motif, events (such as resizing, painting, mouse clicks, button
presses) are handled by a rather arbitrary collection of optional
XView and Xlib callbacks. In Windows 3.1, events are \hy-7{113}{messages}
which are handled by a window procedure, or ignored.

In wxWindows, an application's GUI objects mostly receive events by
wxWindows calling user-overridable handlers, such as \hy-8{114}{OnEvent}, \hy-8{115}{
OnChar} and \hy-8{116}{OnSize}.  Frames can receive \hy-8{117}{OnClose} events from
the window manager (X) or system control menu (Windows 3.1). These events
are handled by the application by deriving new frame classes and
overriding the event-handling member functions.

Panel item notification has to be handled rather differently. In
Windows 3.1, all panel item events (such as a button press) are sent to
the parent window (requiring large case statements to differentiate
the events), and all window events are sent to the relevant window. In
XView and Motif, different types of callback function have to be defined,
depending on the event.

In wxWindows, panel items have optional callback functions, but there is
only one callback type: the function takes the object and a command event
structure.  The class derivation approach cannot be extended to panel
items since it does not make sense to derive a new class for every
individual panel item created.

\hy-8{118}{The wxWindows event system}


\hy-10{126}{Keyboard input}

From Version 1.5, wxWindows defines platform-independent constants for
most common keys, including function and cursor keys. The virtual
keycodes for standard ASCII characters are the ASCII codes themselves,
unlike under Windows. Key presses are sent to the \hy-8{127}{OnChar} member
of a window with a \hy-8{128}{wxKeyEvent} argument, which can be used to
determine the state of the shift and control keys as well as finding the
virtual key code of the depressed key.

The \hy-8{129}{wxCanvas} class has a default \hy-8{130}{OnChar} handler which scrolls
the canvas using the cursor keys.


\hy-10{132}{Repainting of windows}

All windows except for the canvas are repainted by the system.  The
canvas requires a paint message handler to be defined (and therefore
canvas derivation is obligatory). Under XView and Motif, wxWindows
allows a canvas to be retained if desired, which means that fewer
paint messages are received and scrolling is fast. The Motif implementation
has a slight overhead in that drawing must be done both to the canvas
and to the backing pixmap, but this is usually made up for by the speed
of repainting.

The repaint procedure will obviously be written in such a way that the
minimum amount of work needs to be done (for example, positions of
objects on a canvas are only recalculated when the positions change).

See \hy-13{133}{Scrolling} for more information on repainting and scrolling.


\hy-10{135}{Scrolling}

Scrolling can be a tricky subject for a novice GUI programmer to tackle.
The Windows 3.1 API ensures that the suffering is as acute as possible by
requiring the application to program the scrollbar behaviour, to check
the scrollbar positions on repainting, and to reposition the scroll bars
on window resizing.  XView has the decency to provide a canvas event
with coordinates that reflect what the scrollbars are doing. In
wxWindows, the XView approach is taken, so that all the programmer has
to do is to create scrollbars with a given scroll length and increment,
and the repaint procedure automatically reflects scrollbar positions. 
Obviously this simple approach can be inefficient if the canvas doesn't
know what is actually in view, so the application can get the current
view in order to limit the amount of repainting required.

It is possible to tell a wxWindows canvas to be \hy-7{136}{retained} (though
this only has an effect in XView and Motif). In this case no repaint events will happen
when scrolling since the system remembers what was drawn and simply moves
a bitmap around.

Under Windows 3.1, wxWindows scrolls the bits of the canvas around
when the user generates a scroll event, so the canvas does not need to
be cleared and only the damaged areas need be repainted---so all the
application need do is redraw the whole image, and scrolling will appear to be
relatively smooth. This is the case in the \hy-14{137}{hello.exe} demo.

However, there are times when we can't allow the system to scroll the
bits of the image, for example when a scroll increment will result in
an unpredictable actual movement of the image. This is true for wxHelp, since
scrolling is in terms of lines, and lines vary in height. If we left
it up to wxWindows to scroll without clearing the screen, the text
would then overlay some of the previous screen since the old and new
images will probably not exactly match.

In the wxHelp application (see \hy-13{138}{wxHelp}) the horizontal
direction is scrolled in terms of pixels, not character widths, and so
wxWindows can be left to scroll the image smoothly, without having to
clear before repainting. This kind of control is avilable by using \hy-8{139}{
wxCanvas::EnableScrolling}.

Scrolling panels have yet to be implemented in wxWindows.


\hy-10{141}{Printing}

Printing in Windows 3.1 is relatively easy, since all drawing is done to
a `device context' which could equally well be associated with a
printer as with a window. Windows 3.1 handles the plethora of printer
types that abound in the PC environment. In X under UNIX, the standard
is PostScript; X, XView and Motif provide no help at all. The solution
adopted in wxWindow is to use a device context for canvases and
printers, with Windows 3.1 printing supported on the PC and an
Encapsulated PostScript driver provided under X. Thus graphic code may
be extremely generic - the same piece of code can draw to Windows 3.1
screens of all types, to X windows, and to hundreds of different
printers.


\hy-10{143}{Programmatic versus interactive GUI building}

Interactive tools for rapidly building GUIs are all the rage, and
wxWindows does not at this point support this. Loading Windows 3.1
dialog boxes from resource files may be possible in future in wxWindows,
so that dialogs may be constructed interactively. However, this will not
carry through to other platforms, so a more general solution is
required. One possibility is to translate Windows 3.1 resource scripts
or DevGuide descriptions into wxWindows code, or into a form that
wxWindows could load.  Using YACC and LEX such a project could be quite
straightforward, although there will not always be a mapping between the
dialog builder and wxWindows constructs. (A wxWindows user is currently
working on this project.)

Another consideration is that it is not always possible to build GUI
components interactively: the `what you see is \hy-7{144}{all} you get'
syndrome. When complex repositioning of items depending on window size
is required, then GUI builders such as the Microsoft dialog editor
are useless.

However, using a toolkit with geometry management may be no panacea;
for example, the Motif constraint algorithm is difficult to understand
and much experimentation is necessary. The approach taken by wxWindows
is in keeping with the main goal of simplicity: wxWindows has the
ability to create panel items from left to right, top to bottom with
appropriate horizontal and vertical spacing; or the programmer may
position the panel items explicitly. The first method gives resolution
and font independence, and is less fiddly, and the second method may
be used for tidying up a display for a specific platform.

Is likely that in the near future, a constraint algorithm will be
added to wxWindows to allow specification of relative position, alignment
etc. Hopefully, it will be easier to use than Motif constraints, if
not as flexible.

A basic GUI builder is currently being written for wxWindows, and is
expected to be released around March 1994. It will generate C++ and
CLIPS code, and help file skeletons in LaTeX form to be translated
into Windows Help, wxHelp and HTML (World Wide Web) format.


\hy-10{146}{Dimensions}

The graphics origin is always the top left hand corner of a window.
Dimensions are a problem in a multi-platform application, since display
and character widths will change from machine to machine, even more so
than for different PC display boards. At the moment wxWindows uses
pixels; Windows 3.1 tackles the problem by using `dialog units' based on
the size of the standard system font.  To avoid this problem when
creating panel items, wxWindows provides automatic left to right, top to
bottom item layout (similar to XView), in addition to absolute
positioning, in which case, portability is up to the discretion of the
programmer.

A canvas has a \hy-7{147}{mapping mode} associated with it, which determines
the meaning of dimensions in subsequent graphics operations. Drawing may
be done using various units including mm, 1/10 mm, pixels and points. Future
versions of wxWindows may support a change of graphics origin.


\hy-10{149}{Colour}

Under XView, Motif and Windows 3.1, the default colourmap is used for
canvases. Future versions of wxWindows should improve upon colourmap
handling.

The presence of a monochrome screen can be detected so the application
can change its use of colour accordingly. Currently, wxWindows tries to
choose appropriate pen and brush colours for a monochrome display. To
override this behaviour, set the device context \hy-8{150}{Colour} member to
TRUE and choose custom colours for drawing graphics.


\hy-10{152}{On-line help}

Most modern GUI applications have on-line hypertext help. In Windows
3.1, help is normally supplied in binary files which are read by an external
program, which is itself accessed from within the application using
Microsoft-supplied function calls. XView has provisions for simple
context sensitive help, but no equivalent of the Windows 3.1 browseable
help.

From version 1.30, wxWindows comes with wxHelp, a hypertext help
system which may be invoked from wxWindows applications. However, a
wxWindows program may specify that under Windows 3.1, WinHelp should
be used instead of wxHelp. wxHelp may be seen as a `last resort' if the
GUI system does not have a native help facility.

Please see \hy-13{153}{wxHelp} and the separate wxHelp manual for
further details.

wxWindows programmers may wish to follow the example of the wxWindows
documentation, and prepare their manuals in a LaTeX form. The supplied
\hy-13{154}{Tex2RTF} utility may then be used to generate
online help in a variety of paper and on-line hypertext formats, including
wxHelp and Windows Help.


\hy-10{156}{User preferences}

In both X and Windows, there are mechanisms for handling user
preferences, or resources. Under X, there is a global .Xdefaults
file plus inidividual application defaults files. Under Windows,
either win.ini or application specific .ini files are used.

wxWindows unifies these with \hy-8{157}{wxGetResource} and
\hy-8{158}{wxWriteResource} functions: section, entry, value and
file arguments may be specified.

In X, a section is the first word in a resource specification; in
Windows, this is enclosed in square brackets on a line of its own.  In
X, an entry is taken to mean the rest of a resource specification, and
in Windows this is a name followed by an equals character.
The value is an arbitrary string in both cases, although wxWindows
overloads the resource functions for commonly used types.

If the resource filename is omitted, the main resource file is assumed
(.Xdefaults or win.ini). Under X, if an application class
(wxApp::wx_class) has been defined, it is appended to the string
/usr/lib/X11/app-defaults/ to try to find an applications default
file when merging all resource databases.


\hy-10{160}{Interprocess Communication}

\hy-8{161}{What wxWindows has}

\hy-8{163}{Principles of DDE}

\hy-8{186}{Data transfer}

\hy-8{196}{Examples}

\hy-8{200}{Remote Procedure Call}


\hy-10{207}{Code structure}

Since version 1.50, the files have been split as much as possible into
command and platform-specific code. The \hy-14{208}{include} and \hy-14{209}{src} directories
each have a \hy-14{210}{base} directory for the common code, plus a directory for
each platform, currently \hy-14{211}{msw} and \hy-14{212}{x}. Because much X functionality
is shared, the Motif and XView versions are contained in the same files, separated
by conditional compilation statements. This structure should make it easy
both to implement support for new platforms, and to edit the existing code.

In order to provide separate out the base functionality from the
platform-specific functionality, each wxWindows class is composed of two
classes: a base for the common code with prefix \hy-8{213}{wxb}, and a derived
class for the platform with prefix \hy-8{214}{wx}. Base files have a \hy-8{215}{
wb_} prefix whilst platform-specific files (or files which \hy-7{216}{never}
have corresponding platform-specific code) have a \hy-8{217}{wx_} prefix.

For example, the \hy-8{218}{wxCanvas} class is declared for each platform, and
derives from \hy-8{219}{wxbCanvas}. The relevant files for this class may
therefore be found as follows:

\hy-14{220}{include\base\wb_canvs.h
include\msw\wx_canvs.h
include\x\wx_canvs.h
src\base\wb_canvs.cc
src\msw\wx_canvs.cc
src\x\wx_canvs.cc
}

Each \hy-8{221}{wx_} header file includes the corresponding \hy-8{222}{wb_} header file.


\hy-10{224}{Include files}

Under both operating systems, include the file \hy-14{225}{"wx.h"}, or to save
on compilation time, include only those header files relevant to the
source file. If you are using precompiled headers, you should include
\hy-14{226}{"wx.h"} only. The main header files (omitting base class files) are
as follows.


\hy-8{227}{o}  common.h - important definitions and includes (included by wx.h)
\hy-8{228}{o}  wx.h - includes all wxWindows headers
\hy-8{229}{o}  wx_setup.h - configuration file for wxWindows optional features
\hy-8{230}{o}  wx_buttn.h - button panel item
\hy-8{231}{o}  wx_canvs.h - drawing on canvases
\hy-8{232}{o}  wx_check.h - check box panel item
\hy-8{233}{o}  wx_dc.h - drawing on canvases and printers
\hy-8{234}{o}  wx_dccan.h - canvas device context
\hy-8{235}{o}  wx_dcmem.h - memory device context
\hy-8{236}{o}  wx_dcps.h - PostScript device context
\hy-8{237}{o}  wx_dialg.h - user-defined and standard dialogs
\hy-8{238}{o}  wx_form.h - forms allow succinct expression of panels with
constrained items
\hy-8{239}{o}  wx_frame.h - frame window handling
\hy-8{240}{o}  wx_gdi.h - graphics objects such as colours, pens, brushes and icons
\hy-8{241}{o}  wx_help.h - API for invoking wxHelp
\hy-8{242}{o}  wx_hash.h - hash table implementation
\hy-8{243}{o}  wx_ipc.h - interprocess communication (using a subset of the DDE standard)
\hy-8{244}{o}  wx_ipcob.h - client or server object class
\hy-8{245}{o}  wx_item.h - panel item base class
\hy-8{246}{o}  wx_lbox.h - list box panel item
\hy-8{247}{o}  wx_list.h - linked list implementation, heavily used by wxWindows
\hy-8{248}{o}  wx_main.h - application initialization
\hy-8{249}{o}  wx_menu.h - menus
\hy-8{250}{o}  wx_messg.h - message panel item
\hy-8{251}{o}  wx_mf.h - metafile class
\hy-8{252}{o}  wx_mgstr.h - language-specific strings (experimental)
\hy-8{253}{o}  wx_mnuit.h - menu item (for internal use by menus only)
\hy-8{254}{o}  wx_mtxt.h - multitext panel item
\hy-8{255}{o}  wx_obj.h - base class for wxWindows classes
\hy-8{256}{o}  wx_panel.h - panels
\hy-8{257}{o}  wx_privt.h - some private wxWindows definitions
\hy-8{258}{o}  wx_rbox.h - radio box panel item
\hy-8{259}{o}  wx_stdev.h - standard event class definitions
\hy-8{260}{o}  wx_sysev.h - system event definitions
\hy-8{261}{o}  wx_text.h - text subwindows
\hy-8{262}{o}  wx_timer.h - timer object
\hy-8{263}{o}  wx_txt.h - single-line text panel item
\hy-8{264}{o}  wx_types.h - explicit type system
\hy-8{265}{o}  wx_utils.h - various utilities
\hy-8{266}{o}  wx_win.h - abstract base class for frames, subwindows and items



\hy-10{268}{Libraries}

Under UNIX, use the library libwx_ol.a (XView) or libwx_motif.a
(Motif).  Under DOS, use the library wx.lib for stand-alone Windows
applications, or wxdll.lib for creating DLLs.


\hy-10{270}{Configuration}

The following is an incomplete list of options configurable in
the file include/base/wx_setup.h.


\hy-8{271}{CTL3D} 

It is recommended that CTL3D is used under Windows, since the 3D effects
are good-looking and will be standard.  Howver, the default for
wxWindows is not to use it. If you want to use it and don't already have
CTL3D installed, copy the files in contrib/ctl3d to appropriate places
(ctl3d.lib into your compiler lib directory, ctl3d.h into an include
directory, and ctl3d.dll into windows/system). If you are using a
compiler other than Microsoft's, you will need to obtain the CTL3D
sources (e.g. from ftp.microsoft.com) and compile them. Define CTL3D 
to be 1 in wx_setup.h and link your executables with CTL3D.LIB.
\hy-8{272}{FAFA_LIB} 

Define this to be 1 if you have the Fafa enhanced control library (in
the contrib directory). The Fafa library is mandatory for bitmap
buttons.

An application using the Fafa library must include fafa.rc in the
its RC file. Otherwise, some controls will not show up.
\hy-8{273}{ENHANCED_FONTS} 

Define to be 1 to have pre-defined fonts in wxEnhDialogBox.
\hy-8{274}{PIXEL0_DISABLE} 

Define to disallow allocation of pixel 0 (wxXOR problem.)
\hy-8{275}{USE_GADGETS} 

Use gadgets where possible rather than Widgets for items. Default is
to use Gadgets.



\hy-10{277}{Makefiles}

At the moment there is no attempt to make UNIX makefiles and
PC makefiles compatible, i.e. one makefile is required for
each environment.

Sample UNIX and MS C++ makefiles and Turbo C++ project files are
included for the library, demos and utilities. Borland C++ makefiles are
provided for the library only. See the \hy-14{278}{contrib} directory for
platform-specific information for other compilers such as Symantec and
Visual C++.

The controlling makefile for wxWindows is in the platform-specific
directory, such as \hy-14{279}{src/msw} or \hy-14{280}{src/x}. This makefile will
recursively execute the makefile in \hy-14{281}{src/base}.

\hy-8{282}{DOS makefiles}

\hy-8{288}{UNIX makefiles}


\hy-10{303}{Windows-specific files}

wxWindows application compilation under Windows 3.1 requires at least two
extra files, resource and module definition files.

\hy-8{304}{Resource file}

\hy-8{308}{Module definition file}


\hy-10{312}{Memory models and memory allocation}

Under UNIX, memory allocation isn't a problem. Under Windows, the only
really viable way to go is to use the large model, which uses the global
heap instead of the local heap for memory allocation. Unless more than
one read-write data segment is used (see \hy-13{313}{large data}
below), large model programs may still have multiple instances under MS
C/C++ 7. Microsoft give the following guidelines for producing
multiple-instance large model programs:


\hy-8{314}{o}  Do not use \hy-14{315}{/ND} to name extra data segments unless the segment is READONLY.
\hy-8{316}{o}  Use the .DEF file to mark extra data segments READONLY.
\hy-8{317}{o}  Do not use __far or FAR to mark data items.
\hy-8{318}{o}  Use \hy-14{319}{/PACKDATA} to combine data segments.
\hy-8{320}{o}  Use \hy-14{321}{/Gt65500 /Gx} to force all data into the default data segment.


Even with the single-instance limitation, the productivity benefit is
worth it in the majority of cases. Note that some other multi-platform
class libraries also have this restriction. (If more than one instance
really is required, create several copies of the program with different
names.)

Having chosen the large model, just use C++ `new', `delete' (and if
necessary `malloc' and `free') in the normal way. The only restrictions
now encountered are a maximum of 64 KB for a single program segment and
for a single data item, unless huge model is selected.


\hy-10{323}{Dynamic Link Libraries}

wxWindows may be used to produce DLLs which run under Windows 3.1. Note that
this is not the same thing as having wxWindows as a DLL, which is not
currently possible. For Microsoft C++, use the makefile with the argument DLL=1 to produce
a version of the wxWindows library which may be used in a DLL application.
There is a bug in Microsoft C++ which makes the compiler complain about returned floats,
which goes away when the \hy-14{324}{/Os} option is used, which is why that flag is
set in the makefile.

For making wxWindows as a Sun dynamic library, there are comments in the
UNIX makefile for the appropriate flags for AT&T C++. Sorry, I haven't
investigated the flags needed for other compilers.


\hy-10{326}{Conditional compilation}

One of the purposes of wxWindows is to reduce the need for conditional
compilation in source code, which can be messy and confusing to follow.
However, sometimes it is necessary to incorporate platform-specific
features (such as metafile use under Windows 3.1). The following identifiers
may be used for this purpose, along with any user-supplied ones:


\hy-8{327}{o}  \hy-14{328}{wx_x} - for code which should work under any X toolkit
\hy-8{329}{o}  \hy-14{330}{wx_xview} - for code which should work under XView only
\hy-8{331}{o}  \hy-14{332}{wx_motif} - for code which should work under Motif only
\hy-8{333}{o}  \hy-14{334}{wx_msw} - for code which should work under Microsoft Windows only


For example:

\hy-14{335}{  ...
#ifdef wx_x
  (void)wxMessageBox("Sorry, metafiles not available under X.");
#endif
#ifdef wx_msw
  wxMetaFileDC dc;
  DrawIt(dc);
  wxMetaFile *mf = dc.Close();
  mf->SetClipboard();
  delete mf;
#endif
  ...
}


\hy-10{337}{Building on-line help}

wxWindows has its own help system from version 1.30: wxHelp. It can be
used to view the wxWindows class library reference, and also to provide
on-line help for your wxWindows applications. The API, made accessible
by including \hy-14{338}{wx_help.h}, allows you to load files and display
specific sections, using DDE to communicate between the application and
wxHelp.

wxHelp files can be marked up by hand from ASCII files within wxHelp,
or may be generated from other files, as is the case with the wxWindows
documentation.

From version 1.50, it is possible to use the platform-specific help
system (e.g. WinHelp) instead of wxHelp.

See \hy-14{339}{install.txt}, the wxHelp documentation (in \hy-14{340}{
utils/wxhelp/docs}) and \hy-13{341}{wxHelp} for further details.


\hy-10{343}{C++ issues}

There are cases where a C++ program will compile and run fine under one
environment, and then fail to compile using a different compiler. Some
caveats are given below, from experience with the GNU C++ compiler (GCC)
and MS C/C++ compiler version 7.

\hy-8{344}{Templates}

\hy-8{346}{Definition of constructors}

\hy-8{349}{Pointers to functions}

\hy-8{355}{Precompiled headers}


\hy-10{361}{File handling}

When building an application which may be used under different
environments, one difficulty is coping with documents which may be
moved to different directories on other machines. Saving a file which
has pointers to full pathnames is going to be inherently unportable. One
approach is to store filenames on their own, with no directory
information.  The application searches through a number of locally
defined directories to find the file. To support this, the class \hy-8{362}{
wxPathList} makes adding directories and searching for files easy, and
the global function \hy-8{363}{FileNameFromPath} allows the application to
strip off the filename from the path if the filename must be stored.
This has undesirable ramifications for people who have documents of the
same name in different directories.

As regards the limitations of DOS 8+3 single-case filenames versus
unrestricted UNIX filenames, the best solution is to use DOS filenames
for your application, and also for document filenames \hy-7{364}{if} the user
is likely to be switching platforms regularly. Obviously this latter
choice is up to the application user to decide.  Some programs (such as
YACC and LEX) generate filenames incompatible with DOS; the best
solution here is to have your UNIX makefile rename the generated files
to something more compatible before transferring the source to DOS.
Transferring DOS files to UNIX is no problem, of course, apart from EOL
conversion for which there should be a utility available (such as
dos2unix).

See also the File Functions section of the reference manual for
descriptions of miscellaneous file handling functions.


\hy-10{366}{Large amounts of global data}

Under Windows, it is possible that the default data segment becomes
too large (for example, a large number of small, global data items
have been declared). This may be cured by using more than one data
segment. In Microsoft C++, specify the \hy-14{367}{/Gt} compiler option with
a number representing the data size threshold for putting data items
in a separate segment. For example, \hy-14{368}{/Gt8}.

The tradeoff is that using more than one data segment prevents you from
having more than one instance of the program running at a time
(see \hy-13{369}{Memory Models}). Large model programs with one
data segment may still have multiple instances.

A separate problem sometimes occurs when the linker complains about too
many segments. This can be cured by using the \hy-14{370}{/SEG} linker switch,
for example \hy-14{371}{/SEG:256}.


\hy-10{376}{wxBuilder}

wxBuilder is a start at an interactive GUI builder for wxWindows
applications. It allows the developer to quickly construct a fair amount
of the skeleton of a GUI program, before filling in the details by hand.
Presently wxBuilder runs under Windows, but it will eventually run under
Motif as well.

wxBuilder is so far the largest freely-available program written in
wxWindows, totalling about 15,000 lines, and so may be of interest as a
sample application of reasonable complexity. However, I don't make any
claims about the C++ style -- it was written very quickly as a spare
time project.

Please see the printed and on-line documentation for wxBuilder.


\hy-10{378}{wxToolBar}

wxToolBar implements a simple toolbar class, to help give wxWindows
applications a more graphical and intuitive look and feel. A wxToolBar
is a canvas with bitmaps either arranged automatically in rows and
columns, or spaced explicitly by the application. Individual tools can
be toggle or non-toggle, and toggle tools may have a second bitmap to
denote the on-state. Without a second bitmap, a distinguishable on-state
is supplied by wxToolBar. To supply further feedback for the user, the
application may override a member to intercept mouse movement over the
tools, typically using this to supply an explanatory string on the
status line.

A toolbar can be made to exist in its own frame, or (for example) below
the menu bar of the main application window. Both these types are shown
in the demo toolbar application \hy-14{379}{test.cc}. wxToolBar works under Motif,
XView, Windows and NT.

Please refer to the separate manual for further details.


\hy-10{381}{wxHelp}

wxHelp is a stand-alone program, written using wxWindows and \hy-13{382}{hyText},
for displaying hypertext help. It is necessary since not all target
systems (notably X in the guise of XView and Motif) supply an adequate
standard for on-line help. wxHelp is modelled on the Windows 3.1 help
system, with contents, search and browse buttons, but does not reformat
text to suit the size of window, as WinHelp does, and its input files
are uncompressed ASCII with some embedded font commands and an .xlp
extension. Most wxWindows documentation (user manuals and class
references) is supplied in wxHelp format, and also in Windows Help
format.

Note that an application can be programmed to use Windows Help under
Windows 3.1, and wxHelp under X. An alternative help viewer under X is
Mosaic, a World Wide Web viewer that uses HTML as its native hypertext
format. However, this is not currently integrated with wxWindows
applications.

wxHelp works in two modes---edit and end-user. In edit mode, an ASCII
file may be marked up with different fonts and colours, and divided into
sections. In end-user mode, no editing is possible, and the user browses
principally by clicking on highlighted blocks.

When an application invokes wxHelp, subsequent sections, blocks or
files may be viewed using the same instance of wxHelp since the two
programs are linked using wxWindows interprocess communication
facilities. When the application exits, that application's instance of
wxHelp may be made to exit also.  See the \hy-8{383}{wxHelpInstance} entry in the
reference section for how an application controls wxHelp.


\hy-10{385}{hyText}

This is the hypertext library used by wxHelp to show text with mixed
fonts and colour, and manipulate blocks of text. It is supplied in
library form so it can be used by other applications (it is in fact used
by another application at AIAI).

See the separate manual and class reference for hyText.


\hy-10{387}{wxCLIPS}

C++ is all very well for applications that have to be fast, deliverable
and, above all, written in C++. But what about casual programmers,
prototypers, and those who want something a little more high-level?

Naturally, wxWindows, in collaboration with NASA, can supply the
answer---wxCLIPS. CLIPS is NASA's expert system shell consisting of a
LISP-like functional language, a rule interpreter, an object system, and
the crucial characteristic of portability. It's implemented as a C
library, can be embedded in any C or C++ application with no royalty
payments, and is free within the United States, available at low
cost elsewhere.

As a language, CLIPS has several advantages over C++. It requires no
explicit memory management, since it has garbage collection; it's
interpreted, so no long compilations; and it has a rule interpreter,
useful for knowledge based system projects, or just occasional pattern
matching and searching. So it's useful for prototyping applications,
or for non-C++ programmers. From the C++ developer's point of view,
it makes a great embedded language for user-extensible applications.

wxCLIPS adds a library of GUI CLIPS functions to CLIPS; the intention is
to cover all of wxWindows functionality eventually, though presently,
only the most important functionality is covered. wxCLIPS comes as both
a library and an executable, so it can be used straightaway to develop
GUI programs, and it can also be linked into applications to provide a
built-in language. Within AIAI, wxCLIPS has proven popular amongst
students and professionals for rapid-prototyping and customization.

A program called CLIPS2C has been written to translate a subset of CLIPS
into C++, to combine the advantages of interactive development
with efficient delivery. CLIPS2C knows about the wxCLIPS extensions.

See the wxCLIPS manual and NASA's CLIPS manuals for further details.

wxCLIPS and CLISP2C are now distributed separately, to save
space in the wxWindows distribution. They are now available
from the /pub/wxclips directory of AIAI's ftp site.


\hy-10{389}{PROLOGIO}

Much of a programmer's time can be spent in writing and modifying code
to load and save data files. PROLOGIO is a utility that makes life
easier, if your application's data needs look something like the
following:


\hy-8{390}{o}  The data are complex, possibly involving linked records and
nested lists.
\hy-8{391}{o}  The application is under development, so the size and contents
of each record are liable to change.
\hy-8{392}{o}  Backward compatibility of data files is required.
\hy-8{393}{o}  Ability to read and edit data file is required.
\hy-8{394}{o}  Speed of application development is important, and speed of
data I/O is a lesser priority.


A PROLOGIO data file is an ASCII series of `objects'. In fact, each
object is a subset of the syntax for a term in the Prolog language, and
a PROLOGIO file can be read into Prolog with a single command, but this
is irrelevant for most purposes. Because these objects consist of a list
of attribute-value pairs, parsed by a YACC/LEX grammar, attributes can
be removed from or added to an object without `breaking' the data
format. A typical application will be written to deal with missing
attribute values, supplying defaults instead, and so data I/O can be
very robust, even though the application changes substantially over the
months and years. Very old data files are likely to be useable, even
though many bells and whistles have been added to the application.

Since the file is ASCII, and readable, it is possible to edit the data
file directly if something goes wrong---a very useful fallback position.
Also, one application's data file can be easily read by another's,
encouraging the separation of a complex application into a suite of
smaller tools.

PROLOGIO supplies a number of classes to manipulate these objects and
whole databases of objects. A PROLOGIO database can be built up
in memory and then dumped to a file with a single statement, and
conversely, a data file can be loaded into memory with a single
statement, and then picked apart.

Please refer to the separate PROLOGIO manual. \hy-13{395}{wxBuilder} is
a good example of a program that makes extensive use of PROLOGIO.


\hy-10{397}{Tex2RTF}

Supplied with wxWindows is a utility called Tex2RTF for converting
LaTeX manuals to the following formats:


\hy-8{398}{wxHelp} 
wxWindows help system format (XLP).
\hy-8{399}{Linear RTF} 
Rich Text Format suitable for importing into a word processor.
\hy-8{400}{Windows Help RTF} 
Rich Text Format suitable for compiling into a WinHelp HLP file with the
help compiler.
\hy-8{401}{HTML} 
HTML is the native format for Mosaic, the main hypertext viewer for
the World Wide Web. Since it is freely available it is a good candidate
for being the wxWindows help system under X, as an alternative to wxHelp.


Tex2RTF is used for the wxWindows manuals and can be used independently
by authors wishing to create on-line and printed manuals from the same
LaTeX source.  Please see the separate documentation for Tex2RTF.


\hy-10{403}{wxTreeLayout}

This is a simple class library for drawing trees in a reasonably pretty
fashion. It provides only minimal default drawing capabilities, since
the algorithm is meant to be used for implementing custom tree-based
tools.

Directed graphs may also be drawn using this library, if cycles are
removed before the nodes and arcs are passed to the algorithm.

Tree displays are used in many applications: directory browsers,
hypertext systems, class browsers, and decision trees are a few
possibilities.

See the separate manual and the directory utils/wxtree.


\hy-10{405}{wxGraphLayout}

The wxGraphLayout class is based on a tool called `graphplace' by Dr.
Jos T.J. van Eijndhoven of Eindhoven University of Technology. Given a
(possibly cyclic) directed graph, it does its best to lay out the nodes
in a sensible manner. There are many applications (such as diagramming)
where it is required to display a graph with no human intervention. Even
if manual repositioning is later required, this algorithm can make a good
first attempt.

See the separate manual and the directory utils/wxgraph. 


\hy-10{407}{rcParser}

This libary, written by Petr Smilauer, parses Windows resource files,
bitmaps, icons and cursors. The library is used in wxBuilder, but other
applications may find uses for it. Sorry, there isn't much documentation,
but the header files and wxBuilder sources should supply a few clues.


\hy-10{411}{Bugs}

These are the known bugs:


\hy-8{412}{1.}  Using \hy-8{413}{SetClientSize} before setting the menu bar on a frame
does not cause a menu bar to appear under XView. Use \hy-8{414}{SetClientSize} after changes
to the window which might affect its size.
\hy-8{415}{2.}  Modal dialogs under XView do not treat some panel items correctly.
This XView problem is partially corrected with the list item scrollbar
fix supplied with wxWindows, but choice items (and probably other items)
still don't work properly.
\hy-8{416}{3.}  On creation of a new frame, XView often appears to send too many repaint
events to subwindows.  I can't find a way around this, any suggestions
appreciated.
\hy-8{417}{4.}  Windows MDI support is hampered by the inability to paint icons
dynamically onto the iconized window client area, thus limiting icons to
one image for all child windows.
\hy-8{418}{5.}  There are MDI focus problems: you need to set the subwindow focus
explicitly or character input is not received.
\hy-8{419}{6.}  Mapping mode support is patchy.
\hy-8{420}{7.}  PostScript output control could be improved. Mapping mode ignored
by PostScript driver.
\hy-8{421}{8.}  Some text window behaviour is not implemented in Windows (e.g.
character input).



\hy-10{423}{Future developments}

The following enhancements are under consideration, some of which have
been discussed earlier.


\hy-8{424}{1.}  Better support for image file loading and display.
\hy-8{425}{2.}  Interception of all wxWindows system events, for `meta-applications' such
as a special-needs interface.
\hy-8{426}{3.}  An enhanced text window for the Windows environment.
\hy-8{427}{4.}  Improved PostScript handling.


Please contact Julian Smart for a list of ongoing projects related to
wxWindows.


\hy-10{431}{General}

\hy-7{432}{wxWindows doesn't compile.}

Most UNIX environments that have Motif or XView installed, and a C++
compiler, should be capable of compiling wxWindows. However, there can
be small differences between platforms that have not been catered for:
these might be things such as differences in the way NULL is defined,
network or timer-specific function differences, changes in typedefs in
Motif, etc. Most people have been able to resolve these problems by
small changes to the source. wxWindows uses few, if any, unportable C++
constructs, such as templates or exceptions.

Some problems are caused by an incorrect compiler installation (for example,
an incomplete GNU GCC installation) so do try compiling a small, non-wxWindows
program before concluding wxWindows is at fault.

\hy-7{433}{The program exits abnormally without initializing.}

You may be declaring a pen, brush, icon, cursor or colour globally.
These objects automatically add themselves to global lists which may
not be initialized before the object constructors are called, and so
only global pointers to these objects may be declared. After or during
\hy-8{434}{OnInit} is called, these objects may be created with impunity.


\hy-10{436}{Motif-specific problems}

\hy-7{437}{Panel items do not size or position correctly.}

Absolute positioning in Motif doesn't mix well with constraint-based positioning,
as used by wxWindows to implement left-to-right, top-to-bottom layout.

If you know that all your widgets are going to be positioned and sized explicitly,
you should pass the style flag \hy-8{438}{wxABSOLUTE_POSITIONING} to the panel constructor,
in which case a Motif bulletin board widget will be used instead of a form widget.

Another possibility is to try setting the widget sizes first, and finally setting the panel size.


\hy-10{440}{Windows-specific problems}

\hy-7{441}{Dialog boxes refuse to appear.}

You probably forgot to include the file wx.rc in your resource script
(see \hy-13{442}{Resources}).

MDI child windows don't size properly.

For some reason, it's not possible to programmatically resize an MDI
child frame just after creation, so using \hy-7{443}{Fit} to size an MDI
child frame around a subwindow does not work.

Also, it does not seem to be possible (on creation at least) to hide an
MDI child frame, resize its subwindows, then show it.

If you are using \hy-7{444}{Fit} to size the child window, you must
put up with seeing the windows repaint themselves: the child
window will come up already visible.

However, if you know the size of the window in advance, give it an
absolute size, create it with the wxMINIMIZE window style, draw
the contents, then call \hy-7{445}{Iconize(FALSE)} to restore the
window. This at least avoids seeing half-painted windows whilst
things get initialized.

\hy-7{446}{I get a link error.}

See sections \hy-13{447}{Memory models} and \hy-13{448}{Large Data}. Also, try invoking
the Microsoft C++ help program (Quick Help) with the given error message.

Under Turbo C++ for Windows, you are likely to get an error which says
that there is too much debugging information. Unfortunately, this is a
fault of Borland's linker, and can only be solved by omitting some
sections of your program from the debugging process, or by buying a new
linker. Here is a message from the UseNet on the subject.

\hy-14{449}{Article 34639 of comp.lang.c++:
>From: timh@loot01.demon.co.uk (Tim Hawkins)
Newsgroups: comp.lang.c++
Subject: Re: Turbo C++ 3.0 can't debug large programs!??
Date: 8 Aug 93 12:24:46 GMT
Reply-To: Timh@loot01.demon.co.uk

In article <5e0a8B2w165w@waffle.sns.com> billj@waffle.sns.com writes:

>zargon@leland.Stanford.EDU (Daniel Sommerfield) writes:
>> >However, I compiled my own class library (wxWindows) after much
>> >flicking of switches and fiddling with precompiled headers,
>> >only to find that linking with a small example program bombed
>> >the linker with "Debugging information overflow", and advice to
>> >reduce the number of modules with debugging information.
>> >
>Try downloading tdwin.zip from the Borland BBS.  Then unzip the file and 
>follow the procedures.  Probably you will end up renaming TDWIN.ZIP to 
>(TDWIN.DLL) to WINDEBUG.DLL.
>> 

This is a common problem with BC++, I get this on almost all of my projects

Using TDWIN will not help as the problem is during linking and not during
debugging sessions. 

The reason for the difficulty is that Borland limits the amount of symbolic
debug data to 256K, for "performance" reasons. However there is a fix,

SLR systems produce a linker which is fully compatable with the Tlink linker,
which does not suffer from this problem, it is called "optilink" and claims
to remove redundant methods as a bonus. If you get past the linker stage, and
still have problems, then this is because although TDW has a bigger symbol
limit than tlink, it is often still to small.. I have switched to using
the symantec "Multiscope" debugger which is also borland C++ compatable.

The link\debug system in BC++ is IMHO only suitable for small to medium
sized projects, and even then can bottle out at a suprisingly early stage.

Borland claim they have no plans to fix this problem. 
-- 
+--------------------------------------------------------------------------+
| Tim Hawkins  - timh@loot01.demon.co.uk     Loot Ltd Londons NoticeBoard  |
+--------------------------------------------------------------------------+
}


\hy-10{451}{XView-specific problems}

\hy-7{452}{Under X, the menu bar does not appear, and a blank area of window
appears instead.}

You may be using \hy-8{453}{SetClientSize} before the menu bar has been
created.  Call it after the whole window and its subwindows have been
created.

\hy-7{454}{Under XView, the following message appears:}

\hy-14{455}{XView warning: SERVER_IMAGE_BITMAP_FILE: Server image creation failed (Server Image package)}

The application may be looking for an icon file which does not exist or
has been referenced by a relative icon pathname. Use an absolute path, or
include the icon image in the source file using conditional compilation
(see the \hy-8{456}{wxIcon} class entry).


\hy-10{460}{The demo programs}

\hy-8{461}{A minimal wxWindows program}

\hy-8{485}{More advanced features: the \hy-7{487}{hello} demo}

\hy-8{502}{The MDI demo}

\hy-8{508}{The IPC demo}


\hy-10{522}{A Rough Guide}

To set a wxWindows application going, you'll need to derive a \hy-13{523}{wxApp} class.

An application must have a top-level \hy-13{524}{wxFrame} window (returned by \hy-13{525}{wxApp::OnInit}),
each frame containing one or more instances of \hy-13{526}{wxPanel}, \hy-13{527}{wxTextWindow}
or \hy-13{528}{wxCanvas}.

A frame can have a \hy-13{529}{wxMenuBar}, a status line, and a \hy-13{530}{wxIcon} for
when the frame is iconized.

A \hy-13{531}{wxPanel} is used to place items (classes derived from \hy-13{532}{wxItem})
which are used for user interaction. Examples of items are \hy-13{533}{wxButton},
\hy-13{534}{wxCheckBox}, \hy-13{535}{wxChoice}, \hy-13{536}{wxListBox}, \hy-13{537}{wxSlider},
\hy-13{538}{wxRadioBox}, \hy-13{539}{wxSlider}.

Instances of \hy-13{540}{wxDialogBox} can also be used for panels, items and they have
the advantage of not requiring a separate frame.

Instead of creating a dialog box and populating it with items, it is possible to choose
one of the convenient \hy-13{541}{dialog functions}, such as \hy-13{542}{wxMessageBox}
and \hy-13{543}{wxFileSelector}.

If you want to draw arbitrary graphics, you'll need a \hy-13{544}{wxCanvas}. In fact,
you never draw directly onto a canvas---you use a \hy-7{545}{device context} (DC). \hy-13{546}{wxDC} is
the base for \hy-13{547}{wxCanvasDC}, \hy-13{548}{wxMemoryDC}, \hy-13{549}{wxPostScriptDC},
\hy-13{550}{wxMemoryDC}, \hy-13{551}{wxMetaFileDC} and \hy-13{552}{wxPrinterDC}.
If your drawing functions have \hy-8{553}{wxDC} as a parameter, you can pass any of these DCs
to the function, and thus use the same code to draw to several different devices.
You can draw using the member functions of \hy-8{554}{wxDC}, such as \hy-13{555}{wxDC::DrawLine}
and \hy-13{556}{wxDC::DrawText}. Control colour on a canvas (\hy-13{557}{wxColour}) with
brushes (\hy-13{558}{wxBrush}) and pens (\hy-13{559}{wxPen}).

On a canvas, you will probably need to intercept key events by overriding the
\hy-13{560}{wxCanvas::OnChar} member, and mouse events by overriding \hy-13{561}{wxCanvas::OnEvent}.

Most modern applications will have an on-line, hypertext help system; for this, you
need wxHelp and the \hy-13{562}{wxHelpInstance} class to control
wxHelp. To add sparkle, you might use the wxToolBar class (documented separately)
which makes heavy use of the \hy-13{563}{wxBitmap}.

GUI applications aren't all graphical wizardry. List and hash table needs are
catered for by \hy-13{564}{wxList}, \hy-13{565}{wxStringList} and \hy-13{566}{wxHashTable}.
You will undoubtedly need some platform-independent \hy-13{567}{file functions},
and you may find it handy to maintain and search a list of paths using \hy-13{568}{wxPathList}.
There's a \hy-13{569}{miscellany} of operating system and other functions.

If you have several communicating applications, you can try out the DDE-like functions, by
using the three classes \hy-13{570}{wxClient}, \hy-13{571}{wxServer} and
\hy-13{572}{wxConnection}. These use DDE under Windows, and a simulation using
sockets under UNIX.


\hy-10{574}{wxApp: wxObject}

The \hy-8{575}{wxApp} class represents the application itself.  A wxWindows
application does not have a \hy-7{576}{main} procedure; the equivalent is the
\hy-13{577}{OnInit} member defined for a class derived from \hy-8{578}{wxApp}.
\hy-7{579}{OnInit} must create and return a main window frame as a bare minimum.
If NULL is returned from \hy-7{580}{OnInit}, the application will exit.
Note that the program's command line arguments, represented by \hy-7{581}{
argc} and \hy-7{582}{argv}, are available from within \hy-8{583}{wxApp} member functions.

An application closes by destroying all windows. Because all frames must
be destroyed for the application to exit, it is advisable to use parent
frames wherever possible when creating new frames, so that deleting the
top level frame will automatically delete child frames. The alternative
is to explicitly delete child frames in the top-level frame's \hy-13{584}{wxFrame::OnClose}
member.

In emergencies the \hy-13{585}{wxExit} function can be called to kill the
application.

An example of defining an application follows:

\hy-14{586}{class DerivedApp: public wxApp
{
 public:
  wxFrame *OnInit(void);
};

wxFrame *DerivedApp::OnInit(void)
{
  wxFrame *the_frame = new wxFrame(NULL, argv[0]);
  ...
  return the_frame;
}

MyApp DerivedApp;
}

\hy-8{587}{wxApp::wxApp}

\hy-8{591}{wxApp::~wxApp}

\hy-8{594}{wxApp::argc}

\hy-8{597}{wxApp::argv}

\hy-8{600}{wxApp::wx_class}

\hy-8{606}{wxApp::Initialized}

\hy-8{610}{wxApp::MainLoop}

\hy-8{613}{wxApp::OnExit}

\hy-8{616}{wxApp::OnInit}


\hy-10{620}{wxBitmap: wxObject}

This class encapsulates the concept of a platform-dependent bitmap,
either monochrome or colour. Platform-specific methods for creating a
\hy-8{621}{wxBitmap} structure from an existing file are catered for, and
this is an occasion where conditional compilation will probably be
required.

A bitmap created dynamically or loaded from a file can be selected
into a memory device context (instance of \hy-13{622}{wxMemoryDC}). This
enables the bitmap to be copied to a canvas or memory device context
using \hy-13{623}{wxDC::Blit}, or to be used as a drawing surface.  The \hy-8{624}{
wxToolBar} class was implemented using bitmaps, and the toolbar demo
shows one of the toolbar bitmaps being used for drawing a miniature
version of the graphic which appears on the main canvas.

wxWindows contains code to `grey out' a bitmap when used in an insensitive
panel item. Under X, this code is contained in the wxBitmap class.
Under Windows, the user-contributed Fafa library is responsible for this.

See \hy-13{625}{wxMemoryDC} for an example of drawing onto a bitmap.

The following shows the conditional compilation required to load a
bitmap in X and in Windows 3. The alternative is to use the string
version of the bitmap constructor, which loads a file under X and a
resource under Windows 3, but has the disadvantage of requiring the
X icon file to be available at run-time.

\hy-14{626}{#ifdef wx_x
#include "aiai.xbm"
#endif
#ifdef wx_msw
  wxIcon *icon = new wxBitmap("aiai");
#endif
#ifdef wx_x
  wxIcon *icon = new wxBitmap(aiai_bits, aiai_width, aiai_height);
#endif
}

\hy-8{627}{wxBitmap::wxBitmap}

\hy-8{641}{wxBitmap::~wxBitmap}

\hy-8{644}{wxBitmap::GetDepth}

\hy-8{647}{wxBitmap::GetHeight}

\hy-8{650}{wxBitmap::GetWidth}

\hy-8{653}{wxBitmap::Ok}


\hy-10{657}{wxBrush: wxObject}

A brush is a drawing tool for filling in areas. It is used for painting
the background of rectangles, ellipses, etc.  It has a colour and a
style - the style may be wxSOLID (normal) or wxTRANSPARENT (the brush
isn't used). On a monochrome display, the default behaviour is to show
all brushes as white unless the colour is really black. If you wish the
policy to be `all non-white colours are black', as with pens, uncomment
the piece of code documented in \hy-13{658}{wxDC::SetBrush} in wx_dc.cc.
Alternatively, set the \hy-8{659}{Colour} member of the device context to
TRUE, and select appropriate colours.

Do not initialize objects on the stack before the program commences,
since other required structures may not have been set up yet. Instead,
define global pointers to objects and create them in \hy-13{660}{wxApp::OnInit} or
when required.

An application may wish to create brushes with different
characteristics dynamically, and there is the consequent danger that a
large number of duplicate brushes will be created. Therefore an
application may wish to get a pointer to a brush by using the global
list of brushes \hy-8{661}{wxTheBrushList}, and calling the member function
\hy-8{662}{FindOrCreateBrush}. See \hy-13{663}{wxBrushList} and \hy-13{664}{wxDC}.

\hy-8{665}{wxBrush::wxBrush}

\hy-8{675}{wxBrush::~wxBrush}

\hy-8{678}{wxBrush::GetColour}

\hy-8{681}{wxBrush::GetStyle}

\hy-8{684}{wxBrush::SetColour}

\hy-8{694}{wxBrush::SetStyle}


\hy-10{699}{wxBrushList: wxList}

A brush list is a list containing all brushes which have been created.
There is only one instance of this class: \hy-8{700}{wxTheBrushList}.  Use
this object to search for a previously created brush of the desired
type and create it if not already found. In some windowing systems,
the brush may be a scarce resource, so it is best to reuse old
resources if possible.  When an application finishes, all brushes will
be deleted and their resources freed, eliminating the possibility of
`memory leaks'. See \hy-13{701}{wxBrush}.

\hy-8{702}{wxBrushList::wxBrushList}

\hy-8{706}{wxBrushList::AddBrush}

\hy-8{710}{wxBrushList::FindOrCreateBrush}

\hy-8{718}{wxBrushList::RemoveBrush}


\hy-10{723}{wxButton: wxItem}

A button is a \hy-7{724}{panel item} that contains a text string or bitmap,
and is one of the commonest elements of a GUI. It may be placed on a
\hy-13{725}{dialog box} or \hy-13{726}{panel}.

\hy-8{727}{wxButton::wxButton}

\hy-8{759}{wxButton::~wxButton}

\hy-8{762}{wxButton::Create}

\hy-8{786}{wxButton::SetDefault}

\hy-8{792}{wxButton::SetLabel}


\hy-10{797}{wxCanvas: wxWindow}

A canvas is a subwindow onto which graphics and text can be drawn, and
mouse and keyboard input can be intercepted.  At present, panel items
cannot be placed on a canvas.

To determine whether a canvas is colour or monochrome, test the canvas's
device context \hy-8{798}{Colour} boolean member variable.

When you draw onto a canvas, you are really drawing onto a \hy-7{799}{device
context} (see \hy-13{800}{wxDC}, \hy-13{801}{wxCanvasDC}).
Although you can use the members of wxCanvas for drawing,
it is much better to get the device context from the canvas
(see \hy-13{802}{GetDC}) and draw into that. Then,
code which can draw into one device context can be reused for others,
such as PostScript or memory device contexts (see \hy-13{803}{wxPostScriptDC}
and \hy-13{804}{wxMemoryDC}).

\hy-8{805}{wxCanvas::wxCanvas}

\hy-8{823}{wxCanvas::~wxCanvas}

\hy-8{826}{wxCanvas::Create}

\hy-8{837}{wxCanvas::Clear}

\hy-8{840}{wxCanvas::DestroyClippingRegion}

\hy-8{843}{wxCanvas::DrawArc}

\hy-8{855}{wxCanvas::DrawEllipse}

\hy-8{862}{wxCanvas::DrawLine}

\hy-8{869}{wxCanvas::DrawLines}

\hy-8{882}{wxCanvas::DrawPolygon}

\hy-8{895}{wxCanvas::DrawPoint}

\hy-8{900}{wxCanvas::DrawRectangle}

\hy-8{907}{wxCanvas::DrawRoundedRectangle}

\hy-8{915}{wxCanvas::DrawSpline}

\hy-8{926}{wxCanvas::DrawText}

\hy-8{932}{wxCanvas::EnableScrolling}

\hy-8{937}{wxCanvas::GetDC}

\hy-8{942}{wxCanvas::GetScrollUnitsPerPage}

\hy-8{948}{wxCanvas::GetVirtualSize}

\hy-8{955}{wxCanvas::IsRetained}

\hy-8{958}{wxCanvas::OnChar}

\hy-8{963}{wxCanvas::OnEvent}

\hy-8{969}{wxCanvas::OnPaint}

\hy-8{972}{wxCanvas::Scroll}

\hy-8{978}{wxCanvas::SetBackground}

\hy-8{983}{wxCanvas::SetClippingRegion}

\hy-8{991}{wxCanvas::SetBrush}

\hy-8{996}{wxCanvas::SetFont}

\hy-8{1002}{wxCanvas::SetLogicalFunction}

\hy-8{1008}{wxCanvas::SetPen}

\hy-8{1013}{wxCanvas::SetScrollbars}

\hy-8{1030}{wxCanvas::SetTextBackground}

\hy-8{1036}{wxCanvas::SetTextForeground}

\hy-8{1042}{wxCanvas::ViewStart}

\hy-8{1051}{wxCanvas::WarpPointer}


\hy-10{1057}{wxCanvasDC: wxDC}

A canvas device context is automatically created when a canvas is created.
It can be retrieved from a canvas with \hy-13{1058}{wxCanvas::GetDC} and then
drawn into. See \hy-13{1059}{wxDC} for further information on device contexts.

\hy-8{1060}{wxCanvasDC::wxCanvasDC}


\hy-10{1065}{wxCheckBox: wxItem}

A checkbox is a labelled box which is either on (checkmark is visible)
or off (no checkmark).

\hy-8{1066}{wxCheckBox::wxCheckBox}

\hy-8{1097}{wxCheckBox::~wxCheckBox}

\hy-8{1100}{wxCheckBox::Create}

\hy-8{1123}{wxCheckBox::GetValue}

\hy-8{1126}{wxCheckBox::SetLabel}

\hy-8{1130}{wxCheckBox::SetValue}


\hy-10{1135}{wxChoice: wxItem}

A choice item is used to select one of a list of strings. Unlike a
listbox, only the selection is visible until the user pulls down the
menu of choices. Under XView and Motif, all selections are visible
when the menu is displayed. Under Windows 3, a scrolling list is
displayed when the user wants to change the selection. Note that under
XView, creating a choice item with a large number of strings takes a
long time due to the inefficiency of Sun's implementation of the XView
choice item.

See also \hy-13{1136}{wxListBox}.

\hy-8{1137}{wxChoice::wxChoice}

\hy-8{1163}{wxChoice::~wxChoice}

\hy-8{1166}{wxChoice::Append}

\hy-8{1171}{wxChoice::Clear}

\hy-8{1174}{wxChoice::Create}

\hy-8{1189}{wxChoice::FindString}

\hy-8{1193}{wxChoice::GetSelection}

\hy-8{1196}{wxChoice::GetStringSelection}

\hy-8{1199}{wxChoice::SetSelection}

\hy-8{1203}{wxChoice::SetStringSelection}

\hy-8{1207}{wxChoice::GetString}


\hy-10{1213}{wxClient: wxIPCObject}

A wxClient object represents the client part of a client-server DDE
(Dynamic Data Exchange) conversation (available in \hy-7{1214}{both}
Windows and UNIX).

To create a client which can communicate with a suitable server,
you need to derive a class from wxConnection and another from wxClient.
The custom wxConnection class will intercept communications in
a `conversation' with a server, and the custom wxServer is required
so that a user-overriden \hy-13{1215}{wxClient::OnMakeConnection} member can return
a wxConnection of the required class, when a connection is made.

For example:

\hy-14{1216}{class MyConnection: public wxConnection
{
 public:
  MyConnection(void)::wxConnection(ipc_buffer, 3999) {}
  ~MyConnection(void) { }
  Bool OnAdvise(char *topic, char *item, char *data, int size, int format)
  { wxMessageBox(topic, data); }
};

class MyClient: public wxClient
{
 public:
  MyClient(void) {}
  wxConnection *OnMakeConnection(void) { return new MyConnection; }
};

}

Here, \hy-8{1217}{MyConnection} will respond to \hy-13{1218}{OnAdvise} messages sent
by the server.

When the client application starts, it must first call \hy-13{1219}{wxIPCInitialize}
before creating an instance of the derived wxClient. In the following, command line
arguments are used to pass the host name (the name of the machine the server is running
on) and the server name (identifying the server process). Calling \hy-13{1220}{wxClient::MakeConnection}
implicitly creates an instance of \hy-8{1221}{MyConnection} if the request for a
connection is accepted, and the client then requests an \hy-7{1222}{Advise} loop
from the server, where the server calls the client when data has changed.

\hy-14{1223}{  wxIPCInitialize();

  char *server = "4242";
  char hostName[256];
  wxGetHostName(hostName, sizeof(hostName));

  char *host = hostName;

  if (argc > 1)
    server = argv[1];
  if (argc > 2)
    host = argv[2];

  // Create a new client
  MyClient *client = new MyClient;
  the_connection = (MyConnection *)client->MakeConnection(host, server, "IPC TEST");

  if (!the_connection)
  {
    wxMessageBox("Failed to make connection to server", "Client Demo Error");
    return NULL;
  }
  the_connection->StartAdvise("Item");
}

See also \hy-13{1224}{wxServer}, \hy-13{1225}{wxConnection},
the chapter on interprocess communication in the user manual, and
the programs in \hy-14{1226}{samples/ipc}.

\hy-8{1227}{wxClient::wxClient}

\hy-8{1230}{wxClient::MakeConnection}

\hy-8{1237}{wxClient::OnMakeConnection}


\hy-10{1245}{wxColour: wxObject}

A colour is an object representing a Red, Green, Blue (RGB) combination
of primary colours, and is used to determine drawing colours. See the
entry for \hy-13{1246}{wxColourDatabase} for how a pointer to a predefined,
named colour may be returned instead of creating a new colour.

Valid RGB values are in the range 0 to 255.

\hy-8{1247}{wxColour::wxColour}

\hy-8{1256}{wxColour::Get}

\hy-8{1262}{wxColour::Ok}

\hy-8{1265}{wxColour::Set}


\hy-10{1272}{wxColourDatabase: wxObject}

wxWindows maintains a database of standard RGB colours for a predefined
set of named colours (such as ``BLACK'', ``LIGHT GREY''). The
application may add to this set if desired by using \hy-7{1273}{Append}.  There
is only one instance of this class: \hy-8{1274}{wxTheColourDatabase}.

The colours in the standard database are as follows:

AQUAMARINE, BLACK, BLUE, BLUE VIOLET, BROWN, CADET BLUE, CORAL,
CORNFLOWER BLUE, CYAN, DARK GREY, DARK GREEN, DARK OLIVE GREEN, DARK
ORCHID, DARK SLATE BLUE, DARK SLATE GREY DARK TURQUOISE, DIM GREY,
FIREBRICK, FOREST GREEN, GOLD, GOLDENROD, GREY, GREEN, GREEN YELLOW,
INDIAN RED, KHAKI, LIGHT BLUE, LIGHT GREY, LIGHT STEEL BLUE, LIME GREEN,
MAGENTA, MAROON, MEDIUM AQUAMARINE, MEDIUM BLUE, MEDIUM FOREST GREEN,
MEDIUM GOLDENROD, MEDIUM ORCHID, MEDIUM SEA GREEN, MEDIUM SLATE BLUE,
MEDIUM SPRING GREEN, MEDIUM TURQUOISE, MEDIUM VIOLET RED, MIDNIGHT BLUE,
NAVY, ORANGE, ORANGE RED, ORCHID, PALE GREEN, PINK, PLUM, PURPLE, RED,
SALMON, SEA GREEN, SIENNA, SKY BLUE, SLATE BLUE, SPRING GREEN, STEEL
BLUE, TAN, THISTLE, TURQUOISE, VIOLET, VIOLET RED, WHEAT, WHITE, YELLOW,
YELLOW GREEN.

wxWindows' colour handling under XView and Motif prior to Version 1.50
was poor, due to a bug in the code which allocates colours. This has
now been fixed and a greater range of colours may be allocated.
However, if a very wide range of colours is used in an application,
wxWindows may still fail to allocate a colour, so it is best to choose
a fixed number of colours, pens or brushes rather than allocate
colours when needed.

See also \hy-13{1275}{wxColour}.

\hy-8{1276}{wxColourDatabase::wxColourDatabase}

\hy-8{1279}{wxColourDatabase::FindColour}

\hy-8{1283}{wxColourDatabase::FindName}

\hy-8{1287}{wxColourDatabase::Initialize}


\hy-10{1291}{wxColourMap: wxObject}

Colourmap functionality has yet to be implemented under wxWindows. This class
will be extended in the future.

\hy-8{1292}{wxColourMap::wxColourMap}

\hy-8{1295}{wxColourMap::~wxColourMap}


\hy-10{1299}{wxCommandEvent: wxEvent}

This event class contains information about panel item command events.
It is passed to \hy-13{1300}{wxFunction} panel item callbacks. It
can also be constructed by an application and used with \hy-13{1301}{wxSendEvent}
to simulate a user command in a panel item.

\hy-8{1302}{wxCommandEvent::clientData}

\hy-8{1305}{wxCommandEvent::commandInt}

\hy-8{1308}{wxCommandEvent::commandString}

\hy-8{1311}{wxCommandEvent::extraLong}

\hy-8{1314}{wxCommandEvent::wxCommandEvent}

\hy-8{1337}{wxCommandEvent::Checked}

\hy-8{1340}{wxCommandEvent::GetClientData}

\hy-8{1343}{wxCommandEvent::GetSelection}

\hy-8{1346}{wxCommandEvent::GetString}

\hy-8{1349}{wxCommandEvent::IsSelection}


\hy-10{1353}{wxConnection: wxObject}

A wxConnection object represents the connection between a client and a
server. It can be created by making a connection using a
\hy-13{1354}{wxClient} object, or by the acceptance of a connection by a
\hy-13{1355}{wxServer} object. The bulk of a DDE (Dynamic Data Exchange)
conversation (available in both Windows and UNIX) is controlled by
calling members in a \hy-8{1356}{wxConnection} object or by overriding its
members.

An application should normally derive a new connection class from
wxConnection, in order to override the communication event handlers
to do something interesting.

See \hy-13{1357}{wxClient}, \hy-13{1358}{wxServer}, and
the chapter on interprocess communication in the user manual.

\hy-8{1359}{wxConnection::wxConnection}

\hy-8{1367}{wxConnection::Advise}

\hy-8{1375}{wxConnection::Execute}

\hy-8{1383}{wxConnection::Disconnect}

\hy-8{1389}{wxConnection::OnAdvise}

\hy-8{1397}{wxConnection::OnDisconnect}

\hy-8{1400}{wxConnection::OnExecute}

\hy-8{1407}{wxConnection::OnPoke}

\hy-8{1415}{wxConnection::OnRequest}

\hy-8{1424}{wxConnection::OnStartAdvise}

\hy-8{1429}{wxConnection::OnStopAdvise}

\hy-8{1434}{wxConnection::Poke}

\hy-8{1442}{wxConnection::Request}

\hy-8{1449}{wxConnection::StartAdvise}

\hy-8{1454}{wxConnection::StopAdvise}


\hy-10{1460}{wxCursor: wxObject}

A cursor is a small bitmap usually used for denoting where the mouse
pointer is, with a picture that might indicate the interpretation of a
mouse click. As with icons, cursors in X and Windows 3 are created
in a different manner. Therefore, separate cursors will be created for the
different environments.  Platform-specific methods for creating a \hy-8{1461}{
wxCursor} object are catered for, and this is an occasion where
conditional compilation will probably be required (see \hy-13{1462}{wxIcon} for
an example).

A single cursor object may be used in many windows (any subwindow type).
The wxWindows convention is to set the cursor for a window, as in X,
rather than to set it globally as in Windows 3, although a
global \hy-13{1463}{::wxSetCursor} is also available for Windows 3 use.

Run the \hy-7{1464}{hello} demo program to see what stock cursors are
available.

\hy-8{1465}{wxCursor::wxCursor}

\hy-8{1501}{wxCursor::~wxCursor}


\hy-10{1505}{wxDC: wxObject}

A wxDC is \hy-7{1506}{device context} onto which graphics and text can be drawn.
It is intended to represent a number of output devices in a generic way,
so a canvas has a device context and a printer also has a device context.
In this way, the same piece of code may write to a number of different devices,
if the device context is used as a parameter.

To determine whether a device context is colour or monochrome, test the
\hy-8{1507}{Colour} Bool member variable. To override wxWindows monochrome
graphics drawing behaviour, set this member to TRUE.

From version 1.5, this class is abstract and cannot be used to create
device context objects. Instead, use the derived classes \hy-13{1508}{wxPostScriptDC},
\hy-13{1509}{wxMetaFileDC}, \hy-13{1510}{wxMemoryDC} or \hy-13{1511}{wxPrinterDC}
(Windows only) for constructing new device contexts.  \hy-13{1512}{wxCanvasDC}
is a context that cannot be created by the user but can be retrieved from
a \hy-13{1513}{wxCanvas} by using \hy-13{1514}{wxCanvas::GetDC}.

When writing code to draw into a device context, use \hy-8{1515}{wxDC} as a
parameter whenever possible, to allow the most general use of your
drawing code.  You can then pass a device context object of any
derived type. See the demo in \hy-14{1516}{samples/hello} for code which
uses this device-independent method of drawing.

Derived types of \hy-8{1517}{wxDC} have documentation for specific features
only, so refer to this section for most device context information.

\hy-8{1518}{wxDC::wxDC}

\hy-8{1521}{wxDC::~wxDC}

\hy-8{1524}{wxDC::Blit}

\hy-8{1537}{wxDC::Clear}

\hy-8{1540}{wxDC::DestroyClippingRegion}

\hy-8{1544}{wxDC::DeviceToLogicalX}

\hy-8{1548}{wxDC::DeviceToLogicalY}

\hy-8{1552}{wxDC::DrawArc}

\hy-8{1564}{wxDC::DrawEllipse}

\hy-8{1571}{wxDC::DrawIcon}

\hy-8{1577}{wxDC::DrawLine}

\hy-8{1584}{wxDC::DrawLines}

\hy-8{1597}{wxDC::DrawPolygon}

\hy-8{1610}{wxDC::DrawPoint}

\hy-8{1615}{wxDC::DrawRectangle}

\hy-8{1622}{wxDC::DrawRoundedRectangle}

\hy-8{1630}{wxDC::DrawSpline}

\hy-8{1641}{wxDC::DrawText}

\hy-8{1648}{wxDC::EndDoc}

\hy-8{1651}{wxDC::EndPage}

\hy-8{1654}{wxDC::GetMapMode}

\hy-8{1659}{wxDC::GetSize}

\hy-8{1664}{wxDC::GetTextExtent}

\hy-8{1679}{wxDC::LogicalToDeviceX}

\hy-8{1683}{wxDC::LogicalToDeviceY}

\hy-8{1687}{wxDC::MaxX}

\hy-8{1690}{wxDC::MaxY}

\hy-8{1693}{wxDC::MinX}

\hy-8{1696}{wxDC::MinY}

\hy-8{1699}{wxDC::Ok}

\hy-8{1702}{wxDC::SetBackground}

\hy-8{1706}{wxDC::SetBackgroundMode}

\hy-8{1711}{wxDC::SetClippingRegion}

\hy-8{1719}{wxDC::SetBrush}

\hy-8{1724}{wxDC::SetFont}

\hy-8{1729}{wxDC::SetLogicalFunction}

\hy-8{1735}{wxDC::SetMapMode}

\hy-8{1747}{wxDC::SetPen}

\hy-8{1751}{wxDC::SetTextBackground}

\hy-8{1756}{wxDC::SetTextForeground}

\hy-8{1761}{wxDC::SetUserScale}

\hy-8{1766}{wxDC::StartDoc}

\hy-8{1770}{wxDC::StartPage}


\hy-10{1774}{wxDialogBox: wxPanel}

A dialog box is similar to a panel, in that it is a window which can
be used for placing panel items, with the following exceptions:


\hy-8{1775}{1.}  A surrounding frame is implicitly created.
\hy-8{1776}{2.}  Extra functionality is automatically given to the dialog box,
  such as tabbing between items (currently Windows only).
\hy-8{1777}{3.}  If the dialog box is \hy-7{1778}{modal}, the calling program is blocked
  until the dialog box is dismissed.


Under XView, some panel items may display incorrectly in a modal dialog.

Note that under Windows 3, modal dialogs have to be emulated using
modeless dialogs and a message loop. This is because Windows 3 expects
the contents of a modal dialog to be loaded from a resource file or
created on receipt of a dialog initialization message. This is too
restrictive for wxWindows, where any window may be created and displayed
before its contents are created.

It would be easy to add a facility for loading Windows 3 dialog
resources instead of building them programmatically, but of course
this method is very non-portable. See the discussion about dialogs in
the user manual.

For a set of dialog convenience functions, including file selection, see
\hy-13{1779}{Dialog functions}.

See also \hy-13{1780}{wxPanel} and \hy-13{1781}{wxWindow} for inherited
member functions.

\hy-8{1782}{wxDialogBox::wxDialogBox}

\hy-8{1811}{wxDialogBox::~wxDialogBox}

\hy-8{1814}{wxDialog::Centre}

\hy-8{1821}{wxDialogBox::Create}

\hy-8{1834}{wxDialogBox::GetTitle}

\hy-8{1837}{wxDialogBox::Iconize}

\hy-8{1843}{wxDialogBox::Iconized}

\hy-8{1846}{wxDialogBox::SetTitle}

\hy-8{1850}{wxDialogBox::Show}


\hy-10{1857}{wxEnhDialogBox: wxDialogBox}

The purpose of the wxEnhDialogBox class is to make it easy to
provide a common look for all dialog boxes of an application. The
wxEnhDialogBox separates the dialog box into four areas:


\hy-8{1858}{o}  the pin area
\hy-8{1859}{o}  the user area
\hy-8{1860}{o}  the command area
\hy-8{1861}{o}  the status area


For now, these panels are tiled vertically, but in future there may a
style flag to allow placement of the command area to the right of the dialog, as
is common in Windows applications.

The pin area is borrowed from the pushpin metaphor of XView, and can be
disabled via a compilation flag. Again, a flag style is perhaps more
judicious and may be implemented in future.

The user area is left free for the application programmer.

The command area contains command buttons which are centered automatically
by the \hy-13{1862}{wxEnhDialogBox::Fit} method.

The status area provides a way to display status messages, as in XView.

All areas can have distints fonts sets, currently controlled by a compilation
flag. The pushpin can be replaced by a Cancel button (automatically created)
if WANT_CANCEL_BUTTON is defined when compiling.

\hy-8{1863}{wxEnhDialogBox::wxEnhDialogBox}

\hy-8{1878}{wxEnhDialogBox::~wxEnhDialogBox}

\hy-8{1881}{wxEnhDialogBox::userPanel}

\hy-8{1884}{wxEnhDialogBox::SetStatus}

\hy-8{1888}{wxEnhDialogBox::AddCmd}

\hy-8{1899}{wxEnhDialogBox::GetCmd}

\hy-8{1904}{wxEnhDialogBox::SetPin}

\hy-8{1908}{wxEnhDialogBox::Show}

\hy-8{1916}{wxEnhDialogBox::Fit}


\hy-10{1920}{wxEvent: wxObject}

An event is a structure holding information about an event passed to a
callback or member function. \hy-8{1921}{wxEvent} used to be a multipurpose
event object, and is now an abstract base class for events such
as \hy-13{1922}{wxCommandEvent} (for panel item commands)
and \hy-13{1923}{wxMouseEvent} (for mouse events on windows).

\hy-8{1924}{wxEvent::wxEvent}

\hy-8{1927}{wxEvent::~wxEvent}

\hy-8{1930}{wxEvent::eventClass}

\hy-8{1933}{wxEvent::eventHandle}

\hy-8{1936}{wxEvent::eventObject}

\hy-8{1939}{wxEvent::eventType}

\hy-8{1942}{wxEvent::ReadEvent}

\hy-8{1946}{wxEvent::WriteEvent}


\hy-10{1951}{wxFont: wxObject}

A font is an object which determines the appearance of text, primarily
when drawing text to a canvas or device context. A font is determined by
four parameters:


\hy-8{1952}{o}  Point size.  This is the standard way of referring to text size.
\hy-8{1953}{o}  Family.  Supported families are:
  \hy-8{1954}{wxDEFAULT, wxDECORATIVE, wxROMAN, wxSCRIPT, wxSWISS, wxMODERN}.
  \hy-8{1955}{wxMODERN} is a fixed pitch font; the others are either fixed or variable pitch.
\hy-8{1956}{o}  Style. The value can be \hy-8{1957}{wxNORMAL, wxSLANT} or \hy-8{1958}{wxITALIC}.
\hy-8{1959}{o}  Weight. The value can be \hy-8{1960}{wxNORMAL, wxLIGHT} or \hy-8{1961}{wxBOLD}.
\hy-8{1962}{o}  Underlining. The value can be TRUE or FALSE.


There is currently a difference between the appearance of fonts on the
two platforms, if the mapping mode is anything other than MM_TEXT.
Under X, font size is always specified in points. Under Windows, the
unit for text is points but the text is scaled according to the
current mapping mode.  However, user scaling on a device canvas will
also scale fonts under both environments. A future version of
wxWindows will attempt to make font appearance more consistent across
platforms.

\hy-8{1963}{wxFont::wxFont}

\hy-8{1977}{wxFont::~wxFont}

\hy-8{1980}{wxFont::GetFamily}

\hy-8{1984}{wxFont::GetPointSize}

\hy-8{1987}{wxFont::GetStyle}

\hy-8{1991}{wxFont::GetUnderlined}

\hy-8{1994}{wxFont::GetWeight}


\hy-10{1999}{wxFontList: wxList}

A font list is a list containing all fonts which have been created. There
is only one instance of this class: \hy-8{2000}{wxTheFontList}.  Use this object to search
for a previously created font of the desired type and create it if not already found.
In some windowing systems, the font may be a scarce resource, so it is best to
reuse old resources if possible.  When an application finishes, all fonts will be
deleted and their resources freed, eliminating the possibility of `memory leaks'.

\hy-8{2001}{wxFontList::wxFontList}

\hy-8{2005}{wxFontList::AddFont}

\hy-8{2009}{wxFontList::FindOrCreateFont}

\hy-8{2017}{wxFontList::RemoveFont}


\hy-10{2022}{wxForm: wxObject}

\hy-8{2023}{The purpose of the form class}

\hy-8{2025}{Constraints on form items}

\hy-8{2027}{Form appearance}

\hy-8{2038}{Example}

\hy-8{2044}{wxForm::wxForm}

\hy-8{2059}{wxForm::~wxForm}

\hy-8{2062}{wxForm::Add}

\hy-8{2067}{wxForm::FindItem}

\hy-8{2071}{wxForm::Set}

\hy-8{2076}{wxForm::Delete}

\hy-8{2080}{wxForm::AssociatePanel}

\hy-8{2084}{wxForm::OnCancel}

\hy-8{2088}{wxForm::OnOk}

\hy-8{2092}{wxForm::OnRevert}

\hy-8{2095}{wxForm::OnUpdate}

\hy-8{2098}{wxForm::RevertValues}

\hy-8{2101}{wxForm::UpdateValues}

\hy-8{2104}{Functions for making form items and constraints}


\hy-10{2188}{wxFrame: wxWindow}

A frame is a window which contains subwindows of various kinds. It has a
title bar and, optionally, a menu bar, and a status line.  Depending on
the platform, the frame has further menus or buttons relating to window
movement, sizing, closing, etc. Most of these events are handled by the host
system without need for special handling by the application. However,
the application should normally define an \hy-13{2189}{wxFrame::OnClose} handler for the
frame so that related data and subwindows can be cleaned up.

The Windows 3 issues of Multiple Document Interface (MDI) versus Single
Document Interface (SDI) frames are covered in the user manual.

A frame may contain the subwindows \hy-13{2190}{wxCanvas}, \hy-13{2191}{wxPanel}
and \hy-13{2192}{wxTextWindow}.

\hy-8{2193}{wxFrame::wxFrame}

\hy-8{2235}{wxFrame::~wxFrame}

\hy-8{2238}{wxFrame::Centre}

\hy-8{2245}{wxFrame::Command}

\hy-8{2250}{wxFrame::Create}

\hy-8{2262}{wxFrame::CreateStatusLine}

\hy-8{2267}{wxFrame::Fit}

\hy-8{2271}{wxFrame::GetTitle}

\hy-8{2275}{wxFrame::Iconize}

\hy-8{2279}{wxFrame::Iconized}

\hy-8{2282}{wxFrame::Maximize}

\hy-8{2287}{wxFrame::OnClose}

\hy-8{2295}{wxFrame::OnMenuCommand}

\hy-8{2300}{wxFrame::OnMenuSelect}

\hy-8{2305}{wxFrame::OnSize}

\hy-8{2311}{wxFrame::SetIcon}

\hy-8{2318}{wxFrame::SetMenuBar}

\hy-8{2324}{wxFrame::SetStatusText}

\hy-8{2331}{wxFrame::SetTitle}

\hy-8{2336}{wxFrame::StatusLineExists}


\hy-10{2342}{wxFunction}.

The type of a panel item callback function.

\hy-8{2343}{wxFunction}


\hy-10{2351}{wxIcon: wxObject}

An icon is a small rectangular bitmap usually used for denoting a
minimized application. It is optional (but desirable) to associate a
pertinent icon with a frame. Obviously icons in X and Windows 3 are
created in a different manner, and colour icons in X are difficult
to arrange. Therefore, separate icons will be created for the different
environments.  Platform-specific methods for creating a \hy-8{2352}{wxIcon}
structure are catered for, and this is an occasion where conditional
compilation will probably be required.

Note that a new icon must be created for every time the icon is to be
used for a new window. In X, this will ensure that fresh X resources
are allocated for this frame. In Windows 3, the icon will not be
reloaded if it has already been used. An icon allocated to a frame will
be deleted when the frame is deleted.

The following shows the conditional compilation required to define an
icon in X and in Windows 3. The alternative is to use the string
version of the icon constructor, which loads a file under X and a
resource under Windows 3, but has the disadvantage of requiring the
X icon file to be available at run-time. If anyone can invent a
scheme or macro which does the following more elegantly and
platform-independently, I'd like to see it!

\hy-14{2353}{#ifdef wx_x
#include "aiai.xbm"
#endif
#ifdef wx_msw
  wxIcon *icon = new wxIcon("aiai");
#endif
#ifdef wx_x
  wxIcon *icon = new wxIcon(aiai_bits, aiai_width, aiai_height);
#endif
}

See also \hy-13{2354}{wxDC::DrawIcon}, \hy-13{2355}{wxBitmap}.

\hy-8{2356}{wxIcon::wxIcon}

\hy-8{2366}{wxIcon::~wxIcon}


\hy-10{2370}{wxHashTable: wxObject}

This class provides hash table functionality for wxWindows, and for an
application if it wishes.  Data can be hashed on an integer or string
key.  Below is an example of using a hash table.

\hy-14{2371}{  wxHashTable table(KEY_STRING);

  wxPoint *point = new wxPoint(100, 200);
  table.Put("point 1", point);

  ....

  wxPoint *found_point = (wxPoint *)table.Get("point 1");
}

A hash table is implemented as an array of pointers to lists. When no
data has been stored, the hash table takes only a little more space than
this array (default size is 1000).  When a data item is added, an
integer is constructed from the integer or string key that is within the
bounds of the array. If the array element is NULL, a new (keyed) list is
created for the element. Then the data object is appended to the list,
storing the key in case other data objects need to be stored in the list
also (when a `collision' occurs).

Retrieval involves recalculating the array index from the key, and searching
along the keyed list for the data object whose stored key matches the passed
key. Obviously this is quicker when there are fewer collisions, so hashing
will become inefficient if the number of items to be stored greatly exceeds
the size of the hash table.

See also \hy-13{2372}{wxList}.

\hy-8{2373}{wxHashTable::wxHashTable}

\hy-8{2380}{wxHashTable::~wxHashTable}

\hy-8{2383}{wxHashTable::BeginFind}

\hy-8{2389}{wxHashTable::Clear}

\hy-8{2392}{wxHashTable::Delete}

\hy-8{2398}{wxHashTable::Get}

\hy-8{2404}{wxHashTable::MakeKey}

\hy-8{2408}{wxHashTable::Next}

\hy-8{2416}{wxHashTable::Put}


\hy-10{2425}{wxHelpInstance: wxClient}

The \hy-8{2426}{wxHelpInstance} class implements the interface by which
applications may invoke wxHelp to provide on-line help. Each instance
of the class maintains one connection to an instance of wxHelp which
belongs to the application, and which is shut down when the Quit
member of \hy-8{2427}{wxHelpInstance} is called (for example in the \hy-8{2428}{
OnClose} member of an application's main frame). Under Windows 3,
there is currently only one instance of wxHelp which is used by all
applications.

Since there is a DDE link between the two programs, each subsequent
request to display a file or section uses the existing instance of
wxHelp, rather than starting a new instance each time. wxHelp thus
appears to the user to be an extension of the current application.
wxHelp may also be invoked independently of a client application.

Normally an application will create an instance of \hy-8{2429}{
wxHelpInstance} when it starts, and immediately call \hy-8{2430}{Initialize}
to associate a filename with it. wxHelp will only get run, however,
just before the first call to display something. See the test program
supplied with the wxHelp source.

Include the file \hy-14{2431}{wx_help.h} to use this API, even if you have
included \hy-14{2432}{wx.h}.

If you give TRUE to the constructor, you can use the native help system
where appropriate (currently under Windows only). Omit the file extension
to allow wxWindows to choose the appropriate file for the platform.

\hy-8{2433}{wxHelpInstance::wxHelpInstance}

\hy-8{2438}{wxHelpInstance::~wxHelpInstance}

\hy-8{2440}{wxHelpInstance::Initialize}

\hy-8{2445}{wxHelpInstance::DisplayBlock}

\hy-8{2449}{wxHelpInstance::DisplayContents}

\hy-8{2452}{wxHelpInstance::DisplaySection}

\hy-8{2456}{wxHelpInstance::KeywordSearch}

\hy-8{2460}{wxHelpInstance::LoadFile}

\hy-8{2465}{wxHelpInstance::OnQuit}

\hy-8{2468}{wxHelpInstance::Quit}


\hy-10{2472}{wxItem: wxWindow}

This is the base class for any widget or control which can be placed on a panel
or dialog box.

\hy-8{2473}{wxItem::Centre}

\hy-8{2482}{wxItem::Command}

\hy-8{2487}{wxItem::SetLabel}

\hy-8{2491}{wxItem::GetLabel}


\hy-10{2495}{wxKeyEvent: wxEvent}

This event class contains information about key events. See \hy-13{2496}{wxCanvas::OnChar}.

\hy-8{2497}{wxKeyEvent::controlDown}

\hy-8{2500}{wxKeyEvent::keyCode}

\hy-8{2503}{wxKeyEvent::shiftDown}

\hy-8{2506}{wxKeyEvent::wxKeyEvent}

\hy-8{2510}{wxKeyEvent::ControlDown}

\hy-8{2513}{wxKeyEvent::KeyCode}

\hy-8{2518}{wxKeyEvent::ShiftDown}


\hy-10{2522}{wxList: wxObject}

This class provides linked list functionality for wxWindows, and for an application
if it wishes.  Depending on the form of constructor used, a list can be keyed on
integer or string keys to provide a primitive look-up ability. See \hy-13{2523}{wxHashTable}
for a faster method of storage when random access is required.

It is very common to iterate on a list as follows:

\hy-14{2524}{  ...
  wxPoint *point1 = new wxPoint(100, 100);
  wxPoint *point2 = new wxPoint(200, 200);

  wxList SomeList;
  SomeList.Append(point1);
  SomeList.Append(point2);

  ...

  wxNode *node = SomeList.First();
  while (node)
  {
    wxPoint *point = (wxPoint *)node->Data();
    ...
    node = node->Next();
  }
}

To delete nodes in a list as the list is being traversed, replace

\hy-14{2525}{    ...
    node = node->Next();
    ...
}

with

\hy-14{2526}{    ...
    delete point;
    delete node;
    node = SomeList.First();
    ...
}

See \hy-13{2527}{wxNode} for members that retrieve the data associated with a node, and
members for getting to the next or previous node.

Note that a cast is required when retrieving the data from a node.  Although a
node is defined to store objects of type \hy-8{2528}{wxObject} and derived types, other
types (such as char *) may be used with appropriate casting.

\hy-8{2529}{wxList::wxList}

\hy-8{2542}{wxList::~wxList}

\hy-8{2545}{wxList::Append}

\hy-8{2557}{wxList::Clear}

\hy-8{2560}{wxList::DeleteContents}

\hy-8{2566}{wxList::DeleteNode}

\hy-8{2570}{wxList::DeleteObject}

\hy-8{2575}{wxList::Find}

\hy-8{2582}{wxList::First}

\hy-8{2585}{wxList::Insert}

\hy-8{2593}{wxList::Last}

\hy-8{2596}{wxList::Member}

\hy-8{2601}{wxList::Nth}

\hy-8{2606}{wxList::Number}


\hy-10{2610}{wxListBox: wxItem}

A list box is used to select one or more of a list of strings. The
strings are displayed in a scrolling box, with the selected string(s)
marked in reverse video. A list item can be single selection (if an item
is selected, the previous selection is removed) or multiple selection
(clicking an item toggles the item on or off independently of other
selections).

See also \hy-13{2611}{wxChoice}.

\hy-8{2612}{wxListBox::wxListBox}

\hy-8{2645}{wxListBox::~wxListBox}

\hy-8{2648}{wxListBox::Append}

\hy-8{2657}{wxListBox::Clear}

\hy-8{2660}{wxListBox::Create}

\hy-8{2676}{wxListBox::Delete}

\hy-8{2680}{wxListBox::Deselect}

\hy-8{2684}{wxListBox::FindString}

\hy-8{2688}{wxListBox::GetClientData}

\hy-8{2692}{wxListBox::GetSelection}

\hy-8{2695}{wxListBox::GetSelections}

\hy-8{2699}{wxListBox::GetStringSelection}

\hy-8{2702}{wxListBox::Selected}

\hy-8{2706}{wxListBox::Set}

\hy-8{2711}{wxListBox::SetFirstItem}

\hy-8{2717}{wxListBox::SetSelection}

\hy-8{2722}{wxListBox::SetStringSelection}

\hy-8{2726}{wxListBox::GetString}


\hy-10{2732}{wxMemoryDC: wxObject}

A memory device context provides a means to draw graphics onto a bitmap.

A bitmap must be selected into the new memory DC before it may be used
for anything.  Typical usage is as follows:

\hy-14{2733}{  // Create a memory DC
  wxMemoryDC temp_dc;
  temp_dc.SelectObject(test_bitmap);

  // We can now draw into the memory DC...
  // Copy from this DC to another DC.
  old_dc.Blit(250, 50, BITMAP_WIDTH, BITMAP_HEIGHT, temp_dc, 0, 0);
}

Note that the memory DC \hy-7{2734}{must} be deleted before a bitmap
can be reselected into another memory DC.

See also \hy-13{2735}{wxBitmap}, \hy-13{2736}{wxDC}, \hy-13{2737}{wxCanvasDC}.

\hy-8{2738}{wxMemoryDC::wxMemoryDC}

\hy-8{2744}{wxMemoryDC::SelectObject}


\hy-10{2751}{wxMenu: wxItem}

A menu is a popup (or pull down) list of items, one of which may be
selected before the menu goes away (clicking elsewhere dismisses the
menu).  Menus may be used to construct either menu bars or popup menus.

A menu item has an integer ID associated with it which can be used to
identify the selection, or to change the menu item in some way.

See also \hy-13{2752}{wxFrame::OnMenuCommand} and \hy-13{2753}{wxWindow::PopupMenu}.

\hy-8{2754}{wxMenu::wxMenu}

\hy-8{2760}{wxMenu::~wxMenu}

\hy-8{2763}{wxMenu::Append}

\hy-8{2778}{wxMenu::AppendSeparator}

\hy-8{2781}{wxMenu::Check}

\hy-8{2787}{wxMenu::Enable}

\hy-8{2793}{wxMenu::FindItem}

\hy-8{2797}{wxMenu::FindItemForId}

\hy-8{2801}{wxMenu::GetHelpString}

\hy-8{2805}{wxMenu::GetLabel}

\hy-8{2811}{wxMenu::GetTitle}

\hy-8{2814}{wxMenu::SetHelpString}

\hy-8{2819}{wxMenu::SetLabel}

\hy-8{2824}{wxMenu::SetTitle}


\hy-10{2829}{wxMenuBar: wxItem}

A menu bar is a series of menus accessible from the top of a frame.
Selecting a title pulls down a menu; selecting a menu item causes a \hy-7{2830}{
MenuSelection} message to be passed to the frame with the menu item
integer id as the only argument.

\hy-8{2831}{wxMenuBar::wxMenuBar}

\hy-8{2838}{wxMenuBar::~wxMenuBar}

\hy-8{2841}{wxMenuBar::Append}

\hy-8{2847}{wxMenuBar::Check}

\hy-8{2853}{wxMenuBar::Enable}

\hy-8{2859}{wxMenuBar::EnableTop}

\hy-8{2865}{wxMenuBar::FindMenuItem}

\hy-8{2870}{wxMenuBar::FindItemById}

\hy-8{2874}{wxMenuBar::GetHelpString}

\hy-8{2878}{wxMenuBar::GetLabel}

\hy-8{2883}{wxMenuBar::GetLabelTop}

\hy-8{2889}{wxMenuBar::SetHelpString}

\hy-8{2894}{wxMenuBar::SetLabel}

\hy-8{2900}{wxMenuBar::SetLabelTop}


\hy-10{2908}{wxMessage: wxItem}

A message is a simple line of text which may be displayed in a panel. It does not
respond to mouse clicks.

\hy-8{2909}{wxMessage::wxMessage}

\hy-8{2923}{wxMessage::~wxMessage}

\hy-8{2926}{wxMessage::Create}


\hy-10{2937}{wxMetaFile: wxObject}

A \hy-8{2938}{wxMetaFile} represents the Windows 3 metafile object, so metafile
operations have no effect in X. In wxWindows, only sufficient functionality
has been provided for copying a graphic to the clipboard; this may be extended
in a future version. Presently, the only way of creating a metafile
is to use a wxMetafileDC.

\hy-8{2939}{wxMetaFile::wxMetaFile}

\hy-8{2942}{wxMetaFile::~wxMetaFile}

\hy-8{2945}{wxMetaFile::SetClipboard}


\hy-10{2953}{wxMetaFileDC: wxDC}

This is a type of device context that allows a metafile object to be
created (Windows only), and has most of the characteristics of a normal
\hy-8{2954}{wxDC}. The \hy-13{2955}{wxMetaFileDC::Close} member must be called after drawing into the
device context, to return a metafile. The only purpose for this at
present is to allow the metafile to be copied to the clipboard (see \hy-13{2956}{wxMetaFile}).

Adding metafile capability to an application should be easy if you
already write to a wxDC; simply pass the wxMetaFileDC to your drawing
function instead. You may wish to conditionally compile this code so it
is not compiled under X (although no harm will result if you leave it
in).

Note that a metafile saved to disk is in standard Windows metafile format,
and cannot be imported into most applications. To make it importable,
call the function \hy-13{2957}{::wxMakeMetaFilePlaceable} after
closing your disk-based metafile device context.

\hy-8{2958}{wxMetaFileDC::wxMetaFileDC}

\hy-8{2962}{wxMetaFileDC::~wxMetaFileDC}

\hy-8{2965}{wxMetaFileDC::Close}


\hy-10{2969}{wxMouseEvent: wxEvent}

This event class contains information about mouse events, particularly
events received by canvases. See \hy-13{2970}{wxCanvas::OnEvent}.

\hy-8{2971}{wxMouseEvent::controlDown}

\hy-8{2974}{wxMouseEvent::leftDown}

\hy-8{2977}{wxMouseEvent::middleDown}

\hy-8{2980}{wxMouseEvent::rightDown}

\hy-8{2983}{wxMouseEvent::leftDown}

\hy-8{2986}{wxMouseEvent::shiftDown}

\hy-8{2989}{wxMouseEvent::x}

\hy-8{2992}{wxMouseEvent::y}

\hy-8{2995}{wxMouseEvent::wxMouseEvent}

\hy-8{3013}{wxMouseEvent::Button}

\hy-8{3018}{wxMouseEvent::ButtonDown}

\hy-8{3022}{wxMouseEvent::ControlDown}

\hy-8{3025}{wxMouseEvent::Dragging}

\hy-8{3028}{wxMouseEvent::IsButton}

\hy-8{3032}{wxMouseEvent::LeftDown}

\hy-8{3035}{wxMouseEvent::LeftIsDown}

\hy-8{3038}{wxMouseEvent::LeftUp}

\hy-8{3041}{wxMouseEvent::MiddleDown}

\hy-8{3044}{wxMouseEvent::MiddleIsDown}

\hy-8{3047}{wxMouseEvent::MiddleUp}

\hy-8{3050}{wxMouseEvent::Moving}

\hy-8{3053}{wxMouseEvent::Position}

\hy-8{3061}{wxMouseEvent::RightDown}

\hy-8{3064}{wxMouseEvent::RightIsDown}

\hy-8{3067}{wxMouseEvent::RightUp}

\hy-8{3070}{wxMouseEvent::ShiftDown}


\hy-10{3074}{wxMultiText: wxText}

Members as for \hy-8{3075}{wxText}, but allowing multiple lines of text.

\hy-8{3076}{wxMultiText::GetValue}


\hy-10{3083}{wxNode: wxObject}

A node structure used in linked lists (see \hy-13{3084}{wxList}).

\hy-8{3085}{wxNode::Data}

\hy-8{3088}{wxNode::Next}

\hy-8{3091}{wxNode::Previous}

\hy-8{3094}{wxNode::SetData}


\hy-10{3098}{wxObject}

This is the root class of all wxWindows classes, and has no base
functionality.  It declares a virtual destructor which ensures that
destructors get called for all derived class objects where necessary.

\hy-8{3099}{wxObject::__type}


\hy-10{3105}{wxPanel: wxWindow}

A panel is a subwindow of a frame in which \hy-7{3106}{panel items} can be placed to allow
the user to view and set controls. Panel items include messages, text items, list items,
and check boxes. Use \hy-8{3107}{Fit} to fit the panel around its items.

\hy-8{3108}{wxPanel::wxPanel}

\hy-8{3139}{wxPanel::~wxPanel}

\hy-8{3142}{wxPanel::Create}

\hy-8{3153}{wxPanel::Fit}

\hy-8{3156}{wxPanel::GetButtonFont}

\hy-8{3159}{wxPanel::GetCursor}

\hy-8{3164}{wxPanel::GetDefaultItem}

\hy-8{3168}{wxPanel::GetHorizontalSpacing}

\hy-8{3171}{wxPanel::GetLabelFont}

\hy-8{3174}{wxPanel::GetVerticalSpacing}

\hy-8{3177}{wxPanel::NewLine}

\hy-8{3180}{wxPanel::OnDefaultAction}

\hy-8{3186}{wxPanel::SetHorizontalSpacing}

\hy-8{3190}{wxPanel::SetLabelPosition}

\hy-8{3201}{wxPanel::SetButtonFont}

\hy-8{3205}{wxPanel::SetLabelFont}

\hy-8{3209}{wxPanel::SetVerticalSpacing}

\hy-8{3213}{wxPanel::Tab}


\hy-10{3218}{wxPathList: wxList}

The path list is a convenient way of storing a number of directories, and
when presented with a filename without a directory, searching for an existing file
in those directories.  Storing the filename only in an application's files and
using a locally-defined list of directories makes the application and its files more
portable.

Use the \hy-7{3219}{FileNameFromPath} global function to extract the filename
from the path.

\hy-8{3220}{wxPathList::wxPathList}

\hy-8{3223}{wxPathList::AddEnvList}

\hy-8{3227}{wxPathList::AddPath}

\hy-8{3231}{wxPathList::FindValidPath}

\hy-8{3236}{wxPathList::Member}


\hy-10{3241}{wxPen: wxObject}

A pen is a drawing tool for drawing outlines. It is used for drawing
lines and painting the outline of rectangles, ellipses, etc.  It has a
colour, a width and a style. On a monochrome display, the default
behaviour is to show all non-white pens as black. To change this,
set the \hy-8{3242}{Colour} member of the device context to TRUE, and select
appropriate colours.

The style may be one of wxSOLID, wxDOT, wxLONG_DASH, wxSHORT_DASH and
wxDOT_DASH. The names of these styles should be self explanatory.

Do not initialize objects on the stack before the program commences,
since other required structures may not have been set up yet. Instead,
define global pointers to objects and create them in \hy-7{3243}{OnInit} or
when required.

An application may wish to dynamically create pens with different
characteristics, and there is the consequent danger that a large number
of duplicate pens will be created. Therefore an application may wish to
get a pointer to a pen by using the global list of pens \hy-8{3244}{
wxThePenList}, and calling the member function \hy-8{3245}{FindOrCreatePen}.
See the entry for \hy-13{3246}{wxPenList}.

\hy-8{3247}{wxPen::wxPen}

\hy-8{3259}{wxPen::~wxPen}

\hy-8{3262}{wxPen::GetColour}

\hy-8{3265}{wxPen::GetStyle}

\hy-8{3268}{wxPen::GetWidth}

\hy-8{3271}{wxPen::SetColour}

\hy-8{3281}{wxPen::SetStyle}

\hy-8{3285}{wxPen::SetWidth}


\hy-10{3290}{wxPenList: wxList}

A pen list is a list containing all pens which have been created. There
is only one instance of this class: \hy-8{3291}{wxThePenList}.  Use this object to search
for a previously created pen of the desired type and create it if not already found.
In some windowing systems, the pen may be a scarce resource, so it is best to
reuse old resources if possible.  When an application finishes, all pens will be
deleted and their resources freed, eliminating the possibility of `memory leaks'.

\hy-8{3292}{wxPenList::wxPenList}

\hy-8{3296}{wxPenList::AddPen}

\hy-8{3300}{wxPenList::FindOrCreatePen}

\hy-8{3310}{wxPenList::RemovePen}


\hy-10{3315}{wxPoint: wxObject}

A \hy-8{3316}{wxPoint} is a useful data structure for graphics operations.
It simply contains floating point \hy-7{3317}{x} and \hy-7{3318}{y} members.

\hy-8{3319}{wxPoint::wxPoint}


\hy-10{3329}{wxPostScriptDC: wxDC}

This defines the wxWindows Encapsulated PostScript device context,
which can write PostScript files on any platform. See \hy-13{3330}{wxDC} for
descriptions of the member functions.

\hy-8{3331}{wxPostScriptDC::wxPostScriptDC}


\hy-10{3350}{wxPrinterDC: wxDC}

A printer device context is specific to Windows, and allows access to
any printer with a Windows driver. See \hy-13{3351}{wxDC} for further information
on device contexts.

\hy-8{3352}{wxPrinterDC::wxPrinterDC}


\hy-10{3364}{wxRadioBox: wxItem}

A radio box item is used to select one of number of mutually exclusive
choices.  It is displayed as a vertical column or horizontal row of
labelled buttons.

\hy-8{3365}{wxRadioBox::wxRadioBox}

\hy-8{3406}{wxRadioBox::~wxRadioBox}

\hy-8{3409}{wxRadioBox::Create}

\hy-8{3438}{wxRadioBox::Enable}

\hy-8{3445}{wxRadioBox::FindString}

\hy-8{3449}{wxRadioBox::GetSelection}

\hy-8{3452}{wxRadioBox::GetStringSelection}

\hy-8{3455}{wxRadioBox::Number}

\hy-8{3458}{wxRadioBox::SetSelection}

\hy-8{3462}{wxRadioBox::SetStringSelection}

\hy-8{3466}{wxRadioBox::GetString}


\hy-10{3472}{wxServer: wxIPCObject}

A wxServer object represents the server part of a client-server DDE
(Dynamic Data Exchange) conversation (available in \hy-7{3473}{both} Windows
and UNIX). 

\hy-8{3474}{wxServer::wxServer}

\hy-8{3477}{wxServer::Create}

\hy-8{3481}{wxServer::OnAcceptConnection}


\hy-10{3487}{wxSlider: wxItem}

A slider is, as its name suggests, an item with a handle which can be pulled
back and forth to change a value.  It is currently horizontal only. In Windows 3,
a scrollbar is used to simulate the slider.

\hy-8{3488}{wxSlider::wxSlider}

\hy-8{3508}{wxSlider::~wxSlider}

\hy-8{3511}{wxSlider::Create}

\hy-8{3526}{wxSlider::GetValue}

\hy-8{3529}{wxSlider::SetValue}


\hy-10{3534}{wxStringList: wxList}

A string list is a list which is assumed to contain strings, with a
specific member functions. Memory is allocated when strings are added to
the list, and deallocated by the destructor or by the \hy-8{3535}{Delete}
member.

\hy-8{3536}{wxStringList::wxStringList}

\hy-8{3541}{wxStringList::~wxStringList}

\hy-8{3544}{wxStringList::Add}

\hy-8{3548}{wxStringList::Delete}

\hy-8{3552}{wxStringList::ListToArray}

\hy-8{3557}{wxStringList::Member}

\hy-8{3563}{wxStringList::Sort}


\hy-10{3567}{wxText: wxWindow}

A text item is an area of editable text, with an optional label
displayed in front of it.

\hy-8{3568}{wxText::wxText}

\hy-8{3589}{wxText::~wxText}

\hy-8{3592}{wxText::Create}

\hy-8{3606}{wxText::GetValue}

\hy-8{3609}{wxText::SetValue}


\hy-10{3615}{wxTextWindow: wxWindow}

A text window is a subwindow of a frame, offering some basic ability
to display scrolling text. At present, editing is only possible using
the XView and Motif implementations.

Some manipulation functions take integer positions, starting from zero.
Many of these are currently platform-specific, and have yet to be fully
implemented.

\hy-8{3616}{wxTextWindow::wxTextWindow}

\hy-8{3633}{wxTextWindow::~wxTextWindow}

\hy-8{3636}{wxTextWindow::Clear}

\hy-8{3639}{wxTextWindow::Create}

\hy-8{3650}{wxTextWindow::DiscardEdits}

\hy-8{3654}{wxTextWindow::GetContents}

\hy-8{3657}{wxTextWindow::GetInsertionPoint}

\hy-8{3660}{wxTextWindow::GetLastPosition}

\hy-8{3663}{wxTextWindow::GetLineLength}

\hy-8{3667}{wxTextWindow::GetLineText}

\hy-8{3672}{wxTextWindow::GetNumberOfLines}

\hy-8{3675}{wxTextWindow::Highlight}

\hy-8{3682}{wxTextWindow::LoadFile}

\hy-8{3686}{wxTextWindow::Modified}

\hy-8{3689}{wxTextWindow::Remove}

\hy-8{3696}{wxTextWindow::Replace}

\hy-8{3705}{wxTextWindow::SetFont}

\hy-8{3709}{wxTextWindow::ShowPosition}

\hy-8{3713}{wxTextWindow::SetInsertionPoint}

\hy-8{3718}{wxTextWindow::SetInsertionPointEnd}

\hy-8{3721}{wxTextWindow::SaveFile}

\hy-8{3725}{wxTextWindow::WriteText}

\hy-8{3730}{wxTextWindow::XYToPosition}

\hy-8{3735}{wxTextWindow::<<}


\hy-10{3751}{wxTimer: wxObject}

The wxTimer object is an abstraction of Windows 3, XView and X toolkit timers. To
use it, derive a new class and override the \hy-8{3752}{Notify} member to
perform the required action. Start with \hy-8{3753}{Start}, stop with \hy-8{3754}{
Stop}, it's as simple as that.

See also \hy-13{3755}{::wxStartTimer} and \hy-13{3756}{::wxGetElapsedTime}
for stopwatch functions.

\hy-8{3757}{wxTimer::wxTimer}

\hy-8{3760}{wxTimer::~wxTimer}

\hy-8{3763}{wxTimer::Notify}

\hy-8{3766}{wxTimer::Start}

\hy-8{3771}{wxTimer::Stop}


\hy-10{3775}{wxTypeTree: wxList}

wxTypeTree implements an explicit type hierarchy which can be useful for
querying C++ types at run-time, usually by calling \hy-13{3776}{wxSubType}
using the \hy-13{3777}{wxObject::__type} member.

A type is added to the global variable \hy-8{3778}{wxAllTypes}; wxWindows adds
its own standard types on initialization, in \hy-8{3779}{wxInitStandardTypes},
but the application can add its own.

The standard wxWindows types, grouped by functionality, are:


\hy-8{3780}{o}  wxTYPE_ANY
\hy-8{3781}{o}  wxTYPE_OBJECT (an alias for wxTYPE_ANY)
\hy-8{3782}{o}  wxTYPE_WINDOW
\hy-8{3783}{o}  wxTYPE_DIALOG_BOX
\hy-8{3784}{o}  wxTYPE_ITEM
\hy-8{3785}{o}  wxTYPE_PANEL
\hy-8{3786}{o}  wxTYPE_CANVAS
\hy-8{3787}{o}  wxTYPE_TEXT_WINDOW
\hy-8{3788}{o}  wxTYPE_FRAME
\hy-8{3789}{o}  wxTYPE_BUTTON
\hy-8{3790}{o}  wxTYPE_TEXT
\hy-8{3791}{o}  wxTYPE_MESSAGE
\hy-8{3792}{o}  wxTYPE_CHOICE
\hy-8{3793}{o}  wxTYPE_LIST_BOX
\hy-8{3794}{o}  wxTYPE_SLIDER
\hy-8{3795}{o}  wxTYPE_CHECK_BOX
\hy-8{3796}{o}  wxTYPE_MENU
\hy-8{3797}{o}  wxTYPE_MENU_BAR
\hy-8{3798}{o}  wxTYPE_MULTI_TEXT
\hy-8{3799}{o}  wxTYPE_RADIO_BOX
\hy-8{3800}{o}  wxTYPE_EVENT
\hy-8{3801}{o}  wxTYPE_DC
\hy-8{3802}{o}  wxTYPE_DC_CANVAS
\hy-8{3803}{o}  wxTYPE_DC_POSTSCRIPT
\hy-8{3804}{o}  wxTYPE_DC_PRINTER
\hy-8{3805}{o}  wxTYPE_DC_METAFILE
\hy-8{3806}{o}  wxTYPE_DC_MEMORY
\hy-8{3807}{o}  wxTYPE_MOUSE_EVENT
\hy-8{3808}{o}  wxTYPE_KEY_EVENT
\hy-8{3809}{o}  wxTYPE_COMMAND_EVENT
\hy-8{3810}{o}  wxTYPE_PEN
\hy-8{3811}{o}  wxTYPE_BRUSH
\hy-8{3812}{o}  wxTYPE_FONT
\hy-8{3813}{o}  wxTYPE_ICON
\hy-8{3814}{o}  wxTYPE_BITMAP
\hy-8{3815}{o}  wxTYPE_METAFILE
\hy-8{3816}{o}  wxTYPE_TIMER
\hy-8{3817}{o}  wxTYPE_COLOUR
\hy-8{3818}{o}  wxTYPE_COLOURMAP
\hy-8{3819}{o}  wxTYPE_CURSOR
\hy-8{3820}{o}  wxTYPE_DDE_CLIENT
\hy-8{3821}{o}  wxTYPE_DDE_SERVER
\hy-8{3822}{o}  wxTYPE_DDE_CONNECTION
\hy-8{3823}{o}  wxTYPE_HELP_INSTANCE
\hy-8{3824}{o}  wxTYPE_LIST
\hy-8{3825}{o}  wxTYPE_STRING_LIST
\hy-8{3826}{o}  wxTYPE_HASH_TABLE
\hy-8{3827}{o}  wxTYPE_NODE
\hy-8{3828}{o}  wxTYPE_APP


\hy-8{3829}{wxTypeTree::wxTypeTree}

\hy-8{3832}{wxTypeTree::AddType}

\hy-8{3842}{wxTypeTree::GetName}


\hy-10{3847}{wxWindow: wxObject}

wxWindow is the base class for all windows and panel items.  Any
children of the window will be deleted automatically by the destructor
before the window itself is deleted.

\hy-8{3848}{wxWindow::wxWindow}

\hy-8{3851}{wxWindow::~wxWindow}

\hy-8{3854}{wxWindow::AddChild}

\hy-8{3858}{wxWindow::CaptureMouse}

\hy-8{3862}{wxWindow::Center}

\hy-8{3867}{wxWindow::Centre}

\hy-8{3874}{wxWindow::ClientToScreen}

\hy-8{3881}{wxWindow::DestroyChildren}

\hy-8{3884}{wxWindow::DragAcceptFiles}

\hy-8{3888}{wxWindow::Enable}

\hy-8{3892}{wxWindow::GetCharHeight}

\hy-8{3895}{wxWindow::GetCharWidth}

\hy-8{3898}{wxWindow::GetChildren}

\hy-8{3901}{wxWindow::GetClientData}

\hy-8{3904}{wxWindow::GetClientSize}

\hy-8{3909}{wxWindow::GetGrandParent}

\hy-8{3912}{wxWindow::GetHandle}

\hy-8{3915}{wxWindow::GetPosition}

\hy-8{3920}{wxWindow::GetLabel}

\hy-8{3923}{wxWindow::GetParent}

\hy-8{3926}{wxWindow::GetSize}

\hy-8{3931}{wxWindow::GetTextExtent}

\hy-8{3937}{wxWindow::OnActivate}

\hy-8{3942}{wxWindow::OnChar}

\hy-8{3950}{wxWindow::OnDropFiles}

\hy-8{3962}{wxWindow::OnEvent}

\hy-8{3968}{wxWindow::OnKillFocus}

\hy-8{3971}{wxWindow::OnPaint}

\hy-8{3974}{wxWindow::PopupMenu}

\hy-8{3981}{wxWindow::OnSetFocus}

\hy-8{3984}{wxWindow::OnSize}

\hy-8{3990}{wxWindow::ReleaseMouse}

\hy-8{3994}{wxWindow::ScreenToClient}

\hy-8{4001}{wxWindow::SetFocus}

\hy-8{4005}{wxWindow::SetSize}

\hy-8{4012}{wxWindow::SetClientData}

\hy-8{4016}{wxWindow::SetClientSize}

\hy-8{4024}{wxWindow::SetColourMap}

\hy-8{4028}{wxWindow::SetCursor}

\hy-8{4034}{wxWindow::SetTitle}

\hy-8{4038}{wxWindow::Show}


\hy-10{4044}{File functions}

See also \hy-13{4045}{wxPathList}.

\hy-8{4046}{::DirExists}

\hy-8{4050}{::Dos2UnixFilename}

\hy-8{4054}{::FileExists}

\hy-8{4058}{::FileNameFromPath}

\hy-8{4062}{::IsAbsolutePath}

\hy-8{4066}{::PathOnly}

\hy-8{4070}{::Unix2DosFilename}

\hy-8{4074}{::wxConcatFiles}

\hy-8{4083}{::wxCopyFile}

\hy-8{4090}{::wxGetTempFileName}

\hy-8{4098}{::wxIsWild}

\hy-8{4103}{::wxMatchWild}

\hy-8{4113}{::wxMkdir}

\hy-8{4118}{::wxRemoveFile}

\hy-8{4123}{::wxRenameFile}

\hy-8{4130}{::wxRmdir}


\hy-10{4136}{String functions}

\hy-8{4137}{::copystring}

\hy-8{4143}{::StringMatch}


\hy-10{4155}{Dialog functions}

Below are a number of convenience functions for getting input from the
user or displaying messages. Note that in these functions the last three
parameters are optional. However, it is recommended to pass a parent frame
parameter, or (in Windows 3) the wrong window frame may be brought to
the front when the dialog box is popped up.

\hy-8{4156}{::wxFileSelector}

\hy-8{4169}{::wxGetTextFromUser}

\hy-8{4183}{::wxGetSingleChoice}

\hy-8{4197}{::wxGetSingleChoiceIndex}

\hy-8{4209}{::wxGetSingleChoiceData}

\hy-8{4222}{::wxMessageBox}


\hy-10{4243}{GDI functions}

The following are relevant to the GDI (Graphics Device Interface).

\hy-8{4244}{::wxColourDisplay}

\hy-8{4247}{::wxDisplayDepth}

\hy-8{4250}{::wxMakeMetaFilePlaceable}

\hy-8{4260}{::wxSetCursor}


\hy-10{4267}{System event functions}

The wxWindows system event implementation is incomplete and
experimental, but is intended to be a platform-independent way of
intercepting and sending events, including defining
application-specific events and handlers.

Ultimately it is intended to be used as a way of testing wxWindows
applications using scripts, although there are currently
problems with this (especially with modal dialogs).

All this is documented more to provoke comments and suggestions, and
jog my own memory, rather than to be used, since it has not been
tested. However \hy-8{4268}{wxSendEvent} will probably work if you
instantiate the event structure properly for a command event type (see
the code in \hy-14{4269}{wb_panel.cc} for \hy-13{4270}{wxPanel::OnDefaultAction}
which uses \hy-8{4271}{wxSendEvent} to send a command to the default button).

\hy-8{4272}{::wxAddPrimaryEventHandler}

\hy-8{4276}{::wxAddSecondaryEventHandler}

\hy-8{4283}{::wxNotifyEvent}

\hy-8{4288}{::wxRegisterEventClass}

\hy-8{4295}{::wxRegisterEventName}

\hy-8{4302}{::wxRegisterExternalEventHandlers}

\hy-8{4305}{::wxRemoveSecondaryEventHandler}

\hy-8{4310}{::wxSendEvent}


\hy-10{4316}{Miscellaneous}

\hy-8{4317}{::NewId}

\hy-8{4320}{::RegisterId}

\hy-8{4326}{::wxBell}

\hy-8{4329}{::wxDebugMsg}

\hy-8{4335}{::wxDisplaySize}

\hy-8{4340}{::wxError}

\hy-8{4347}{::wxExecute}

\hy-8{4351}{::wxExit}

\hy-8{4357}{::wxFatalError}

\hy-8{4364}{::wxFindMenuItemId}

\hy-8{4370}{::wxFindWindowByLabel}

\hy-8{4376}{::wxGetHostName}

\hy-8{4383}{::wxGetElapsedTime}

\hy-8{4389}{::wxGetFreeMemory}

\hy-8{4392}{::wxGetResource}

\hy-8{4416}{::wxGetUserId}

\hy-8{4423}{::wxGetUserName}

\hy-8{4430}{::wxIPCInitialize}

\hy-8{4436}{::wxSleep}

\hy-8{4441}{::wxStripMenuCodes}

\hy-8{4448}{::wxStartTimer}

\hy-8{4453}{::wxSubType}

\hy-8{4463}{::wxWriteResource}

\hy-8{4488}{::wxYield}


\hy-10{4494}{API}

Application Programmer's Interface - a set of calls and classes defining
how a library (in this case, wxWindows) can be used.


\hy-10{4496}{Canvas}

A canvas in XView and wxWindows is a subwindow on which graphics (but
not panel items) can be drawn. It may be scrollable. A canvas has a
\hy-7{4497}{device context} associated with it.


\hy-10{4499}{DDE}

Dynamic Data Exchange - Microsoft's interprocess communication protocol.
wxWindows provides an abstraction of DDE under both Windows and UNIX.


\hy-10{4501}{Device context}

A device context is an abstraction away from devices such as windows,
printers and files. Code that draws to a device context is generic since
that device context could be associated with a number of different real
device. A canvas has a device context, although duplicate graphics calls
are provided for the canvas, so the beginner doesn't have to think in
terms of device contexts when starting out. wxWindows supports device
contexts for canvas, Windows printer, and Encapsulated PostScript files on UNIX.


\hy-10{4503}{Dialog box}

In wxWindows a dialog box is a convenient way of popping up a window
with panel items, without having to explicitly create a frame and a
panel. A dialog box may be modal or modeless. A modal dialog does not
return control back to the calling program until the user has dismissed
it, and all other windows in the application are disabled until the
dialog is dismissed.  A modeless dialog is just like a normal window in
that the user can access other windows while the dialog is displayed.


\hy-10{4505}{Frame}

Under XView (and wxWindows), a visible window usually consists of a
frame which contains zero or more subwindows, such as text subwindow,
canvas, and panel. Under Windows 3, windows can be nested arbitrarily,
but this is not currently supported in wxWindows.


\hy-10{4507}{GNU C++}

A free, solid C++ compiler which may be used to compile the UNIX side of
wxWindows applications.


\hy-10{4509}{GUI}

Graphical User Interface, such as Windows 3 or X.


\hy-10{4511}{Menu bar}

A menu bar is a series of labelled menus, usually placed near the top
of a window. It is popular in Windows 3 and Motif applications, and as
such is a supported feature, but wxWindows has to `simulate' the menu
bar under XView by using a panel and several menu buttons.


\hy-10{4513}{Metafile}

Microsoft Windows-specific object which may contain a restricted set of
GDI primitives. It is device independent, since it may be scaled without
losing precision, unlike a bitmap. A metafile may exist in a file or in
memory. wxWindows implements enough metafile functionality to use it to
pass graphics to other applications via the clipboard.


\hy-10{4515}{Open Look}

A specification for a GUI `look and feel', initiated by Sun
Microsystems. XView is one toolkit for writing Open Look applications
under X, and wxWindows sits on top of XView.


\hy-10{4517}{Panel}

A panel in XView and wxWindows terminology is a subwindow on which a
limited range of panel items (widgets or controls for user input) can be
placed. wxWindows allows panel items to be placed explicitly, or laid
out from left to right, top to bottom, which is a more platform
independent method since spacing is calculated automatically at run time.
Panel items cannot be placed on a canvas, which is specifically for
drawing graphics.


\hy-10{4519}{RPC}

Remote Procedure Call - a method of interprocess communication akin to
procedure call, where the client process makes a call to a server, which
sends back a result. The AIAI-supplied PROLOGIO library supports a
simple RPC protocol based on DDE (but working under both UNIX and
Windows).


\hy-10{4521}{Status line}

A status line is often found at the base of a window, to keep the user
informed (for instance, giving a line of description to menu items, as in the
\hy-8{4522}{hello} demo). XView has a status line (or footer) capability, but
wxWindows implements the feature explicitly under Windows 3 and Motif.


\hy-10{4524}{Text subwindow}

In XView and Motif, a text subwindow is supplied for displaying and
retrieving text from a window. It has a rich set of features, only a
small subset of which is currently catered for by wxWindows.


\hy-10{4526}{XView}

An X toolkit supplied by Sun Microsystems, initially just for porting
SunView applications to X, but which has become a popular toolkit in its
own right due to its simplicity of use. XView implements Sun's Open Look
`look and feel' for X, but is not the only toolkit to do so.








\hy-10{94}{MDI versus SDI}

In Windows 3.1, a popular technique is to use the MDI (Multiple Document
Interface) style, where the application window has a number of
iconizable document windows which fit within it. This can save clutter
on the desktop since iconizing or moving the parent window iconizes or
moves all the child windows. MDI contrasts with SDI (Single Document
Interface) in which windows are not constrained within one parent
window, and normal practice is to run one instance of the application
per document. Since wxWindows uses the large model, and large model
programs may be limited to one instance at a time (unless only one data
segment is used), it makes sense to offer MDI support. See
\hy-13{95}{Memory Models}.

I have decided to include largely automatic, albeit relatively
inflexible, support for MDI for these reasons:


\hy-8{96}{o}  Since it is likely that wxWindows programmers are writing for
multiple platforms, and only Windows 3.1 supports MDI, they will not wish
to spend much or any time implementing MDI features.
\hy-8{97}{o}  The difference between writing MDI and SDI applications
has been reduced to almost zero so even the beginner
can easily produce MDI programs.
\hy-8{98}{o}  What wxWindows's auto-MDI cannot handle is hardly worth the extra
effort anyway.


In wxWindows, one argument of the frame constructor is used to
indicate whether the frame is an SDI frame, an MDI parent frame or an
MDI child frame. The default is to create an SDI frame. Once MDI
frames are created, everything else is automatic, including appending
the usual \hy-8{99}{Window} menu option, and moving a child menu to the
parent frame when the child frame is activated.  The choice of menu
items for an MDI child frame will differ slightly, usually including
menus (such as Quit) which would normally be on the main SDI window,
but this only requires a small amount of extra application code.

The demo program \hy-8{100}{mdi} shows how a program can easily be made
switchable between SDI and MDI - use the \hy-8{101}{-mdi} command switch for
MDI operation.


\hy-10{119}{The wxWindows event system}

From Version 1.5, wxWindows has its own event system. Event classes are
derived from the abstract base class wxEvent (which used to serve as a
holder for canvas and panel item events). An event \hy-7{120}{class}
encapsulates a range of similar event \hy-7{121}{types}. For example, the
instances of the \hy-8{122}{wxMouseEvent} class may be generated for a number
of event types such as \hy-8{123}{wxEVENT_TYPE_LEFT_DOWN}.

There are several motivations for having an explicit representation
for events.

Firstly, encapsulating events in structures makes sense compared
with passing an event handler a large number of arguments.

Secondly, user input events may be simulated by sending events; this can
be used for automating GUI testing, and events could (in theory) be
stored for later playback. 

Thirdly, event handlers can be installed by programs or `meta-programs'
which want to override or examine program behaviour. For example, special-needs
access code could be written to enable GUI events to be expressed to the
user in a non-graphical form. Or, a meta-program could examine the
dialog structure of a running application and output a skeleton help file
corresponding to the application's hierarchy of menus and dialogs, taking
some of the donkey work out of preparing on-line help.

The event system is meant to be user-extensible so that any GUI-related
or application-specific events may be defined and used in a consistent
way. However, it is not yet completed and documented, and it is expected
to evolve over the next few releases. The eventual aim is an event
system which is comprehensive enough to enable wxWindows programs to be
tested automatically using scripts (possibly using NASA's CLIPS as the
scripting language -- see \hy-13{124}{CLIPS}).


\hy-10{162}{What wxWindows has}

Interprocess communication (IPC) has always been a tricky area, and
the plethora of techniques on different platforms has not helped.
Microsoft has laid down several standards for IPC under Windows 3.1, the
most fundamental being Dynamic Data Exchange (DDE). DDE is the basis
for wxWindows's IPC capability: the same, simple, object-oriented
interface is provided for a subset of DDE under both Windows on the
PC, and under XView and Motif on UNIX. The UNIX version is implemented
using sockets, and allows processes on the same or different machines
to talk to each other.

The benefits of wxWindows's DDE package are twofold: much greater
simplicity compared with DDE and UNIX sockets; and the considerable
advantage of keeping to platform-independence even in this notoriously
platform-dependent area. Currently only synchronous transactions are
handled; a later version of wxWindows may support asynchronous
transactions also.

A user-contributed package is available that replaces the wxWindows
implementation of DDE with a WinSock implementation, to allow
communication between Windows and UNIX. The API of that package is
identical to the one described in this manual.


\hy-10{164}{Principles of DDE}

The following describes how wxWindows implements DDE.  The following
three classes are crucial.


\hy-8{165}{1.}  wxClient. This represents the client application, and is used
only within a client program.
\hy-8{166}{2.}  wxServer. This represents the server application, and is used
only within a server program.
\hy-8{167}{3.}  wxConnection. This represents the connection from the current
client or server to the other application (server or client), and can be used
in both server and client programs. Most DDE
transactions operate on this object.


Messages between applications are usually identified by three variables:
connection object, topic name and item name.  A data string is a fourth
element of some messages. To create a connection (a conversation in
Windows parlance), the client application sends the message \hy-8{168}{
MakeConnection} to the client object, with a string service name to
identify the server and a topic name to identify the topic for the
duration of the connection. Under UNIX, the service name must contain an
integer port identifier.

The server then responds and either vetos the connection or allows it.
If allowed, a connection object is created which persists until the
connection is closed.  The connection object is then used for subsequent
messages between client and server.

To create a working server, the programmer must:


\hy-8{169}{1.}  Derive a class from wxServer.
\hy-8{170}{2.}  Override the handler \hy-8{171}{OnAcceptConnection} for accepting or rejecting a connection,
on the basis of the topic argument. This member must create and return a connection
object if the connection is accepted.
\hy-8{172}{3.}  Create an instance of your server object, and call \hy-8{173}{Create} to
activate it, giving it a service name.
\hy-8{174}{4.}  Derive a class from wxConnection.
\hy-8{175}{5.}  Provide handlers for various messages that are sent to the server
side of a wxConnection.


To create a working client, the programmer must:


\hy-8{176}{1.}  Derive a class from wxClient.
\hy-8{177}{2.}  Override the handler \hy-8{178}{OnMakeConnection} to create and return
an appropriate connection object.
\hy-8{179}{3.}  Create an instance of your client object.
\hy-8{180}{4.}  Derive a class from wxConnection.
\hy-8{181}{5.}  Provide handlers for various messages that are sent to the client
side of a wxConnection.
\hy-8{182}{6.}  When appropriate, create a new connection by sending a \hy-8{183}{MakeConnection}
message to the client object, with arguments host name (processed in UNIX only),
service name, and topic name for this connection. The client object will call \hy-8{184}{OnMakeConnection}
to create a connection object of the desired type.
\hy-8{185}{7.}  Use the wxConnection member functions to send messages to the server.



\hy-10{187}{Data transfer}

These are the ways that data can be transferred from one application to
another.


\hy-8{188}{o}  \hy-8{189}{Execute:} the client calls the server with a data string representing
a command to be executed. This succeeds or fails, depending on the
server's willingness to answer. If the client wants to find the result
of the Execute command other than success or failure, it has to explicitly
call Request.
\hy-8{190}{o}  \hy-8{191}{Request:} the client asks the server for a particular data string
associated with a given item string. If the server is unwilling to
reply, the return value is NULL. Otherwise, the return value is a string
(actually a pointer to the connection buffer, so it should not be
deallocated by the application).
\hy-8{192}{o}  \hy-8{193}{Poke:} The client sends a data string associated with an item
string directly to the server. This succeeds or fails.
\hy-8{194}{o}  \hy-8{195}{Advise:} The client asks to be advised of any change in data
associated with a particular item. If the server agrees, the server will
send an OnAdvise message to the client along with the item and data.


The default data type is wxCF_TEXT (ASCII text), and the default data
size is the length of the null-terminated string. Windows-specific data
types could also be used on the PC.


\hy-10{197}{Examples}

See the sample programs \hy-7{198}{server} and \hy-7{199}{client} in the IPC
samples directory.  Run the server, then the client. This demonstrates
using the Execute, Request, and Poke commands from the client, together
with an Advise loop: selecting an item in the server list box causes
that item to be highlighted in the client list box.

See also the source for wxHelp, which is a DDE server, and the files
wx_help.h and wx_help.cc which implement the client interface to
wxHelp.


\hy-10{201}{Remote Procedure Call}

DDE is quite a low level protocol, and all encoding and decoding of
messages must be done by the client and server applications. The
wxWindows extension \hy-7{202}{PROLOGIO} implements a remote procedure call
protocol (RPC) so that a server can implement a library of functions for
a client to call.  PROLOGIO makes it easy for applications to pack and
unpack the arguments and return value(s) of procedure calls, and
provides a mechanism for the server to register its available calls and
automatically handle the routing of calls to appropriate server
callbacks, one to a procedure definition. All this makes calling or
implementing server facilities childishly simple. Since PROLOGIO sits on
top of the DDE wrapper, it is also platform independent. See the
separate PROLOGIO manual and \hy-13{203}{PROLOGIO}.


\hy-10{283}{DOS makefiles}

DOS makefiles for Microsoft C++ are supplied (called \hy-14{284}{
makefile.dos)}. \hy-14{285}{makefile.nt} files are supplied for Windows NT with
the Microsoft compiler.

Borland \hy-14{286}{.prj} files are supplied for Turbo C++ for Windows
(unfortunately they are incompatible with Borland C++).

For Microsoft C++, normally it is only necessary to type \hy-14{287}{nmake -f
makefile.dos} (or an alias or batch file which does this). By default,
binaries are made with debugging information, and no optimization. Use
FINAL=1 on the command line to remove debugging information (this only
really necessary at the link stage), and DLL=1 to make a DLL version of
the library, if building a library.


\hy-10{289}{UNIX makefiles}

All makefiles have the targets \hy-7{290}{xview}, \hy-7{291}{motif} and \hy-7{292}{hp}.

\hy-7{293}{xview} builds an Sun Open Look version of the library, \hy-7{294}{motif}
builds a Sun Motif version, and \hy-7{295}{hp} builds a Motif version for HP
workstations.

Remove object files, executables and libraries for the
current module with the \hy-7{296}{clean_ol} and \hy-7{297}{clean_motif} and
\hy-7{298}{clean_hp} targets.

It is possible to maintain simultaneous Motif and Open Look versions
of an application, since object files are kept in separate directories
(\hy-7{299}{objects_ol} and \hy-7{300}{objects_motif}).

Debugging information is included by default; you may add DEBUG= as an
argument to make to compile without it, or use the UNIX \hy-8{301}{strip}
command to remove debugging information from an executable.



\hy-10{305}{Resource file}

The least that must be defined in the resource file (extension RC)
is the following statement:

\hy-14{306}{rcinclude wx.rc
}

which includes essential internal wxWindows definitions.  The resource script
may also contain references to icons, cursors, etc., for example:

\hy-14{307}{wxicon icon wx.ico
}

The icon can then be referenced by name when creating a frame icon. See
the Windows 3.1 SDK documentation.


\hy-10{309}{Module definition file}

A module definition file (extension DEF) looks like the following:

\hy-14{310}{; hello.def
;
;
NAME         Hello
DESCRIPTION  'Hello'
;
EXETYPE      WINDOWS
STUB         'WINSTUB.EXE'
;
CODE         PRELOAD MOVEABLE DISCARDABLE
DATA         PRELOAD MOVEABLE MULTIPLE
;
HEAPSIZE     1024
STACKSIZE    8192
}

The only lines which will usually have to be changed per application are
NAME and DESCRIPTION.


\hy-10{345}{Templates}

wxWindows does not use templates for two main reasons: one, it is a
notoriously unportable feature, and two, the author is irrationally
suspicious of them and prefers to use casts. More compilers are
now implementing templates, and so it will probably be safe to use
them soon without fear of portability problems.


\hy-10{347}{Definition of constructors}

Some compilers allows the user to omit constructor definitions where a
parent class provides a constructor with parameters. In Microsoft C++,
all constructors with parameters must be defined in the derived class,
or the compiler cannot find the required constructor.  This may mean
defining dummy constructors which call parent constructors, for example:

\hy-14{348}{MyClass::MyClass(int x, int y):ParentClass(x, y)
{
}
}

This is not a problem where the constructor has no parameters.


\hy-10{350}{Pointers to functions}

Some compilers are clever in their matching of function pointer
arguments to the declaration of the function, and will not complain in
the following case:

\hy-14{351}{typedef void (*wxFunction) (wxObject&, wxCommandEvent&);
...
void mycallback(wxButton& button, wxCommandEvent& event);
...
wxButton button(parent, &mycallback, label, 100, 200);
}

Since wxButton is derived from wxObject, the function \hy-7{352}{mycallback}
is a subtype of \hy-8{353}{wxFunction}.  In Microsoft C++, and most compilers
with a high warning level set, the function is not an exact match, and
the compiler complains. The solution is to place a cast in front of the
function address, thus:

\hy-14{354}{wxButton button(parent, (wxFunction)&mycallback, label, 100, 200);
}


\hy-10{356}{Precompiled headers}

Some compilers, such as Borland C++ and Microsoft C++, support
precompiled headers. This can save a great deal of compiling time. The
recommended approach is to precompile \hy-14{357}{``wx.h''}, using this
precompiled header for compiling both wxWindows itself and any
wxWindows applications. For Windows compilers, two dummy source files
are provided (one for normal applications and one for creating DLLs)
to allow initial creation of the precompiled header.

However, there are several downsides to using precompiled headers. One
is that to take advantage of the facility, you often need to include
more header files than would normally be the case. This means that
changing a header file will cause more recompilations (in the case of
wxWindows, everything needs to be recompiled since everything includes
\hy-14{358}{``wx.h''}!)

A related problem is that for compilers that don't have precompiled
headers, including a lot of header files slows down compilation
considerably. With Borland C++ it's possible to use pragmas and
conditional compilation to include \hy-14{359}{``wx.h''} under Windows and a
smaller number of files under UNIX, but conditional compilation of the
main header file isn't allowed by Microsoft C++, and so you're
typically stuck with lightning fast compilation under Windows and
treacle-slow compilation using less intelligent UNIX compilers. The
right balance obviously depends on the habits of the individual
developer.


\hy-10{462}{A minimal wxWindows program}

The best way to get a feel for how to use a tool is to see a small
example.  The supplied demo `minimal' (source file \hy-14{463}{minimal.cc})
shows a rudimentary wxWindows program. It has a main window with a panel
inside it, displaying a message. There is a menu bar with a \hy-8{464}{File} menu
which in turn has a \hy-8{465}{Quit} option, and the program has its own icon. Under
Windows 3.1, the system menu shows the usual options including Minimize,
Maximize and Close, and under X, there is a similar pull-down system
menu provided by the current window manager. The window is resizeable,
and the panel automatically resizes to fit its parent.

Look at \hy-14{466}{minimal.cc}.

\hy-12{467}{
\hy-14{468}{/*
 * File:	minimal.cc
 * Purpose:	Minimal wxWindows app
 * Author:	Julian Smart
 * Created:	1993
 * Updated:	
 * Copyright:	(c) 1993, AIAI, University of Edinburgh
 */

static const char sccsid[] = "%W% %G%";

#include "wx.h"

// Define a new application type
class MyApp: public wxApp
{ public:
    wxFrame *OnInit(void);
};

// Define a new frame type
class MyFrame: public wxFrame
{ public:
    MyFrame(wxFrame *frame, char *title, int x, int y, int w, int h);
    void OnMenuCommand(int id);
};

// ID for the menu quit command
#define MINIMAL_QUIT 1

// This statement initializes the whole application and calls OnInit
MyApp myApp;

// `Main program' equivalent, creating windows and returning main app frame
wxFrame *MyApp::OnInit(void)
{
  // Create the main frame window
  MyFrame *frame = new MyFrame(NULL, "Minimal wxWindows App", 50, 50, 400, 300);

  // Give it an icon
#ifdef wx_msw
  frame->SetIcon(new wxIcon("aiai_icn"));
#endif
#ifdef wx_x
  frame->SetIcon(new wxIcon("aiai.xbm"));
#endif

  // Make a menubar
  wxMenu *file_menu = new wxMenu;

  file_menu->Append(MINIMAL_QUIT, "Quit");
  wxMenuBar *menu_bar = new wxMenuBar;
  menu_bar->Append(file_menu, "File");
  frame->SetMenuBar(menu_bar);

  // Make a panel with a message
  wxPanel *panel = new wxPanel(frame, 0, 0, 400, 300);
  (void)new wxMessage(panel, "Hello, this is a minimal wxWindows program!", 0, 0);

  // Show the frame
  frame->Show(TRUE);

  // Return the main frame window
  return frame;
}

// My frame constructor
MyFrame::MyFrame(wxFrame *frame, char *title, int x, int y, int w, int h):
  wxFrame(frame, title, x, y, w, h)
{}

// Intercept menu commands
void MyFrame::OnMenuCommand(int id)
{
  switch (id) {
    case MINIMAL_QUIT:
      delete this;
    break;
  }
}

}
}

The statement \hy-14{469}{#include "wx.h"} provides the program with access to
all the wxWindows classes and functions.

The first class declaration, \hy-8{470}{MyApp}, declares a new application,
overriding one member function \hy-8{471}{OnInit}. This is an essential part
of writing a wxWindows program, since \hy-8{472}{OnInit} is the equivalent of
\hy-8{473}{main} in a normal C++ program.

The class \hy-8{474}{MyFrame} declares a constructor, and a message handler
for intercepting menu commands.

The definition of the global variable \hy-8{475}{myApp} looks innocuous enough
but this starts the whole application going simply by being defined.

The \hy-8{476}{OnInit} MyApp member function does the initialization of
the program. It creates a main frame, sets the icon,
creates a menu bar, a panel, and a panel item.

The \hy-8{477}{MyFrame} constructor may seem a little pointless, but it
fulfils the requirements of C++ syntax in defining the constructor in
terms of its parent's constructor.

The \hy-8{478}{OnMenuCommand} definition intercepts menu commands for the main
frame. If the option chosen is \hy-8{479}{Quit}, the application terminates by
deleting the main frame. Normally any other existing frames should be
deleted (subframes are deleted automatically); these calls are usually put
in the frame's \hy-8{480}{OnClose} handler so that a system-generated \hy-8{481}{
OnClose} event will enable the program to clean itself up first.
System-generated \hy-8{482}{OnClose} events delete the main frame after calling
\hy-8{483}{OnClose}, so this should not be done from within \hy-8{484}{OnClose}.


\hy-10{486}{More advanced features: the \hy-7{487}{hello} demo}

The `Hello wxWindows' demo (source files, \hy-14{488}{hello.cc} and \hy-14{489}{hello.h})
shows off some more wxWindows features.  When run, two windows pop up.
One is the `main window', with two subwindows - a panel containing
various `widgets', and a text window.  The other contains a canvas,
drawing some simple shapes, and allowing the user to doodle on it by
dragging with the left mouse button.  The canvas contents can be
scaled and printed out, either to a printer supported by Windows or to
PostScript, writing to a file or invoking the printer directly. Under
Windows, the graphic may be copied to the clipboard as a metafile.

Both frames can be resized, and the subwindows will be resized
in an appropriate manner. The text subwindow can be scrolled;
on the panel, a button can be pressed for the program to prompt the user
with text with which to set the status bar. Clicking on the
list box writes a line of text into the text window.

The \hy-8{490}{File} menu has options for selecting the `mapping mode' (logical
dimensions) used in drawing graphics, a zoom option, and an option for
loading a file into the text subwindow using a file selector tool.

The \hy-8{491}{Timer} menu allows the user to switch a timer on and off; when on,
some text gets written to the text subwindow every five seconds.

The \hy-8{492}{Cursor} menu enables the canvas cursor to be changed, and lets
the potential wxWindows programmer view the available standard cursors.

The \hy-8{493}{About} option of the Help menu pops up a dialog box with some
information.

This represents a fair amount of GUI functionality for a relatively
small program. This is because wxWindows calls are high level (creating
a working text window is a single call) and because an object-oriented
approach is taken, where much default functionality is provided.

Note also the lack of explicit coordinates or sizes in the panel item
creation calls. This is the preferred approach, leaving wxWindows to lay
out the items from left to right and top to bottom, with the user
interjecting the occasional \hy-8{494}{NewLine} call.  Explicit positioning is
not recommended since it is less device independent, but can be achieved
by using more parameters to the creation calls, or by using \hy-8{495}{
SetSize} after an item has been created.  Coordinates and sizes default
to -1, which tells wxWindows to choose appropriate positioning and
sizing.  In this example, the windows are explicitly sized, but you may
size a frame or panel to fit around its contents by calling \hy-8{496}{Fit}.

\hy-8{497}{MyFrame's} \hy-8{498}{OnSize} member sizes each subwindow in proportion
to the new size of the frame. \hy-8{499}{MyCanvas's} \hy-8{500}{OnPaint} draws a
couple of lines, a rectangle and a spline whenever the canvas requires
repainting (e.g. on creation, and when exposed). The \hy-8{501}{OnEvent}
member checks for mouse dragging, and draws a line from the last point
to the current position.  Scrolling the canvas and subsequent
repainting is handled automatically by wxWindows.

Finally, two callback functions demonstrate popping up dialog boxes,
setting the status line, and inserting text into a text window.

This demo can provide a template for your own application.
Gradually modify it for your own needs, and you will rapidly be
writing portable X and Windows 3.1 programs!


\hy-10{503}{The MDI demo}

As explained in the manual (see \hy-13{504}{MDI versus SDI}), wxWindows takes an
automated view of Microsoft Windows's MDI (Multiple Document Interface)
since it is a very platform-specific feature. The special MDI `Window'
menu, allowing the user to switch between child windows, is provided
automatically, though without any accelerators and without a choice of
position. Also, instead of deriving frames from distinct classes for MDI
versus SDI, the approach taken in Microsoft's class library, wxWindows
uses an option in the frame constructor to switch between styles. This
allows the programmer to delay the MDI/SDI decision, perhaps even
providing a command-line switch to let the user decide.

The \hy-8{505}{mdi} example program shows this run-time switching. Invoked
without a command line switch, it defaults to SDI. Invoked with the
switch \hy-14{506}{-mdi} it runs as an MDI program, but only under Windows 3.1.

There are a few extra considerations when programming an MDI
applications. One is the choice of menu items. An SDI program might have
a main window and several child windows, where the main window menu has
options for quitting the program and other global matters, while child
window menus have child-specific options. In MDI, the child window menu
visually replaces the main window menu when activated, and so it must
duplicate some main window menu options. One solution is to
include logic to add extra menu items depending on whether MDI or
SDI is specified, as the \hy-8{507}{mdi} example does.

Also, for programs which must be both SDI and MDI (on non-Windows 3.1
platforms SDI mode is mandatory), the main window must not have
subwindows (i.e. panels, canvases or text subwindows) since the client
area may be occupied with child MDI windows under Windows 3.1.

MDI icons pose a small technical difficulty, in that for some reason it
is not possible to use the same technique of dynamically painting the
icon onto the iconized frame client area as with SDI frames.
Consequently the programmer must insert some lines into the resource
file for providing icons (see mdi.rc) as well as using the SetIcon call
in the program for non-Windows 3.1 platforms. Only one icon image for child
MDI frames may be provided.


\hy-10{509}{The IPC demo}

The demo in the \hy-14{510}{directory samples/ipc} shows how processes
may easily talks to each other synchronously (i.e. when A sends a message
to B, A waits for an answer). If you start \hy-14{511}{server}, then \hy-14{512}{client},
a new window should appear on top of the server window, which represents
the connection between server and client. Quitting the client causes
the connection to be broken and this window to disappear.

To illustrate `hot linking', click on the server's listbox. This sends
an \hy-7{513}{advise} message to the client, telling it to update its own
listbox. The reverse is not true, however.

A client may request information from the server. Select the \hy-8{514}{Request}
menu item from the client's \hy-8{515}{File} menu. The window which pops up
is created by the client and contains a message that the server sent back.

Selecting \hy-8{516}{Execute} from the client's menu makes the server pop up a window.
Normally this would execute some command that the client wishes the server to run.

The \hy-8{517}{Poke} menu item sends a \hy-7{518}{poke} message to the server; normally
this would insert some data into the server's memory.

Interprocess communication in wxWindows uses a subset of DDE (Dynamic Data Exchange)
which is Microsoft's standard for low-level IPC under Windows. wxWindows
gives you DDE under UNIX as well as Windows, and makes it easier to program
into the bargain by using an intuitive object-oriented model of communication.



\hy-10{588}{wxApp::wxApp}

\hy-8{589}{void wxApp(int \hy-8{590}{ language = wxLANGUAGE_ENGLISH})}

Constructor. Called implicitly with a definition of a wxApp object.

The argument is a language identifier; this is an experimental
feature and will be expanded and documented in future versions.


\hy-10{592}{wxApp::~wxApp}

\hy-8{593}{void ~wxApp(void)}

Destructor. Will be called implicitly on program exit if the wxApp
object is created on the stack.


\hy-10{595}{wxApp::argc}

\hy-8{596}{int argc}

Number of command line arguments (after environment-specific processing).


\hy-10{598}{wxApp::argv}

\hy-8{599}{char ** argv}

Command line arguments (after environment-specific processing).


\hy-10{601}{wxApp::wx_class}

\hy-8{602}{char * wx_class}

Currently used under Motif only, where the value is passed to \hy-7{603}{
XtOpenDisplay} on initialization. Set this member in the constructor of
your derived \hy-8{604}{wxApp} class to give the application a name other than
the default \hy-7{605}{``wxApp''}.


\hy-10{607}{wxApp::Initialized}

\hy-8{608}{Bool Initialized(void)}

Returns TRUE if the application has been initialized (i.e. if
\hy-13{609}{OnInit} has returned successfully).  This can be useful for error
message routines to determine which method of output is best for the
current state of the program (some windowing systems may not like
dialogs to pop up before the main loop has been entered).


\hy-10{611}{wxApp::MainLoop}

\hy-8{612}{void MainLoop(void)}

Called by wxWindows on creation of the application. Override this if you wish
to provide your own (environment-dependent) main loop.


\hy-10{614}{wxApp::OnExit}

\hy-8{615}{void OnExit(void)}

Provide this member function for any processing which needs to be done as
the application is about to exit.


\hy-10{617}{wxApp::OnInit}

\hy-8{618}{wxFrame * OnInit(void)}

This must be provided by the application, and must create and return the
application's main window.


\hy-10{628}{wxBitmap::wxBitmap}

\hy-8{629}{void wxBitmap(char \hy-8{630}{ bits[]}, int \hy-8{631}{ width}, int \hy-8{632}{ height}

  int \hy-8{633}{ depth = 1})}

Constructs a (usually monochrome) bitmap from an X bitmap file (XBM).

\hy-8{634}{void wxBitmap(int \hy-8{635}{ width}, int \hy-8{636}{ height} int \hy-8{637}{ depth = -1})}

Constructs a new bitmap. If the final argument is omitted, the display depth of
the screen is used.

\hy-8{638}{void wxBitmap(char * \hy-8{639}{ icon_name})}

Constructs a bitmap by passing a string name. \hy-7{640}{icon_name} refers
to an XBM filename in X, a resource name in Windows 3.


\hy-10{642}{wxBitmap::~wxBitmap}

\hy-8{643}{void ~wxBitmap(void)}

Destroys the bitmap. The bitmap will be destroyed automatically by wxWindows
when the application exits.


\hy-10{645}{wxBitmap::GetDepth}

\hy-8{646}{int GetDepth(void)}

Gets the colour depth of the bitmap. A value of 1 indicates a
monochrome bitmap.


\hy-10{648}{wxBitmap::GetHeight}

\hy-8{649}{int GetHeight(void)}

Gets the height of the bitmap in pixels.


\hy-10{651}{wxBitmap::GetWidth}

\hy-8{652}{int GetWidth(void)}

Gets the width of the bitmap in pixels.


\hy-10{654}{wxBitmap::Ok}

\hy-8{655}{Bool Ok(void)}

Returns TRUE if the bitmap was successfully created.


\hy-10{666}{wxBrush::wxBrush}

\hy-8{667}{void wxBrush(void)}

\hy-8{668}{void wxBrush(wxColour & \hy-8{669}{colour}, int \hy-8{670}{ style})}

\hy-8{671}{void wxBrush(char * \hy-8{672}{colour_name}, int \hy-8{673}{ style})}

Constructs a brush: uninitialized, initialized with an RGB colour and
a style, or initialized using a colour name and a style.  If the named
colour form is used, an appropriate \hy-13{674}{wxColour} structure is found
in the colour database.


\hy-10{676}{wxBrush::~wxBrush}

\hy-8{677}{void ~wxBrush(void)}

Destructor, destroying the brush. Note that brushes should very rarely
be deleted since windows may contain pointers to them. All brushes
will be deleted when the application terminates.


\hy-10{679}{wxBrush::GetColour}

\hy-8{680}{wxColour& GetColour(void)}

Returns a reference to the brush colour.


\hy-10{682}{wxBrush::GetStyle}

\hy-8{683}{int GetStyle(void)}

Returns the brush style (wxSOLID or wxTRANSPARENT).


\hy-10{685}{wxBrush::SetColour}

\hy-8{686}{void SetColour(wxColour & \hy-8{687}{colour})}

\hy-8{688}{void SetColour(char * \hy-8{689}{colour_name})}

\hy-8{690}{void SetColour(int \hy-8{691}{ red}, int \hy-8{692}{ green}, int \hy-8{693}{ blue})}

The brush's colour is changed to the given colour.


\hy-10{695}{wxBrush::SetStyle}

\hy-8{696}{void SetStyle(int \hy-8{697}{ style})}

Sets the brush style (wxSOLID or wxTRANSPARENT).


\hy-10{703}{wxBrushList::wxBrushList}

\hy-8{704}{void wxBrushList(void)}

Constructor.  The application should not construct its own brush list:
use the object pointer \hy-8{705}{wxTheBrushList}.


\hy-10{707}{wxBrushList::AddBrush}

\hy-8{708}{void AddBrush(wxBrush * \hy-8{709}{brush})}

Used by wxWindows to add a brush to the list, called in the brush constructor.


\hy-10{711}{wxBrushList::FindOrCreateBrush}

\hy-8{712}{wxBrush * FindOrCreateBrush(wxColour * \hy-8{713}{colour}, int \hy-8{714}{ style})}

\hy-8{715}{wxBrush * FindOrCreateBrush(char * \hy-8{716}{colour_name}, int \hy-8{717}{ style})}

Finds a brush of the given specification, or creates one and adds it to the list.


\hy-10{719}{wxBrushList::RemoveBrush}

\hy-8{720}{void RemoveBrush(wxBrush * \hy-8{721}{brush})}

Used by wxWindows to remove a brush from the list.


\hy-10{728}{wxButton::wxButton}

\hy-8{729}{void wxButton(wxPanel * \hy-8{730}{parent}, wxFunction \hy-8{731}{ func}, char * \hy-8{732}{label},

  int \hy-8{733}{ x = -1}, int \hy-8{734}{ y = -1}, int \hy-8{735}{ width = -1}, int \hy-8{736}{ height = -1},

  int \hy-8{737}{ style = 0}, char * \hy-8{738}{name = ``button"})}

\hy-8{739}{void wxButton(wxPanel * \hy-8{740}{parent}, wxFunction \hy-8{741}{ func}, wxBitmap * \hy-8{742}{wxBitmap},

  int \hy-8{743}{ x = -1}, int \hy-8{744}{ y = -1}, int \hy-8{745}{ width = -1}, int \hy-8{746}{ height = -1},

  int \hy-8{747}{ style = 0}, char * \hy-8{748}{name = ``button"})}

Constructor, creating and showing a button. The parent must be a valid
panel or dialog box pointer.

\hy-7{749}{func} may be NULL; otherwise it is used as the callback for the
button.  Note that the cast (wxFunction) must be used when passing your
callback function name, or the compiler may complain that the function
does not match the constructor declaration. See \hy-13{750}{wxFunction}.

The parameters \hy-7{751}{x} and \hy-7{752}{y} are used to specify an absolute
position, or a position after the previous panel item if omitted or
default.

If \hy-7{753}{width} or \hy-7{754}{height} are omitted (or are less than zero), an
appropriate size will be used for the item.  The \hy-7{755}{style} parameter
is reserved for future use. The \hy-7{756}{name} parameter is used to associate
a name with the item, allowing the application user to set Motif resource values
for individual buttons.

If the first form is used, the \hy-7{757}{label} will be shown on the button.
If the seond form is used, the \hy-7{758}{bitmap} will be used.


\hy-10{760}{wxButton::~wxButton}

\hy-8{761}{void ~wxButton(void)}

Destructor, destroying the button.


\hy-10{763}{wxButton::Create}

\hy-8{764}{void Create(wxPanel * \hy-8{765}{parent}, wxFunction \hy-8{766}{ func}, char * \hy-8{767}{label},

  int \hy-8{768}{ x = -1}, int \hy-8{769}{ y = -1}, int \hy-8{770}{ width = -1}, int \hy-8{771}{ height = -1},

  int \hy-8{772}{ style = 0}, char * \hy-8{773}{name = ``button"})}

\hy-8{774}{void Create(wxPanel * \hy-8{775}{parent}, wxFunction \hy-8{776}{ func}, wxBitmap * \hy-8{777}{wxBitmap},

  int \hy-8{778}{ x = -1}, int \hy-8{779}{ y = -1}, int \hy-8{780}{ width = -1}, int \hy-8{781}{ height = -1},

  int \hy-8{782}{ style = 0}, char * \hy-8{783}{name = ``button"})}

Button creation functions called by the button constructors. Call these
when a derived button class uses the zero-argument \hy-8{784}{wxButton}
constructor, but can reuse the existing button creation code.
See \hy-13{785}{wxButton::wxButton} for details.


\hy-10{787}{wxButton::SetDefault}

\hy-8{788}{void SetDefault(void)}

This sets the button to be the default item for the panel or dialog
box.  Under XView, the default item is highlighted, and pressing the
return key executes the callback for the item (but with no visual
feedback, and only if a text item does not have the focus).

Under Windows 3, only dialog box buttons respond to this function.  As
normal under Windows 3 and Motif, pressing return causes the default button to
be depressed when the return key is pressed. See also \hy-13{789}{wxWindow::SetFocus}
which sets the keyboard focus for windows and text panel items, \hy-13{790}{wxPanel::OnDefaultAction}
and \hy-13{791}{wxPanel::GetDefaultItem}.


\hy-10{793}{wxButton::SetLabel}

\hy-8{794}{void SetLabel(wxBitmap * \hy-8{795}{label})}

Sets the bitmap for a bitmap button.


\hy-10{806}{wxCanvas::wxCanvas}

\hy-8{807}{void wxCanvas(wxFrame * \hy-8{808}{parent}, int \hy-8{809}{ x = -1}, int \hy-8{810}{ y = -1},

  int \hy-8{811}{ width = -1}, int \hy-8{812}{ height = -1},

  int \hy-8{813}{ style = wxRETAINED}, char * \hy-8{814}{name})}

Constructor.

The parameters \hy-7{815}{x}, \hy-7{816}{y}, \hy-7{817}{width} and \hy-7{818}{height}
can be omitted on construction if the position and size will later
be set (for example by a application frame's \hy-8{819}{OnSize} callback,
or if there is only one subwindow for the frame, in which case the
subwindow fills the frame).

The style parameter may be a combination (using the C++
bitwise `or' operator) of the following flags:


\hy-8{820}{o}  wxBORDER, to give the canvas a thin border (Windows 3 and Motif only).
\hy-8{821}{o}  wxRETAINED, to give the canvas a backing store, making repainting much faster but
at a memory premium (XView and Motif only).


The \hy-7{822}{name} parameter is used to associate a name with the canvas,
allowing the application user to set Motif resources for individual
canvases.


\hy-10{824}{wxCanvas::~wxCanvas}

\hy-8{825}{void ~wxCanvas(void)}

Destructor.


\hy-10{827}{wxCanvas::Create}

\hy-8{828}{void Create(wxFrame * \hy-8{829}{parent}, int \hy-8{830}{ x = -1}, int \hy-8{831}{ y = -1},

  int \hy-8{832}{ width = -1}, int \hy-8{833}{ height = -1},

  int \hy-8{834}{ style = wxRETAINED}, char * \hy-8{835}{name})}

Creates the canvas for two-step construction. Derived classes
should call or replace this function. See \hy-13{836}{wxCanvas::wxCanvas}
for details.


\hy-10{838}{wxCanvas::Clear}

\hy-8{839}{void Clear(void)}

Clears the canvas (fills it with the current background brush).


\hy-10{841}{wxCanvas::DestroyClippingRegion}

\hy-8{842}{void DestroyClippingRegion(void)}

Destroys the current clipping region so that none of the canvas is clipped.


\hy-10{844}{wxCanvas::DrawArc}

\hy-8{845}{void DrawArc(float \hy-8{846}{ x1}, float \hy-8{847}{ y1}, float \hy-8{848}{ x2}, float \hy-8{849}{ y2}, float \hy-8{850}{xc}, float \hy-8{851}{yc})}

Draws an arc, centred on (\hy-7{852}{xc, yc}), with starting point (\hy-7{853}{x1, y1})
and ending at (\hy-7{854}{x2, y2}).   The current pen is used for the outline
and the current brush for filling the shape.


\hy-10{856}{wxCanvas::DrawEllipse}

\hy-8{857}{void DrawEllipse(float \hy-8{858}{ x}, float \hy-8{859}{ y}, float \hy-8{860}{ width},
float \hy-8{861}{ height})}

Draws an ellipse contained in the rectangle with the given top left
corner, and with the given size.  The current pen is used for the
outline and the current brush for filling the shape.


\hy-10{863}{wxCanvas::DrawLine}

\hy-8{864}{void DrawLine(float \hy-8{865}{ x1}, float \hy-8{866}{ y1}, float \hy-8{867}{ x2},
float \hy-8{868}{ y2})}

Draws a line from the first point to the second. The current pen is
used for drawing the line.


\hy-10{870}{wxCanvas::DrawLines}

\hy-8{871}{void DrawLines(int \hy-8{872}{ n}, wxPoint \hy-8{873}{ points[]}, float \hy-8{874}{ xoffset = 0}, float \hy-8{875}{ yoffset = 0})}

\hy-8{876}{void DrawLines(wxList * \hy-8{877}{points}, float \hy-8{878}{ xoffset = 0}, float \hy-8{879}{ yoffset = 0})}

Draw lines using an array of \hy-7{880}{points} of size \hy-7{881}{n}, or list of
pointers to points, adding the optional offset coordinate. The current
pen is used for drawing the lines.  The programmer is responsible for
deleting the list of points.


\hy-10{883}{wxCanvas::DrawPolygon}

\hy-8{884}{void DrawPolygon(int \hy-8{885}{ n}, wxPoint \hy-8{886}{ points[]}, float \hy-8{887}{ xoffset = 0}, float \hy-8{888}{ yoffset = 0})}

\hy-8{889}{void DrawPolygon(wxList * \hy-8{890}{points}, float \hy-8{891}{ xoffset = 0},
float \hy-8{892}{ yoffset = 0})}

Draw a filled polygon using an array of \hy-7{893}{points} of size \hy-7{894}{n},
or list of pointers to points, adding the optional offset coordinate.
The current pen is used for drawing the outline, and the current brush
for filling the shape.  Using a transparent brush suppresses filling.
The programmer is responsible for deleting the list of points.

Note that wxWindows automatically closes the first and last points.


\hy-10{896}{wxCanvas::DrawPoint}

\hy-8{897}{void DrawPoint(float \hy-8{898}{ x}, float \hy-8{899}{ y})}

Draws a point using the current pen.


\hy-10{901}{wxCanvas::DrawRectangle}

\hy-8{902}{void DrawRectangle(float \hy-8{903}{ x}, float \hy-8{904}{ y}, float \hy-8{905}{ width}, float \hy-8{906}{ height})}

Draws a rectangle with the given top left corner, and with the given
size.  The current pen is used for the outline and the current brush for
filling the shape.


\hy-10{908}{wxCanvas::DrawRoundedRectangle}

\hy-8{909}{void DrawRoundedRectangle(float \hy-8{910}{ x}, float \hy-8{911}{ y}, float \hy-8{912}{ width},
  float \hy-8{913}{ height}, float \hy-8{914}{ radius = 20})}

Draws a rectangle with the given top left corner, and with the given
size.  The corners are quarter-circles using the given radius. The
current pen is used for the outline and the current brush for filling
the shape.


\hy-10{916}{wxCanvas::DrawSpline}

\hy-8{917}{void DrawSpline(wxList * \hy-8{918}{points})}

Draws a spline between all given control points, using the current
pen.  Doesn't delete the wxList and contents. The spline is drawn
using a series of lines, using an algorithm taken from the X drawing
program `XFIG'.

\hy-8{919}{void DrawSpline(float \hy-8{920}{ x1}, float \hy-8{921}{ y1}, float \hy-8{922}{ x2}, float \hy-8{923}{ y2},
  float \hy-8{924}{ x3}, float \hy-8{925}{ y3})}

Draws a three-point spline using the current pen.


\hy-10{927}{wxCanvas::DrawText}

\hy-8{928}{void DrawText(char * \hy-8{929}{text}, float \hy-8{930}{ x}, float \hy-8{931}{ y})}

Draws a text string at the specified point, using the current text font,
and the current text foreground and background colours.


\hy-10{933}{wxCanvas::EnableScrolling}

\hy-8{934}{void EnableScrolling(Bool \hy-8{935}{ xScrolling}, Bool \hy-8{936}{ yScrolling})}

Enable or disable Windows scrolling in the given direction, where in
this context scrolling is the physical transfer of bits up or down the
screen when a scroll event occurs. If the application scrolls by a
variable amount (e.g. if there are different font sizes) then physical
scrolling messes up the display.


\hy-10{938}{wxCanvas::GetDC}

\hy-8{939}{wxCanvasDC * GetDC(void)}

Get a pointer to the canvas's device context. See \hy-13{940}{wxDC}
and \hy-13{941}{wxCanvasDC}.


\hy-10{943}{wxCanvas::GetScrollUnitsPerPage}

\hy-8{944}{void GetScrollUnitsPerPage(int * \hy-8{945}{x_page}, int * \hy-8{946}{y_page})}

Get the number of units per page, in each direction, as set
by \hy-13{947}{wxCanvas::SetScrollbars}. A value of zero indicates no
scrolling in that direction.


\hy-10{949}{wxCanvas::GetVirtualSize}

\hy-8{950}{void GetVirtualSize(int * \hy-8{951}{x}, int * \hy-8{952}{y})}

Gets the size in device units of the scrollable canvas area (as
opposed to the client size, which is the area of the canvas currently
visible).

Use \hy-13{953}{wxDC::DeviceToLogicalX} and \hy-13{954}{wxDC::DeviceToLogicalY}
to translate these units to logical units.


\hy-10{956}{wxCanvas::IsRetained}

\hy-8{957}{Bool IsRetained(void)}

TRUE if the canvas has a backing bitmap.


\hy-10{959}{wxCanvas::OnChar}

\hy-8{960}{void OnChar(wxKeyEvent&  \hy-8{961}{event})}

This default handler interprets cursor key movement and scrolls the
canvas accordingly.  Override the function to change this behaviour
(see \hy-13{962}{wxWindow::OnChar} for details).


\hy-10{964}{wxCanvas::OnEvent}

\hy-8{965}{void OnEvent(wxMouseEvent& \hy-8{966}{ event})}

Sent to the canvas when the user has initiated an event with the mouse.
Derive your own class to handle this message. See \hy-13{967}{wxCanvas::OnChar}
for character events, and also \hy-13{968}{wxMouseEvent} for how to access
event information.


\hy-10{970}{wxCanvas::OnPaint}

\hy-8{971}{void OnPaint(void)}

Sent to the canvas when the canvas must be refreshed. Derive your own
class to handle this message.


\hy-10{973}{wxCanvas::Scroll}

\hy-8{974}{void Scroll(int \hy-8{975}{ x_pos}, int \hy-8{976}{ y_pos})}

Scrolls a canvas so the view start is at the given point. The
positions are in scroll units, not pixels, so to convert to pixels you
will have to multiply by the number of pixels per scroll increment.
If either parameter is -1, that position will be ignored (no change in
that direction).

See also \hy-13{977}{wxCanvas::SetScrollbars}.


\hy-10{979}{wxCanvas::SetBackground}

\hy-8{980}{void SetBackground(wxBrush * \hy-8{981}{brush})}

Sets the current background brush for the canvas, used for the pixels
between dotted or dashed lines.  The brush should not be deleted while
being used by a canvas. All brushes are deleted automatically when the
application terminates.

See also \hy-13{982}{wxBrush}.


\hy-10{984}{wxCanvas::SetClippingRegion}

\hy-8{985}{void SetClippingRegion(float \hy-8{986}{ x}, float \hy-8{987}{ y}, float \hy-8{988}{ width}, float \hy-8{989}{ height})}

Sets the clipping region for the canvas. The clipping region is a
rectangular area to which drawing is restricted.  Possible uses for
the clipping region are for clipping text or for speeding up canvas
redraws when only a known area of the screen is damaged.

See also \hy-13{990}{wxCanvas::DestroyClippingRegion}.


\hy-10{992}{wxCanvas::SetBrush}

\hy-8{993}{void SetBrush(wxBrush * \hy-8{994}{brush})}

Sets the current brush for the canvas.  The brush is not copied, so
you should not delete the brush unless the canvas pen has been set to
another brush, or to NULL. Note that all pens and brushes are
automatically deleted when the program is exited.

See also \hy-13{995}{wxBrush}.


\hy-10{997}{wxCanvas::SetFont}

\hy-8{998}{void SetFont(wxFont * \hy-8{999}{font})}

Sets the current font for the canvas. The font is not copied, so you
should not delete the font unless the canvas pen has been set to
another font, or to NULL.

See also \hy-13{1000}{wxFont}, \hy-13{1001}{wxCanvas::DrawText}.


\hy-10{1003}{wxCanvas::SetLogicalFunction}

\hy-8{1004}{void SetLogicalFunction(int \hy-8{1005}{ function})}

Sets the current logical function for the canvas.  This determines how
a source pixel (from a pen or brush colour, or source device context if using \hy-13{1006}{wxDC::Blit})
combines with a destination pixel in the current device context.

The possible values
and their meaning in terms of source and destination pixel values are
as follows:

\hy-14{1007}{wxAND                 src AND dst
wxAND_INVERT          (NOT src) AND dst
wxAND_REVERSE         src AND (NOT dst)
wxCLEAR               0
wxCOPY                src
wxEQUIV               (NOT src) XOR dst
wxINVERT              NOT dst
wxNAND                (NOT src) OR (NOT dst)
wxNOR                 (NOT src) AND (NOT dst)
wxNO_OP               dst
wxOR                  src OR dst
wxOR_INVERT           (NOT src) OR dst
wxOR_REVERSE          src OR (NOT dst)
wxSET                 1
wxSRC_INVERT          NOT src
wxXOR                 src XOR dst
}

The default is wxCOPY, which simply draws with the current colour.
The others combine the current colour and the background using a
logical operation.  wxXOR is commonly used for drawing rubber bands or
moving outlines, since drawing twice reverts to the original colour.


\hy-10{1009}{wxCanvas::SetPen}

\hy-8{1010}{void SetPen(wxPen * \hy-8{1011}{pen})}

Sets the current pen for the canvas.  The pen is not copied, so you
should not delete the pen unless the canvas pen has been set to
another pen, or to NULL. Note that all pens and brushes are
automatically deleted when the program is exited.

See also \hy-13{1012}{wxPen}.


\hy-10{1014}{wxCanvas::SetScrollbars}

\hy-8{1015}{void SetScrollbars(int \hy-8{1016}{ horiz_pixels}, int \hy-8{1017}{ vert_pixels}, int \hy-8{1018}{ x_length}, int \hy-8{1019}{ y_length},

  int  \hy-8{1020}{x_page}, int \hy-8{1021}{ y_page}, int  \hy-8{1022}{x_pos = 0}, int \hy-8{1023}{ y_pos = 0})}

Sets up vertical and/or horizontal scrollbars. The first pair of
parameters give the number of pixels per `scroll step', i.e. amount
moved when the up or down scroll arrows are pressed. These may be 0 or
less for no scrollbar. The second pair gives the length of scrollbar
in scroll steps, which effectively sets the size of the `virtual
canvas'.  The third pair gives the number of scroll steps in a `page',
i.e. amount moved when pressing above or below the scrollbar control,
or using page up/page down.

\hy-7{1024}{x_pos} and \hy-7{1025}{y_pos} optionally specify a position to scroll to immediately.

For example, the following gives a canvas horizontal and vertical
scrollbars with 20 pixels per scroll step, a size of 50 steps (1000
pixels) in each direction, and 4 steps (80 pixels) to a page.

\hy-14{1026}{canvas->SetScrollbars(20, 20, 50, 50, 4, 4);
}

See also \hy-13{1027}{wxCanvas::EnableScrolling},
\hy-13{1028}{wxCanvas::GetScrollUnitsPerPage}, \hy-13{1029}{wxCanvas::GetVirtualSize}.


\hy-10{1031}{wxCanvas::SetTextBackground}

\hy-8{1032}{void SetTextBackground(wxColour * \hy-8{1033}{colour})}

Sets the current text background colour for the canvas.  Do not
delete \hy-7{1034}{colour}. See also \hy-13{1035}{wxCanvas::SetTextForeground}.


\hy-10{1037}{wxCanvas::SetTextForeground}

\hy-8{1038}{void SetTextForeground(wxColour * \hy-8{1039}{colour})}

Sets the current text foreground colour for the canvas. Do not
delete \hy-7{1040}{colour}.  See also \hy-13{1041}{wxCanvas::SetTextBackground}.


\hy-10{1043}{wxCanvas::ViewStart}

\hy-8{1044}{void ViewStart(int * \hy-8{1045}{x}, int * \hy-8{1046}{ y})}

Get the position at which the visible portion of the canvas starts. If
either of the scrollbars is not at the home position, \hy-7{1047}{x} and/or
\hy-7{1048}{y} will be greater than zero.  Combined with \hy-13{1049}{wxWindow::GetClientSize},
the application can use this function to efficiently redraw only the
visible portion of the canvas.  The positions are in logical scroll
units, not pixels, so to convert to pixels you will have to multiply
by the number of pixels per scroll increment.

See also \hy-13{1050}{wxCanvas::SetScrollbars}.


\hy-10{1052}{wxCanvas::WarpPointer}

\hy-8{1053}{void WarpPointer(int \hy-8{1054}{ x}, int \hy-8{1055}{ y})}

Moves the pointer to the given position on the canvas.


\hy-10{1061}{wxCanvasDC::wxCanvasDC}

\hy-8{1062}{void wxCanvasDC(wxCanvas * \hy-8{1063}{canvas})}

Constructor for internal use only.


\hy-10{1067}{wxCheckBox::wxCheckBox}

\hy-8{1068}{void wxCheckBox(void)}

Constructor, used when deriving from this class.

\hy-8{1069}{void wxCheckBox(wxPanel * \hy-8{1070}{parent}, wxFunction \hy-8{1071}{ func},
  char * \hy-8{1072}{label}, 
int \hy-8{1073}{ x = -1}, int \hy-8{1074}{ y = -1},
  int \hy-8{1075}{ width = -1}, int \hy-8{1076}{ height = -1},

  int \hy-8{1077}{ style = 0}, char * \hy-8{1078}{name = ``checkBox"})}

\hy-8{1079}{void wxCheckBox(wxPanel * \hy-8{1080}{parent}, wxFunction \hy-8{1081}{ func},
  wxBitmap * \hy-8{1082}{bitmap}, 
int \hy-8{1083}{ x = -1}, int \hy-8{1084}{ y = -1},
  int \hy-8{1085}{ width = -1}, int \hy-8{1086}{ height = -1},

  int \hy-8{1087}{ style = 0}, char * \hy-8{1088}{name = ``checkBox"})}

Constructor, creating and showing a checkbox.

\hy-7{1089}{func} may be NULL; otherwise it is used as the callback for the
check box.  Note that the cast (wxFunction) must be used when passing
your callback function name, or the compiler may complain that the
function does not match the constructor declaration.

In the second form, if \hy-7{1090}{label} is non-NULL, it is used as the label
for the checkbox. In the third form, a bitmap is provided instead of
a text label.

The parameters \hy-7{1091}{x} and \hy-7{1092}{y} are used to specify an absolute
position, or a position after the previous panel item if omitted or
default.

If \hy-7{1093}{width} or \hy-7{1094}{height} are omitted (or are less than zero), an
appropriate size will be used for the check box.

The \hy-7{1095}{style} parameter is reserved for future use.

The \hy-7{1096}{name} parameter is used to associate a name with the item,
allowing the application user to set Motif resource values for
individual checkboxes.


\hy-10{1098}{wxCheckBox::~wxCheckBox}

\hy-8{1099}{void ~wxCheckBox(void)}

Destructor, destroying the checkbox.


\hy-10{1101}{wxCheckBox::Create}

\hy-8{1102}{Bool Create(wxPanel * \hy-8{1103}{parent}, wxFunction \hy-8{1104}{ func},
  char * \hy-8{1105}{label}, 
int \hy-8{1106}{ x = -1}, int \hy-8{1107}{ y = -1},
  int \hy-8{1108}{ width = -1}, int \hy-8{1109}{ height = -1},

  int \hy-8{1110}{ style = 0}, char * \hy-8{1111}{name = ``checkBox"})}

\hy-8{1112}{Bool Create(wxPanel * \hy-8{1113}{parent}, wxFunction \hy-8{1114}{ func},
  char * \hy-8{1115}{bitmap}, 
int \hy-8{1116}{ x = -1}, int \hy-8{1117}{ y = -1},
  int \hy-8{1118}{ width = -1}, int \hy-8{1119}{ height = -1},

  int \hy-8{1120}{ style = 0}, char * \hy-8{1121}{name = ``checkBox"})}

Creates the checkbox for two-step construction. Derived classes
should call or replace this function. See \hy-13{1122}{wxCheckBox::wxCheckBox}
for details.


\hy-10{1124}{wxCheckBox::GetValue}

\hy-8{1125}{Bool GetValue(void)}

Gets the state of the checkbox, TRUE if it is checked, FALSE otherwise.


\hy-10{1127}{wxCheckBox::SetLabel}

\hy-8{1128}{void SetLabel(wxBitmap * \hy-8{1129}{label})}

Sets the bitmap for a bitmap checkbox.


\hy-10{1131}{wxCheckBox::SetValue}

\hy-8{1132}{void SetValue(Bool \hy-8{1133}{ state})}

Sets the checkbox to the given state: if the state is TRUE, the check is on,
otherwise it is off.



\hy-10{1138}{wxChoice::wxChoice}

\hy-8{1139}{void wxChoice(void)}

Constructor, for use by derived classes.

\hy-8{1140}{void wxChoice(wxPanel * \hy-8{1141}{parent}, wxFunction \hy-8{1142}{ func},
  char * \hy-8{1143}{label}, 
int \hy-8{1144}{ x = -1}, int \hy-8{1145}{ y = -1}, int \hy-8{1146}{ width = -1},
  int \hy-8{1147}{ height = -1}, 
int \hy-8{1148}{ n}, char * \hy-8{1149}{choices[]},

  int \hy-8{1150}{ style = 0}, char * \hy-8{1151}{name = ``choice"})}

Constructor, creating and showing a choice. 

\hy-7{1152}{func} may be NULL; otherwise it is used as the callback for the
choice.  Note that the cast (wxFunction) must be used when passing your
callback function name, or the compiler may complain that the function
does not match the constructor declaration.

If \hy-7{1153}{label} is non-NULL, it is used as the label for the choice item.

The parameters \hy-7{1154}{x} and \hy-7{1155}{y} are used to specify an absolute
position, or a position after the previous panel item if omitted or
default.

If \hy-7{1156}{width} or \hy-7{1157}{height} are omitted (or are less than zero), an
appropriate size will be used for the choice.

\hy-7{1158}{n} is the number of possible choices, and \hy-7{1159}{choices} is an
array of strings of size \hy-7{1160}{n}. wxWindows allocates its own memory
for these strings so the calling program must deallocate the array
itself.

The \hy-7{1161}{style} parameter is reserved for future use.

The \hy-7{1162}{name} parameter is used to associate a name with the item,
allowing the application user to set Motif resource values for
individual choice items.


\hy-10{1164}{wxChoice::~wxChoice}

\hy-8{1165}{void ~wxChoice(void)}

Destructor, destroying the choice item.


\hy-10{1167}{wxChoice::Append}

\hy-8{1168}{void Append(char * \hy-8{1169}{ item})}

Adds the item to the end of the choice item. \hy-7{1170}{item} must be
deallocated by the calling program, i.e. wxWindows makes its own copy.


\hy-10{1172}{wxChoice::Clear}

\hy-8{1173}{void Clear(void)}

Clears the strings from the choice item. Under XView, this is done
by deleting and reconstructing the item, but it doesn't redisplay
properly until the user refreshes the window.


\hy-10{1175}{wxChoice::Create}

\hy-8{1176}{Bool Create(wxPanel * \hy-8{1177}{parent}, wxFunction \hy-8{1178}{ func},
  char * \hy-8{1179}{label}, 
int \hy-8{1180}{ x = -1}, int \hy-8{1181}{ y = -1}, int \hy-8{1182}{ width = -1},
  int \hy-8{1183}{ height = -1}, int \hy-8{1184}{ n}, char * \hy-8{1185}{choices[]}

  int \hy-8{1186}{ style = 0}, char * \hy-8{1187}{name = ``choice"})}

Creates the choice for two-step construction. Derived classes
should call or replace this function. See \hy-13{1188}{wxChoice::wxChoice}
for further details.


\hy-10{1190}{wxChoice::FindString}

\hy-8{1191}{int FindString(char * \hy-8{1192}{s})}

Finds a choice matching the given string, returning the position if found, or
-1 if not found.


\hy-10{1194}{wxChoice::GetSelection}

\hy-8{1195}{int GetSelection(void)}

Gets the id (position) of the selected string.


\hy-10{1197}{wxChoice::GetStringSelection}

\hy-8{1198}{char * GetStringSelection(void)}

Gets the selected string. This must be copied by the calling program
if long term use is to be made of it.


\hy-10{1200}{wxChoice::SetSelection}

\hy-8{1201}{void SetSelection(int \hy-8{1202}{ n})}

Sets the choice by passing the desired string position. 


\hy-10{1204}{wxChoice::SetStringSelection}

\hy-8{1205}{void SetStringSelection(char * \hy-8{1206}{ s})}

Sets the choice by passing the desired string.


\hy-10{1208}{wxChoice::GetString}

\hy-8{1209}{char * GetString(int \hy-8{1210}{ n})}

Returns a temporary pointer to the string at position \hy-7{1211}{n}.


\hy-10{1228}{wxClient::wxClient}

\hy-8{1229}{void wxClient(void)}

Constructs a client object.


\hy-10{1231}{wxClient::MakeConnection}

\hy-8{1232}{wxConnection * MakeConnection(char * \hy-8{1233}{host}, char * \hy-8{1234}{service}, char * \hy-8{1235}{topic})}

Tries to make a connection with a server specified by the host
(machine name under UNIX, ignored under Windows), service name (must
contain an integer port number under UNIX), and topic string. If the
server allows a connection, a wxConnection object will be returned.
The type of wxConnection returned can be altered by overriding
the \hy-13{1236}{wxClient::OnMakeConnection} member to return your own
derived connection object.


\hy-10{1238}{wxClient::OnMakeConnection}

\hy-8{1239}{wxConnection * OnMakeConnection(void)}

The type of \hy-13{1240}{wxConnection} returned from a \hy-13{1241}{wxClient::MakeConnection} call can
be altered by deriving the \hy-8{1242}{OnMakeConnection} member to return your
own derived connection object. By default, an ordinary wxConnection
object is returned.

The advantage of deriving your own connection class is that it will
enable you to intercept messages initiated by the server, such
as \hy-13{1243}{wxConnection::OnAdvise}. You may also want to
store application-specific data in instances of the new class.


\hy-10{1248}{wxColour::wxColour}

\hy-8{1249}{void wxColour(char \hy-8{1250}{ red}, char \hy-8{1251}{ green}, char \hy-8{1252}{ blue})}

\hy-8{1253}{void wxColour(char * \hy-8{1254}{ colour_name})}

Construct a colour object from the RGB values or using a colour name
(uses \hy-8{1255}{wxTheColourDatabase}).


\hy-10{1257}{wxColour::Get}

\hy-8{1258}{void Get(char * \hy-8{1259}{ red}, char * \hy-8{1260}{ green}, char * \hy-8{1261}{ blue})}

Gets the RGB values---pass pointers to three char variables.


\hy-10{1263}{wxColour::Ok}

\hy-8{1264}{Bool Ok(void)}

Returns TRUE if the colour object is valid.


\hy-10{1266}{wxColour::Set}

\hy-8{1267}{void Set(char \hy-8{1268}{ red}, char \hy-8{1269}{ green}, char \hy-8{1270}{ blue})}

Sets the RGB value.


\hy-10{1277}{wxColourDatabase::wxColourDatabase}

\hy-8{1278}{void wxColourDatabase(void)}

Constructs the colour database.  Should not need to be used by an 
application.


\hy-10{1280}{wxColourDatabase::FindColour}

\hy-8{1281}{wxColour * FindColour(char * \hy-8{1282}{colour_name})}

Finds a colour given the name.  Returns NULL if not found.


\hy-10{1284}{wxColourDatabase::FindName}

\hy-8{1285}{char * FindName(wxColour& \hy-8{1286}{ colour})}

Finds a colour name given the colour. Returns NULL if not found.


\hy-10{1288}{wxColourDatabase::Initialize}

\hy-8{1289}{char * Initialize(void)}

Initializes the database with a number of stock colours.  Called by wxWindows
on start-up.


\hy-10{1293}{wxColourMap::wxColourMap}

\hy-8{1294}{void wxColourMap(void)}

Constructor.


\hy-10{1296}{wxColourMap::~wxColourMap}

\hy-8{1297}{void ~wxColour(void)}

Destructor.


\hy-10{1303}{wxCommandEvent::clientData}

\hy-8{1304}{char * clientData}

Contains a pointer to client data for listboxes and choices, if the event
was a selection.


\hy-10{1306}{wxCommandEvent::commandInt}

\hy-8{1307}{int  commandInt}

Contains an integer identifier corresponding to a listbox, choice or
radiobox selection (only if the event was a selection, not a
deselection), or a Boolean value representing the value of a checkbox.


\hy-10{1309}{wxCommandEvent::commandString}

\hy-8{1310}{char * commandString}

Contains a string corresponding to a listbox or choice selection.


\hy-10{1312}{wxCommandEvent::extraLong}

\hy-8{1313}{long  extraLong}

Extra information. If the event comes from a listbox selection, it is
a Boolean determining whether the event was a selection (TRUE) or a
deselection (FALSE). A listbox deselection only occurs for
multiple-selection boxes, and in this case the index and string values
are indeterminate and the listbox must be examined by the application.


\hy-10{1315}{wxCommandEvent::wxCommandEvent}

\hy-8{1316}{void wxCommandEvent(WXTYPE \hy-8{1317}{ commandEventType})}

Constructor. \hy-7{1318}{commandEventType} may be one of the following:


\hy-8{1319}{o}  \hy-8{1320}{wxEVENT_TYPE_BUTTON_COMMAND}
\hy-8{1321}{o}  \hy-8{1322}{wxEVENT_TYPE_CHECKBOX_COMMAND}
\hy-8{1323}{o}  \hy-8{1324}{wxEVENT_TYPE_CHOICE_COMMAND}
\hy-8{1325}{o}  \hy-8{1326}{wxEVENT_TYPE_LISTBOX_COMMAND}
\hy-8{1327}{o}  \hy-8{1328}{wxEVENT_TYPE_TEXT_COMMAND}
\hy-8{1329}{o}  \hy-8{1330}{wxEVENT_TYPE_MULTITEXT_COMMAND}
\hy-8{1331}{o}  \hy-8{1332}{wxEVENT_TYPE_MENU_COMMAND}
\hy-8{1333}{o}  \hy-8{1334}{wxEVENT_TYPE_SLIDER_COMMAND}
\hy-8{1335}{o}  \hy-8{1336}{wxEVENT_TYPE_RADIOBOX_COMMAND}



\hy-10{1338}{wxCommandEvent::Checked}

\hy-8{1339}{Bool Checked(void)}

Returns TRUE or FALSE for a checkbox selection event.


\hy-10{1341}{wxCommandEvent::GetClientData}

\hy-8{1342}{char * GetClientData(void)}

Returns client data pointer for a listbox or choice selection event
(not valid for a deselection).


\hy-10{1344}{wxCommandEvent::GetSelection}

\hy-8{1345}{int GetSelection(void)}

Returns item index for a listbox or choice selection event (not valid for
a deselection).


\hy-10{1347}{wxCommandEvent::GetString}

\hy-8{1348}{char * GetString(void)}

Returns item string for a listbox or choice selection event (not valid for
a deselection).


\hy-10{1350}{wxCommandEvent::IsSelection}

\hy-8{1351}{Bool IsSelection(void)}

For a listbox or choice event, returns TRUE if it is a selection, FALSE if it
is a deselection.


\hy-10{1360}{wxConnection::wxConnection}

\hy-8{1361}{void wxConnection(void)}

\hy-8{1362}{void wxConnection(char * \hy-8{1363}{buffer}, int \hy-8{1364}{ size})}

Constructs a connection object. If no user-defined connection object is
to be derived from wxConnection, then the constructor should not be
called directly, since the default connection object will be provided on
requesting (or accepting) a connection. However, if the user defines his
or her own derived connection object, the \hy-13{1365}{wxServer::OnAcceptConnection}
and/or \hy-13{1366}{wxClient::OnMakeConnection} members should be replaced by
functions which construct the new connection object. If the arguments of
the wxConnection constructor are void, then a default buffer is
associated with the connection. Otherwise, the programmer must provide a
a buffer and size of the buffer for the connection object to use in
transactions.


\hy-10{1368}{wxConnection::Advise}

\hy-8{1369}{Bool Advise(char * \hy-8{1370}{item}, char * \hy-8{1371}{data}, int \hy-8{1372}{ size = -1}, int \hy-8{1373}{ format = wxCF_TEXT})}

Called by the server application to advise the client of a change in
the data associated with the given item. Causes the client
connection's \hy-13{1374}{wxConnection::OnAdvise}
member to be called. Returns TRUE if successful.


\hy-10{1376}{wxConnection::Execute}

\hy-8{1377}{Bool Execute(char * \hy-8{1378}{data}, int \hy-8{1379}{ size = -1},
int \hy-8{1380}{ format = wxCF_TEXT})}

Called by the client application to execute a command on the server. Can
also be used to transfer arbitrary data to the server (similar
to \hy-13{1381}{wxConnection::Poke} in that respect). Causes the
server connection's \hy-13{1382}{wxConnection::OnExecute} member to be
called. Returns TRUE if successful.


\hy-10{1384}{wxConnection::Disconnect}

\hy-8{1385}{Bool Disconnect(void)}

Called by the client or server application to disconnect from the other
program; it causes the \hy-13{1386}{wxConnection::OnDisconnect} message
to be sent to the corresponding connection object in the other
program. The default behaviour of \hy-8{1387}{OnDisconnect} is to delete the
connection, but the calling application must explicitly delete its
side of the connection having called \hy-8{1388}{Disconnect}. Returns TRUE if
successful.


\hy-10{1390}{wxConnection::OnAdvise}

\hy-8{1391}{Bool OnAdvise(char * \hy-8{1392}{topic}, char * \hy-8{1393}{item}, char * \hy-8{1394}{data}, int \hy-8{1395}{ size}, int \hy-8{1396}{ format})}

Message sent to the client application when the server notifies it of a
change in the data associated with the given item.


\hy-10{1398}{wxConnection::OnDisconnect}

\hy-8{1399}{Bool OnDisconnect(void)}

Message sent to the client or server application when the other
application notifies it to delete the connection. Default behaviour is
to delete the connection object.


\hy-10{1401}{wxConnection::OnExecute}

\hy-8{1402}{Bool OnExecute(char * \hy-8{1403}{topic}, char * \hy-8{1404}{data}, int \hy-8{1405}{ size}, int \hy-8{1406}{ format})}

Message sent to the server application when the client notifies it to
execute the given data. Note that there is no item associated with
this message.


\hy-10{1408}{wxConnection::OnPoke}

\hy-8{1409}{Bool OnPoke(char * \hy-8{1410}{topic}, char * \hy-8{1411}{item}, char * \hy-8{1412}{data}, int \hy-8{1413}{ size}, int \hy-8{1414}{ format})}

Message sent to the server application when the client notifies it to
accept the given data.


\hy-10{1416}{wxConnection::OnRequest}

\hy-8{1417}{char * OnRequest(char * \hy-8{1418}{topic}, char * \hy-8{1419}{item}, int * \hy-8{1420}{size}, int \hy-8{1421}{ format})}

Message sent to the server application when the client
calls \hy-13{1422}{wxConnection::Request}. The server
should respond by returning a character string from \hy-8{1423}{OnRequest},
or NULL to indicate no data.


\hy-10{1425}{wxConnection::OnStartAdvise}

\hy-8{1426}{Bool OnStartAdvise(char * \hy-8{1427}{topic}, char * \hy-8{1428}{item})}

Message sent to the server application by the client, when the client
wishes to start an `advise loop' for the given topic and item. The
server can refuse to participate by returning FALSE.


\hy-10{1430}{wxConnection::OnStopAdvise}

\hy-8{1431}{Bool OnStopAdvise(char * \hy-8{1432}{topic}, char * \hy-8{1433}{item})}

Message sent to the server application by the client, when the client
wishes to stop an `advise loop' for the given topic and item. The
server can refuse to stop the advise loop by returning FALSE, although
this doesn't have much meaning in practice.


\hy-10{1435}{wxConnection::Poke}

\hy-8{1436}{Bool Poke(char * \hy-8{1437}{item}, char * \hy-8{1438}{data}, int \hy-8{1439}{ size = -1}, int \hy-8{1440}{ format = wxCF_TEXT})}

Called by the client application to poke data into the server. Can be
used to transfer arbitrary data to the server. Causes the server
connection's \hy-13{1441}{wxConnection::OnPoke} member
to be called. Returns TRUE if successful.


\hy-10{1443}{wxConnection::Request}

\hy-8{1444}{char * Request(char * \hy-8{1445}{item}, int * \hy-8{1446}{size}, int \hy-8{1447}{ format = wxCF_TEXT})}

Called by the client application to request data from the server. Causes
the server connection's \hy-13{1448}{wxConnection::OnRequest} member to be called. Returns a
character string (actually a pointer to the connection's buffer) if
successful, NULL otherwise.


\hy-10{1450}{wxConnection::StartAdvise}

\hy-8{1451}{Bool StartAdvise(char * \hy-8{1452}{item})}

Called by the client application to ask if an advise loop can be started
with the server. Causes the server connection's \hy-13{1453}{wxConnection::OnStartAdvise}
member to be called. Returns TRUE if the server okays it, FALSE
otherwise.


\hy-10{1455}{wxConnection::StopAdvise}

\hy-8{1456}{Bool StopAdvise(char * \hy-8{1457}{item})}

Called by the client application to ask if an advise loop can be
stopped. Causes the server connection's \hy-13{1458}{wxConnection::OnStopAdvise} member
to be called. Returns TRUE if the server okays it, FALSE otherwise.


\hy-10{1466}{wxCursor::wxCursor}

\hy-8{1467}{void wxCursor(void)}

\hy-8{1468}{void wxCursor(short \hy-8{1469}{ bits[]}, int \hy-8{1470}{width},
int \hy-8{1471}{ height})}

\hy-8{1472}{void wxCursor(char * \hy-8{1473}{ cursor_name})}

\hy-8{1474}{void wxCursor(int \hy-8{1475}{ id})}

Constructor. A cursor can be created by passing an array of bits
(XView and Motif only) by passing a string name, or by passing a stock
cursor id. \hy-7{1476}{cursor_name} refers to a filename in X, or a
resource name in Windows 3.

The following stock cursor ids may be used:


\hy-8{1477}{o}  wxCURSOR_ARROW
\hy-8{1478}{o}  wxCURSOR_BULLSEYE
\hy-8{1479}{o}  wxCURSOR_CHAR
\hy-8{1480}{o}  wxCURSOR_CROSS
\hy-8{1481}{o}  wxCURSOR_HAND
\hy-8{1482}{o}  wxCURSOR_IBEAM
\hy-8{1483}{o}  wxCURSOR_LEFT_BUTTON
\hy-8{1484}{o}  wxCURSOR_MAGNIFIER
\hy-8{1485}{o}  wxCURSOR_MIDDLE_BUTTON
\hy-8{1486}{o}  wxCURSOR_NO_ENTRY
\hy-8{1487}{o}  wxCURSOR_PAINT_BRUSH
\hy-8{1488}{o}  wxCURSOR_PENCIL
\hy-8{1489}{o}  wxCURSOR_POINT_LEFT
\hy-8{1490}{o}  wxCURSOR_POINT_RIGHT
\hy-8{1491}{o}  wxCURSOR_QUESTION_ARROW
\hy-8{1492}{o}  wxCURSOR_RIGHT_BUTTON
\hy-8{1493}{o}  wxCURSOR_SIZENESW
\hy-8{1494}{o}  wxCURSOR_SIZENS
\hy-8{1495}{o}  wxCURSOR_SIZENWSE
\hy-8{1496}{o}  wxCURSOR_SIZEWE
\hy-8{1497}{o}  wxCURSOR_SIZING
\hy-8{1498}{o}  wxCURSOR_SPRAYCAN
\hy-8{1499}{o}  wxCURSOR_WAIT
\hy-8{1500}{o}  wxCURSOR_WATCH



\hy-10{1502}{wxCursor::~wxCursor}

\hy-8{1503}{void ~wxCursor(void)}

Destroys the cursor. Unlike an icon, a cursor can be reused for more
than one window, and does not get destroyed when the window is
destroyed. wxWindows destroys all cursors on application exit.


\hy-10{1519}{wxDC::wxDC}

\hy-8{1520}{void wxDC(void)}

Constructor.


\hy-10{1522}{wxDC::~wxDC}

\hy-8{1523}{void ~wxDC(void)}

Destructor.


\hy-10{1525}{wxDC::Blit}

\hy-8{1526}{Bool Blit(float \hy-8{1527}{ xdest}, float \hy-8{1528}{ ydest}, float \hy-8{1529}{ width}, float \hy-8{1530}{ height},

  wxDC * \hy-8{1531}{source}, float \hy-8{1532}{ xsrc}, float \hy-8{1533}{ ysrc}, int \hy-8{1534}{ logical_func})}

Copy from a source DC to this DC, specifying the destination
coordinates, size of area to copy, source DC, source coordinates, and
logical function (see \hy-13{1535}{wxDC::SetLogicalFunction}).
See \hy-13{1536}{wxMemoryDC} for typical usage.


\hy-10{1538}{wxDC::Clear}

\hy-8{1539}{void Clear(void)}



\hy-10{1541}{wxDC::DestroyClippingRegion}

\hy-8{1542}{void DestroyClippingRegion(void)}

Destroys the current clipping region so that none of the DC is clipped.
See also \hy-13{1543}{wxDC::SetClippingRegion}.


\hy-10{1545}{wxDC::DeviceToLogicalX}

\hy-8{1546}{float DeviceToLogicalX(int \hy-8{1547}{ x})}

Convert device X coordinate to logical coordinate, using the current
mapping mode.


\hy-10{1549}{wxDC::DeviceToLogicalY}

\hy-8{1550}{float DeviceToLogicalY(int \hy-8{1551}{ y})}

Converts device Y coordinate to logical coordinate, using the current
mapping mode.


\hy-10{1553}{wxDC::DrawArc}

\hy-8{1554}{void DrawArc(float \hy-8{1555}{ x1}, float \hy-8{1556}{ y1}, float \hy-8{1557}{ x2}, float \hy-8{1558}{ y2}, float \hy-8{1559}{xc}, float \hy-8{1560}{yc})}

Draws an arc, centred on (\hy-7{1561}{xc, yc}), with starting point (\hy-7{1562}{x1, y1})
and ending at (\hy-7{1563}{x2, y2}).   The current pen is used for the outline
and the current brush for filling the shape.


\hy-10{1565}{wxDC::DrawEllipse}

\hy-8{1566}{void DrawEllipse(float \hy-8{1567}{ x}, float \hy-8{1568}{ y}, float \hy-8{1569}{ width}, float \hy-8{1570}{ height})}

Draws an ellipse contained in the rectangle with the given top left corner, and with the
given size.  The current pen is used for the outline and the current brush for
filling the shape.


\hy-10{1572}{wxDC::DrawIcon}

\hy-8{1573}{void DrawIcon(wxIcon * \hy-8{1574}{icon}, float \hy-8{1575}{ x}, float \hy-8{1576}{ y})}

Draw an icon on the display (does nothing if the device context is PostScript).
This can be the simplest way of drawing bitmaps on a canvas.


\hy-10{1578}{wxDC::DrawLine}

\hy-8{1579}{void DrawLine(float \hy-8{1580}{ x1}, float \hy-8{1581}{ y1}, float \hy-8{1582}{ x2}, float \hy-8{1583}{ y2})}

Draws a line from the first point to the second. The current pen is used
for drawing the line.


\hy-10{1585}{wxDC::DrawLines}

\hy-8{1586}{void DrawLines(int \hy-8{1587}{ n}, wxPoint \hy-8{1588}{ points[]}, float \hy-8{1589}{ xoffset = 0}, float \hy-8{1590}{ yoffset = 0})}

\hy-8{1591}{void DrawLines(wxList * \hy-8{1592}{points}, float \hy-8{1593}{ xoffset = 0}, float \hy-8{1594}{ yoffset = 0})}

Draws lines using an array of \hy-7{1595}{points} of size \hy-7{1596}{n}, or list of
pointers to points, adding the optional offset coordinate. The current
pen is used for drawing the lines.  The programmer is responsible for
deleting the list of points.


\hy-10{1598}{wxDC::DrawPolygon}

\hy-8{1599}{void DrawPolygon(int \hy-8{1600}{ n}, wxPoint \hy-8{1601}{ points[]}, float \hy-8{1602}{ xoffset = 0}, float \hy-8{1603}{ yoffset = 0})}

\hy-8{1604}{void DrawPolygon(wxList * \hy-8{1605}{points}, float \hy-8{1606}{ xoffset = 0}, float \hy-8{1607}{ yoffset = 0})}

Draws a filled polygon using an array of \hy-7{1608}{points} of size \hy-7{1609}{n},
or list of pointers to points, adding the optional offset coordinate.
The current pen is used for drawing the outline, and the current brush
for filling the shape.  Using a transparent brush suppresses filling.
The programmer is responsible for deleting the list of points.

Note that wxWindows automatically closes the first and last points.


\hy-10{1611}{wxDC::DrawPoint}

\hy-8{1612}{void DrawPoint(float \hy-8{1613}{ x}, float \hy-8{1614}{ y})}

Draws a point using the current pen.


\hy-10{1616}{wxDC::DrawRectangle}

\hy-8{1617}{void DrawRectangle(float \hy-8{1618}{ x}, float \hy-8{1619}{ y}, float \hy-8{1620}{ width}, float \hy-8{1621}{ height})}

Draws a rectangle with the given top left corner, and with the given
size.  The current pen is used for the outline and the current brush
for filling the shape.


\hy-10{1623}{wxDC::DrawRoundedRectangle}

\hy-8{1624}{void DrawRoundedRectangle(float \hy-8{1625}{ x}, float \hy-8{1626}{ y}, float \hy-8{1627}{ width}, float \hy-8{1628}{ height}, float \hy-8{1629}{ radius = 20})}

Draws a rectangle with the given top left corner, and with the given
size.  The corners are quarter-circles using the given radius. The
current pen is used for the outline and the current brush for filling
the shape.


\hy-10{1631}{wxDC::DrawSpline}

\hy-8{1632}{void DrawSpline(wxList * \hy-8{1633}{points})}

Draws a spline between all given control points, using the current
pen.  Doesn't delete the wxList and contents. The spline is drawn
using a series of lines, using an algorithm taken from the X drawing
program `XFIG'.

\hy-8{1634}{void DrawSpline(float \hy-8{1635}{ x1}, float \hy-8{1636}{ y1}, float \hy-8{1637}{ x2}, float \hy-8{1638}{ y2}, float \hy-8{1639}{ x3}, float \hy-8{1640}{ y3})}

Draws a three-point spline using the current pen.


\hy-10{1642}{wxDC::DrawText}

\hy-8{1643}{void DrawText(char * \hy-8{1644}{text}, float \hy-8{1645}{ x}, float \hy-8{1646}{ y})}

Draws a text string at the specified point, using the current text font,
and the current text foreground and background colours.

The coordinates refer to the top-left corner of the rectangle bounding
the string. See \hy-13{1647}{wxDC::GetTextExtent} for how
to get the dimensions of a text string, which can be used to position the
text more precisely.


\hy-10{1649}{wxDC::EndDoc}

\hy-8{1650}{void EndDoc(void)}

Ends a document (only relevant when outputting to a printer).


\hy-10{1652}{wxDC::EndPage}

\hy-8{1653}{void EndPage(void)}

Ends a document page (only relevant when outputting to a printer).


\hy-10{1655}{wxDC::GetMapMode}

\hy-8{1656}{int GetMapMode(void)}

Gets the \hy-7{1657}{mapping mode} for the device context (see \hy-13{1658}{wxDC::SetMapMode}).


\hy-10{1660}{wxDC::GetSize}

\hy-8{1661}{void GetSize(int * \hy-8{1662}{width}, int * \hy-8{1663}{height})}

This gets the maximum size of graphics drawn so far on the device context.


\hy-10{1665}{wxDC::GetTextExtent}

\hy-8{1666}{void GetTextExtent(char * \hy-8{1667}{string}, float * \hy-8{1668}{w}, float * \hy-8{1669}{h},

  float * \hy-8{1670}{descent = NULL}, float * \hy-8{1671}{externalLeading = NULL})}

Gets the dimensions of the string using the currently selected font.
\hy-7{1672}{string} is the text string to measure, \hy-7{1673}{w} and \hy-7{1674}{h} are
the total width and height respectively, \hy-7{1675}{descent} is the
dimension from the baseline of the font to the bottom of the
descender, and \hy-7{1676}{externalLeading} is any extra vertical space added
to the font by the font designer (usually is zero).

See also \hy-13{1677}{wxFont}, \hy-13{1678}{wxDC::SetFont}.


\hy-10{1680}{wxDC::LogicalToDeviceX}

\hy-8{1681}{int LogicalToDeviceX(float \hy-8{1682}{ x})}

Converts logical X coordinate to device coordinate, using the current
mapping mode.


\hy-10{1684}{wxDC::LogicalToDeviceY}

\hy-8{1685}{int LogicalToDeviceY(float \hy-8{1686}{ y})}

Converts logical Y coordinate to device coordinate, using the current
mapping mode.


\hy-10{1688}{wxDC::MaxX}

\hy-8{1689}{float MaxX(void)}

Gets the maximum horizontal extent used in drawing commands so far.


\hy-10{1691}{wxDC::MaxY}

\hy-8{1692}{float MaxY(void)}

Gets the maximum vertical extent used in drawing commands so far.


\hy-10{1694}{wxDC::MinX}

\hy-8{1695}{float MinX(void)}

Gets the minimum horizontal extent used in drawing commands so far.


\hy-10{1697}{wxDC::MinY}

\hy-8{1698}{float MinY(void)}

Gets the minimum vertical extent used in drawing commands so far.


\hy-10{1700}{wxDC::Ok}

\hy-8{1701}{Bool Ok(void)}

Returns TRUE if the DC is ok to use.


\hy-10{1703}{wxDC::SetBackground}

\hy-8{1704}{void SetBackground(wxBrush * \hy-8{1705}{brush})}

Sets the current background brush for the DC.  Do not delete the
brush; it will be deleted automatically when the application
terminates.


\hy-10{1707}{wxDC::SetBackgroundMode}

\hy-8{1708}{void SetBackgroundMode(int \hy-8{1709}{ mode})}

\hy-7{1710}{mode} may be one of wxSOLID and wxTRANSARENT. This setting determines
whether text will be drawn with a background colour or not.


\hy-10{1712}{wxDC::SetClippingRegion}

\hy-8{1713}{void SetClippingRegion(float \hy-8{1714}{ x}, float \hy-8{1715}{ y}, float \hy-8{1716}{ width}, float \hy-8{1717}{ height})}

Sets the clipping region for the DC. The clipping region is a rectangular area
to which drawing is restricted.  Possible uses for the clipping region are for clipping text
or for speeding up canvas redraws when only a known area of the screen is damaged.

See also \hy-13{1718}{wxDC::DestroyClippingRegion}.


\hy-10{1720}{wxDC::SetBrush}

\hy-8{1721}{void SetBrush(wxBrush * \hy-8{1722}{brush})}

Sets the current brush for the DC.  The brush is not copied, so you should not delete
the brush unless the DC pen has been set to another brush, or to NULL. Note that
all pens and brushes are automatically deleted when the program is exited.

See also \hy-13{1723}{wxBrush}.


\hy-10{1725}{wxDC::SetFont}

\hy-8{1726}{void SetFont(wxFont * \hy-8{1727}{font})}

Sets the current font for the DC. The font is not copied, so you should not delete
the font unless the DC pen has been set to another font, or to NULL.

See also \hy-13{1728}{wxFont}.


\hy-10{1730}{wxDC::SetLogicalFunction}

\hy-8{1731}{void SetLogicalFunction(int \hy-8{1732}{ function})}

Sets the current logical function for the canvas.  This determines how
a source pixel (from a pen or brush colour, or source device context if
using \hy-13{1733}{wxDC::Blit}) combines with a destination pixel in the
current device context.

The possible values
and their meaning in terms of source and destination pixel values are
as follows:

\hy-14{1734}{wxAND                 src AND dst
wxAND_INVERT          (NOT src) AND dst
wxAND_REVERSE         src AND (NOT dst)
wxCLEAR               0
wxCOPY                src
wxEQUIV               (NOT src) XOR dst
wxINVERT              NOT dst
wxNAND                (NOT src) OR (NOT dst)
wxNOR                 (NOT src) AND (NOT dst)
wxNO_OP               dst
wxOR                  src OR dst
wxOR_INVERT           (NOT src) OR dst
wxOR_REVERSE          src OR (NOT dst)
wxSET                 1
wxSRC_INVERT          NOT src
wxXOR                 src XOR dst
}

The default is wxCOPY, which simply draws with the current colour.
The others combine the current colour and the background using a
logical operation.  wxXOR is commonly used for drawing rubber bands or
moving outlines, since drawing twice reverts to the original colour.


\hy-10{1736}{wxDC::SetMapMode}

\hy-8{1737}{void SetMapMode(int \hy-8{1738}{ int})}

The \hy-7{1739}{mapping mode} of the device context defines the unit of
measurement used to convert logical units to device units. Note that
in X, text drawing isn't handled consistently with the mapping mode; a
font is always specified in point size. However, setting the \hy-7{1740}{
user scale} (see \hy-13{1741}{wxDC::SetUserScale}) scales the text appropriately. In
Windows, scaleable TrueType fonts are always used; in X, results depend
on availability of fonts, but usually a reasonable match is found.

Note that the coordinate origin should ideally be selectable, but for
now is always at the top left of the screen/printer.

Drawing to a Windows printer device context under UNIX
uses the current mapping mode, but mapping mode is currently ignored for
PostScript output.

The mapping mode can be one of the following:


\hy-8{1742}{o}  MM_TWIPS - each logical unit is 1/20 of a point, or 1/1440 of
  an inch
\hy-8{1743}{o}  MM_POINTS - each logical unit is a point, or 1/72 of an inch
\hy-8{1744}{o}  MM_METRIC - each logical unit is 1 mm
\hy-8{1745}{o}  MM_LOMETRIC - each logical unit is 1/10 of a mm
\hy-8{1746}{o}  MM_TEXT - each logical unit is 1 pixel




\hy-10{1748}{wxDC::SetPen}

\hy-8{1749}{void SetPen(wxPen * \hy-8{1750}{pen})}

Sets the current pen for the DC.  The pen is not copied, so you should
not delete the pen unless the DC pen has been set to another pen, or
to NULL. Note that all pens and brushes are automatically deleted when
the program is exited.


\hy-10{1752}{wxDC::SetTextBackground}

\hy-8{1753}{void SetTextBackground(wxColour * \hy-8{1754}{colour})}

Sets the current text background colour for the DC.  Do not delete \hy-7{1755}{
colour} while selected for use by a DC.


\hy-10{1757}{wxDC::SetTextForeground}

\hy-8{1758}{void SetTextForeground(wxColour * \hy-8{1759}{colour})}

Sets the current text foreground colour for the DC. Do not delete \hy-7{1760}{
colour} while selected for use by a DC.


\hy-10{1762}{wxDC::SetUserScale}

\hy-8{1763}{void SetUserScale(float \hy-8{1764}{ x_scale}, float \hy-8{1765}{y_scale})}

Sets the user scaling factor, useful for applications which require
`zooming'.


\hy-10{1767}{wxDC::StartDoc}

\hy-8{1768}{Bool StartDoc(char * \hy-8{1769}{message})}

Starts a document (only relevant when outputting to a printer).
Message is a message to show whilst printing.


\hy-10{1771}{wxDC::StartPage}

\hy-8{1772}{Bool StartPage(void)}

Starts a document page (only relevant when outputting to a printer).


\hy-10{1783}{wxDialogBox::wxDialogBox}

\hy-8{1784}{void wxDialogBox(wxFrame * \hy-8{1785}{parent}, char * \hy-8{1786}{title},
Bool \hy-8{1787}{ modal=FALSE},
 int \hy-8{1788}{ x=300}, int \hy-8{1789}{ y=300}, 
  int \hy-8{1790}{ width=500}, int \hy-8{1791}{ height=500},

  int \hy-8{1792}{ style = wxCAPTION | wxSYSTEM_MENU | wxTHICK_FRAME},

  char * \hy-8{1793}{name = ``dialogBox"})}

Constructor.

If \hy-7{1794}{title} is non-NULL, it is placed on the window frame.

If \hy-7{1795}{modal} is TRUE, the dialog box will wait to be
dismissed (using \hy-14{1796}{Show(FALSE)}) before returning control to the
calling program.

The \hy-7{1797}{style} parameter may be a combination of the following, using the bitwise `or' operator:


\hy-8{1798}{o}  \hy-8{1799}{wxABSOLUTE_POSITIONING}: a hint to the windowing system not to try automatic layout
  (Motif only).
\hy-8{1800}{o}  \hy-8{1801}{wxCAPTION}: puts a caption on the dialog box (under XView and Motif this is mandatory).
\hy-8{1802}{o}  \hy-8{1803}{wxSTAY_ON_TOP}: stay on top of other windows (Windows only).
\hy-8{1804}{o}  \hy-8{1805}{wxSYSTEM_MENU}: display a system menu (manadatory under XView and Motif).
\hy-8{1806}{o}  \hy-8{1807}{wxTHICK_FRAME}: display a thick frame around the window (manadatory under XView and Motif).
\hy-8{1808}{o}  \hy-8{1809}{wxVSCROLL}: give the dialog box a vertical scrollbar (XView only).


The \hy-7{1810}{name} parameter is used to associate a name with the window,
allowing the application user to set Motif resource values for
individual dialog boxes.


\hy-10{1812}{wxDialogBox::~wxDialogBox}

\hy-8{1813}{void ~wxDialogBox(void)}

Destructor.  Deletes any panel items before deleting the physical window.


\hy-10{1815}{wxDialog::Centre}

\hy-8{1816}{void Centre(int \hy-8{1817}{ direction = wxBOTH})}

Centres the dialog box on the display. The parameter may be \hy-14{1818}{
wxHORIZONTAL}, \hy-14{1819}{wxVERTICAL} or \hy-14{1820}{wxBOTH}.


\hy-10{1822}{wxDialogBox::Create}

\hy-8{1823}{void Create(wxFrame * \hy-8{1824}{parent}, char * \hy-8{1825}{title},
Bool \hy-8{1826}{ modal=FALSE},
 int \hy-8{1827}{ x=300}, int \hy-8{1828}{ y=300}, 
  int \hy-8{1829}{ width=500}, int \hy-8{1830}{ height=500},

  int \hy-8{1831}{ style = wxCAPTION | wxSYSTEM_MENU | wxTHICK_FRAME},

  char * \hy-8{1832}{name = ``dialogBox"})}

Used for two-step dialog box construction. See \hy-13{1833}{wxDialogBox::wxDialogBox}
for details.


\hy-10{1835}{wxDialogBox::GetTitle}

\hy-8{1836}{char * GetTitle(void)}

Gets a temporary pointer to the title of the dialog box.


\hy-10{1838}{wxDialogBox::Iconize}

\hy-8{1839}{void Iconize(Bool \hy-8{1840}{ iconize})}

If TRUE, iconizes the dialog box; if FALSE, shows and restores it. Note
that in Windows, iconization has no effect since dialog boxes cannot be
iconized. However, applications may need to explicitly restore dialog
boxes under XView and Motif which have user-iconizable frames, and under Windows
calling \hy-14{1841}{Iconize(FALSE)} will bring the window to the front, as does
\hy-14{1842}{Show(TRUE)}.


\hy-10{1844}{wxDialogBox::Iconized}

\hy-8{1845}{Bool Iconized(void)}

Returns TRUE if the dialog box is iconized. Always returns FALSE under
Windows for the reasons given above.


\hy-10{1847}{wxDialogBox::SetTitle}

\hy-8{1848}{void SetTitle(char * \hy-8{1849}{ title})}

Sets the title of the dialog box.


\hy-10{1851}{wxDialogBox::Show}

\hy-8{1852}{void Show(Bool \hy-8{1853}{ show})}

If \hy-7{1854}{show} is TRUE, the dialog box is shown and brought to the front;
otherwise the box is hidden. If \hy-7{1855}{show} is FALSE and the dialog is
modal, control is returned to the calling program.


\hy-10{1864}{wxEnhDialogBox::wxEnhDialogBox}

\hy-8{1865}{void wxEnhDialogBox(wxFrame * \hy-8{1866}{frame}, char * \hy-8{1867}{title},

 Bool  \hy-8{1868}{modal = FALSE}, wxFunction  \hy-8{1869}{fun = NULL}, int  \hy-8{1870}{space = -1},

 int  \hy-8{1871}{x = 0}, int  \hy-8{1872}{y = 0}, int  \hy-8{1873}{width = 10}, int  \hy-8{1874}{height = 10},

 char * \hy-8{1875}{name = "Shell"})}

Constructor. \hy-7{1876}{fun} is called when the user dismiss the window by
using the pin or the cancel button. If \hy-7{1877}{space} is greater than zero, it is
used as panel horizontal spacing for the command area.


\hy-10{1879}{wxEnhDialogBox::~wxEnhDialogBox}

\hy-8{1880}{void ~wxEnhDialogBox(void)}

Destructor.


\hy-10{1882}{wxEnhDialogBox::userPanel}

\hy-8{1883}{wxPanel * userPanel}

User application items must be created in this panel.


\hy-10{1885}{wxEnhDialogBox::SetStatus}

\hy-8{1886}{void SetStatus(char * \hy-8{1887}{label=NULL})}

Display text in the staus area.


\hy-10{1889}{wxEnhDialogBox::AddCmd}

\hy-8{1890}{wxButton * AddCmd(char * \hy-8{1891}{label}, wxFunction  \hy-8{1892}{fun=NULL},

  int  \hy-8{1893}{tag = 0})}

\hy-8{1894}{wxButton * AddCmd(wxBitmap * \hy-8{1895}{bitmap}, wxFunction  \hy-8{1896}{fun=NULL},

  int  \hy-8{1897}{tag = 0})}

Adds a command button in the command area, and returns its identifier. The
client data part of the button is initialized with \hy-7{1898}{tag}.
Buttons are aranged horizontally, from left to right. If WANT_CANCEL_BUTTON
is defined at compile time, a first button is automatically created, with
the label ``Cancel''.


\hy-10{1900}{wxEnhDialogBox::GetCmd}

\hy-8{1901}{wxButton * GetCmd(int  \hy-8{1902}{n})}

Returns the identifier of the \hy-7{1903}{n}th wxButton in the command area
(starting at 0).


\hy-10{1905}{wxEnhDialogBox::SetPin}

\hy-8{1906}{void SetPin(Bool  \hy-8{1907}{flag})}

Set the pushpin to the given state. The state of the pushpin controls the way
the ::Show() method works. Usually, setting the pin to TRUE indicates an
error. Please note that this works even if you have compiled with
WANT_CANCEL_BUTTON.


\hy-10{1909}{wxEnhDialogBox::Show}

\hy-8{1910}{void Show(Bool  \hy-8{1911}{show}, Bool  \hy-8{1912}{flag = FALSE})}

Dismiss or popup the dialog box. If \hy-7{1913}{show} is FALSE, the dialog box
is dismissed only if the pushpin current state is FALSE. If \hy-7{1914}{show}
is TRUE, the dialog box is popped, and the pushpin is initialized in the
state \hy-7{1915}{flag}.


\hy-10{1917}{wxEnhDialogBox::Fit}

\hy-8{1918}{void Fit(void)}

Fits the dialog box to its contents, and centres command buttons in the
command area. The status area is created when Fit is called, so do not
call SetStatus before fitting.



\hy-10{1925}{wxEvent::wxEvent}

\hy-8{1926}{void wxEvent(void)}

Constructor. Should not need to be used by an application.


\hy-10{1928}{wxEvent::~wxEvent}

\hy-8{1929}{void ~wxEvent(void)}

Destructor. Should not need to be used by an application.


\hy-10{1931}{wxEvent::eventClass}

\hy-8{1932}{WXTYPE  eventClass}

The C++ class of the event, such as wxTYPE_COMMAND_EVENT.
A single class may have many `types'; it would be tedious to define
a new C++ class for each type of similar event.


\hy-10{1934}{wxEvent::eventHandle}

\hy-8{1935}{char * eventHandle}

Handle of an underlying windowing system event handle, such as
XEvent. Not guaranteed to be instantiated.


\hy-10{1937}{wxEvent::eventObject}

\hy-8{1938}{wxObject * eventObject}

The object (usually a window) that the event was generated from,
or should be sent to.


\hy-10{1940}{wxEvent::eventType}

\hy-8{1941}{WXTYPE  eventType}

The type of the event, such as wxEVENT_TYPE_BUTTON_COMMAND.


\hy-10{1943}{wxEvent::ReadEvent}

\hy-8{1944}{pure virtual Bool ReadEvent(istream& \hy-8{1945}{ stream})}

Reads the event from the given input stream.


\hy-10{1947}{wxEvent::WriteEvent}

\hy-8{1948}{pure virtual Bool WriteEvent(ostream& \hy-8{1949}{ stream})}

Writes the event to the given output stream.


\hy-10{1964}{wxFont::wxFont}

\hy-8{1965}{void wxFont(void)}

\hy-8{1966}{void wxFont(int \hy-8{1967}{ point_size}, int \hy-8{1968}{ family}, int \hy-8{1969}{ style}, int \hy-8{1970}{ weight}, Bool \hy-8{1971}{ underline = FALSE})}

Creates a font object. If the desired font does not exist, the closest
match will be chosen. Under XView, this may result in a number of
XView warnings during the matching process; these should be ignored,
and will only occur the first time wxWindows attempts to use an absent
font in a given size. wxWindows under Motif does the same thing, but
silently. Under Windows 3, only scaleable TrueType fonts are used.

Underlining only works under Windows 3 at present.

See also \hy-13{1972}{wxDC::SetFont}, \hy-13{1973}{wxDC::DrawText}
and \hy-13{1974}{wxDC::GetTextExtent}.

All fonts are automatically added to the global pointer \hy-8{1975}{wxTheFontList}.
Call \hy-13{1976}{wxFontList::FindOrCreateFont} to return
a previously-created font if possible.


\hy-10{1978}{wxFont::~wxFont}

\hy-8{1979}{void ~wxFont(void)}

Destroys a font object. Do not manually destroy a font which has been
assigned to a canvas. All GDI objects, including fonts, are
automatically destroyed on program exit, so there is no danger of memory
leakage as in conventional Windows programming.


\hy-10{1981}{wxFont::GetFamily}

\hy-8{1982}{int GetFamily(void)}

Gets the font family. See \hy-13{1983}{wxFont} for a list of valid
family identifiers.


\hy-10{1985}{wxFont::GetPointSize}

\hy-8{1986}{int GetPointSize(void)}

Gets the point size.


\hy-10{1988}{wxFont::GetStyle}

\hy-8{1989}{int GetStyle(void)}

Gets the font style.  See \hy-13{1990}{wxFont} for a list of valid
styles.


\hy-10{1992}{wxFont::GetUnderlined}

\hy-8{1993}{Bool GetUnderlined(void)}

TRUE if the font is underlined.


\hy-10{1995}{wxFont::GetWeight}

\hy-8{1996}{int GetWeight(void)}

Gets the font weight.   See \hy-13{1997}{wxFont} for a list of valid
weight identifiers.


\hy-10{2002}{wxFontList::wxFontList}

\hy-8{2003}{void wxFontList(void)}

Constructor.  The application should not construct its own font list:
use the object pointer \hy-8{2004}{wxTheFontList}.


\hy-10{2006}{wxFontList::AddFont}

\hy-8{2007}{void AddFont(wxFont * \hy-8{2008}{font})}

Used by wxWindows to add a font to the list, called in the font constructor.


\hy-10{2010}{wxFontList::FindOrCreateFont}

\hy-8{2011}{wxFont * FindOrCreateFont(int \hy-8{2012}{ point_size}, int \hy-8{2013}{ family}, int \hy-8{2014}{ style}, int \hy-8{2015}{ weight}, Bool \hy-8{2016}{ underline = FALSE})}

Finds a font of the given specification, or creates one and adds it to the list.


\hy-10{2018}{wxFontList::RemoveFont}

\hy-8{2019}{void RemoveFont(wxFont * \hy-8{2020}{font})}

Used by wxWindows to remove a font from the list.


\hy-10{2024}{The purpose of the form class}

The wxForm is a stab at providing form-like functionality, relieving the
programmer of the tedium of defining all the physical panel items and
the callbacks handling out-of-range data. It allows the application
writer to write form dialogs quickly (albeit programmatically) with
panel items being chosen automatically according to the given
constraints. The supplied form demo shows how succinct a form
definition can be. A form gets laid out from left to right; the
programmer can intersperse new lines and specify item sizes, but for
brevity no more control is allowed.

A form does not presuppose a particular type of panel: any window
derived from wxPanel may be associated with a form, once the form has
been built by adding form items. Also, a form reads from and writes to
any C++ variables in your program---just supply pointers to the variables,
and the form handles the rest.


\hy-10{2026}{Constraints on form items}

Each item in a form may be supplied with zero or more constraints, where
the range of possible constraints depends on the data type, and the
displayed panel item depends upon the data type and the constraint(s)
given.  For example, a string form item with a list of possible strings
as a constraint will produce a list box on the panel; an integer form
item with a range constraint will result in a slider being displayed.
The user may define his or her own constraint by passing a function as a
constraint which returns FALSE if the constraint was violated, TRUE
otherwise.  The function should write an appropriate message into the
buffer passed to it if the constraint was violated.


\hy-10{2028}{Form appearance}

Once displayed on a panel, a form shows Ok, Cancel, Update, Revert and
Help buttons along the top, with the user-supplied items below. When the
user presses Ok, the form items are checked for violation of
constraints; if any violations are found, an appropriate error message
is displayed and the user must correct the mistake (or press Cancel,
which leaves the item values as they were after the last Update).
Pressing Update also checks the constraints and updates the values, but
typically does not dismiss the dialog. Revert causes the displayed
values to take on the values at the last Update. Pressing Help cause the
OnHelp member to be called, which by default does nothing. By default,
the OnOk and OnCancel messages dismiss and delete the dialog box and
form, but these may be overridden by the application (see below).

The display-type values which may be passed to a form-item creation
function are as follows:


\hy-8{2029}{o}  wxFORM_DEFAULT: let wxWindows choose a suitable panel item
\hy-8{2030}{o}  wxFORM_SINGLE_LIST: use a single-selection listbox. Default for
string item with a one-of constraint
\hy-8{2031}{o}  wxFORM_CHOICE: use a choice item
\hy-8{2032}{o}  wxFORM_CHECKBOX: use a checkbox. Default for boolean item
\hy-8{2033}{o}  wxFORM_TEXT: use a single-line text item. Default for floating
point item, and for string and integer items with no constraints
\hy-8{2034}{o}  wxFORM_MULTITEXT: use a multi-line text item
\hy-8{2035}{o}  wxFORM_RADIOBOX: use a radiobox with a one-of constraint.
\hy-8{2036}{o}  wxFORM_SLIDER: use a slider. Default for integer item with range
constraint


The wxFormItem and wxFormItemConstraint classes are not detailed in this
manual since their members do not need to be directly accessed by the
user. Functions for creating form items and constraints for passing to
\hy-8{2037}{wxForm::Add} are given in the next subsection.


\hy-10{2039}{Example}

The following is an example of a form definition, taken from the form demo.
Here, a new form \hy-8{2040}{MyForm} has been derived, and a new member \hy-8{2041}{
EditForm} has been defined to edit objects of the type \hy-8{2042}{MyObject},
given a panel to display it on.

\hy-14{2043}{void MyForm::EditForm(MyObject *object, wxPanel *panel)
{
  Add(wxMakeFormString("string 1", &(object->string1), wxFORM_DEFAULT,
                       new wxList(wxMakeConstraintFunction(MyConstraint), 0)));
  Add(wxMakeFormNewLine());

  Add(wxMakeFormString("string 2", &(object->string2), wxFORM_DEFAULT,
                  new wxList(wxMakeConstraintStrings("One", "Two", "Three", 0), 0)));
  Add(wxMakeFormString("string 3", &(object->string3), wxFORM_CHOICE,
                       new wxList(wxMakeConstraintStrings("Pig", "Cow",
                                  "Aardvark", "Gorilla", 0), 0)));
  Add(wxMakeFormNewLine());
  Add(wxMakeFormShort("int 1", &(object->int1), wxFORM_DEFAULT,
                       new wxList(wxMakeConstraintRange(0.0, 50.0), 0)));
  Add(wxMakeFormNewLine());

  Add(wxMakeFormFloat("float 1", &(object->float1), wxFORM_DEFAULT,
                       new wxList(wxMakeConstraintRange(-100.0, 100.0), 0)));
  Add(wxMakeFormBool("bool 1", &(object->bool1)));
  Add(wxMakeFormNewLine());

  Add(wxMakeFormButton("Test button", (wxFunction)MyButtonProc));

  AssociatePanel(panel);
}
}


\hy-10{2045}{wxForm::wxForm}

\hy-8{2046}{void wxForm(int \hy-8{2047}{ useButtons = wxFORM_BUTTON_ALL},

  int \hy-8{2048}{ placeButtons = wxFORM_BUTTON_AT_TOP})}

Constructor. The value of \hy-7{2049}{useButtons} determines which buttons are
automatically created, and must be a bit list of the following
identifiers:


\hy-8{2050}{o}  wxFORM_BUTTON_OK
\hy-8{2051}{o}  wxFORM_BUTTON_CANCEL
\hy-8{2052}{o}  wxFORM_BUTTON_HELP
\hy-8{2053}{o}  wxFORM_BUTTON_UPDATE
\hy-8{2054}{o}  wxFORM_BUTTON_REVERT
\hy-8{2055}{o}  wxFORM_BUTTON_ALL


\hy-7{2056}{placeButtons} may be used to specify whether the form buttons are
placed the top or bottom of the form, and may be one of:


\hy-8{2057}{o}  wxFORM_BUTTON_AT_TOP
\hy-8{2058}{o}  wxFORM_BUTTON_AT_BOTTOM



\hy-10{2060}{wxForm::~wxForm}

\hy-8{2061}{void ~wxForm(void)}

Destructor. Does not delete the associated panel or any panel items, but
does delete all form items.


\hy-10{2063}{wxForm::Add}

\hy-8{2064}{void Add(wxFormItem * \hy-8{2065}{item}, long  \hy-8{2066}{id = -1})}

Adds a form item to the form. If an id is given this is associated with
the form item; otherwise a new id is generated, by which the item may be
identified later.


\hy-10{2068}{wxForm::FindItem}

\hy-8{2069}{wxNode * FindItem(long  \hy-8{2070}{id})}

Given a form item id, returns a list node containing the form item.


\hy-10{2072}{wxForm::Set}

\hy-8{2073}{Bool Set(long  \hy-8{2074}{id}, wxFormItem * \hy-8{2075}{item})}

Given a form item id, replaces an existing item with that id with the
given form item. Returns TRUE if successful.


\hy-10{2077}{wxForm::Delete}

\hy-8{2078}{Bool Delete(long  \hy-8{2079}{id})}

Deletes the given form item by id. Returns TRUE if successful.


\hy-10{2081}{wxForm::AssociatePanel}

\hy-8{2082}{void AssociatePanel(wxPanel * \hy-8{2083}{panel})}

Associates the form with the given panel (or window derived from wxPanel, such as
wxDialogBox). This causes a number of items to be created on the panel
using information from the list of form items. The panel should be shown
after this has been called.


\hy-10{2085}{wxForm::OnCancel}

\hy-8{2086}{void OnCancel(void)}

This member may be derived by the application. When the user presses the
Cancel button, this is called, allowing the application to take action.
By default, \hy-8{2087}{OnCancel} deletes the form and the panel associated with
it, probably the normal desired behaviour.


\hy-10{2089}{wxForm::OnOk}

\hy-8{2090}{void OnOk(void)}

This member may be derived by the application. When the user presses the
OK button, this is called, allowing the application to take action.
By default, \hy-8{2091}{OnOk} deletes the form and the panel associated with
it, probably the normal desired behaviour. Note that if any form item
constraints were violated when the user pressed OK, the member does not
get called.


\hy-10{2093}{wxForm::OnRevert}

\hy-8{2094}{void OnRevert(void)}

This member may be derived by the application. When the user presses the
Revert button, the C++ form item variable values in effect before the
last Update are restored.  Then this member is called, allowing the
application to take further action.


\hy-10{2096}{wxForm::OnUpdate}

\hy-8{2097}{void OnUpdate(void)}

This member may be derived by the application. When the user presses the
Update button, the C++ form item variable values are updated to the
values on the panel.  Then this member is called, allowing the
application to take further action.


\hy-10{2099}{wxForm::RevertValues}

\hy-8{2100}{void RevertValues(void)}

Internal function for displaying the C++ form item values in the
displayed panel items. Should not need to be called by the user.


\hy-10{2102}{wxForm::UpdateValues}

\hy-8{2103}{Bool UpdateValues(void)}

Internal function for setting the C++ form item values to the values set
in the panel items. Should not need to be called by the user.


\hy-10{2105}{Functions for making form items and constraints}

These functions make form items and their associated constraints for
passing to \hy-8{2106}{wxForm::Add}.

\hy-8{2107}{wxFormItem * wxMakeFormButton(char * \hy-8{2108}{label},
wxFunction \hy-8{2109}{ fun})}

Makes a button with a conventional callback.

\hy-8{2110}{wxFormItem * wxMakeFormMessage(char * \hy-8{2111}{label})}

Makes a message.

\hy-8{2112}{wxFormItem * wxMakeFormNewLine(void)}

Adds a newline.

\hy-8{2113}{wxFormItem * wxMakeFormLong(char * \hy-8{2114}{label}, long * \hy-8{2115}{var},

  int \hy-8{2116}{ item_type = wxFORM_DEFAULT}, wxList * \hy-8{2117}{constraints = NULL},

  char * \hy-8{2118}{help_string = NULL}, int \hy-8{2119}{ style = 0}, int \hy-8{2120}{ width = -1},

  int \hy-8{2121}{ height = -1})}

Makes a long integer form item, given a label, a pointer to the variable
holding the value, an item type, and a list of constraints (see below).
\hy-7{2122}{style} may be wxHORIZONTAL or wxVERTICAL (for label orientation).
\hy-7{2123}{help_string} is currently not used.

\hy-8{2124}{wxFormItem * wxMakeFormShort(char * \hy-8{2125}{label}, int * \hy-8{2126}{var},

  int \hy-8{2127}{ item_type = wxFORM_DEFAULT}, wxList * \hy-8{2128}{constraints = NULL},

  char * \hy-8{2129}{help_string = NULL}, int \hy-8{2130}{ style = 0}, int \hy-8{2131}{ width = -1},

  int \hy-8{2132}{ height = -1})}

Makes an integer form item, given a label, a pointer to the variable
holding the value, an item type, and a list of constraints (see below).
\hy-7{2133}{style} may be wxHORIZONTAL or wxVERTICAL (for label orientation).
\hy-7{2134}{help_string} is currently not used.

\hy-8{2135}{wxFormItem * wxMakeFormFloat(char * \hy-8{2136}{label}, float * \hy-8{2137}{var},

  int \hy-8{2138}{ item_type = wxFORM_DEFAULT}, wxList * \hy-8{2139}{constraints = NULL},

  char * \hy-8{2140}{help_string = NULL}, int \hy-8{2141}{ style = 0},
  int \hy-8{2142}{ width = -1},

  int \hy-8{2143}{ height = -1})}

Makes a floating-point form item, given a label, a pointer to the variable
holding the value, an item type, and a list of constraints (see below).
\hy-7{2144}{style} may be wxHORIZONTAL or wxVERTICAL (for label orientation).
\hy-7{2145}{help_string} is currently not used.

\hy-8{2146}{wxFormItem * wxMakeFormBool(char * \hy-8{2147}{label}, Bool * \hy-8{2148}{var},

  int \hy-8{2149}{ item_type = wxFORM_DEFAULT}, wxList * \hy-8{2150}{constraints = NULL},

  char * \hy-8{2151}{help_string = NULL}, int \hy-8{2152}{ style = 0}, int \hy-8{2153}{ width = -1},

  int \hy-8{2154}{ height = -1})}

Makes a boolean form item, given a label, a pointer to the variable
holding the value, an item type, and a list of constraints (see below).
\hy-7{2155}{style} may be wxHORIZONTAL or wxVERTICAL (for label orientation).
\hy-7{2156}{help_string} is currently not used.

\hy-8{2157}{wxFormItem * wxMakeFormString(char * \hy-8{2158}{label}, char ** \hy-8{2159}{var},

  int \hy-8{2160}{ item_type = wxFORM_DEFAULT}, wxList * \hy-8{2161}{constraints = NULL},

  char * \hy-8{2162}{help_string = NULL}, int \hy-8{2163}{ style = NULL},
  int \hy-8{2164}{ width = -1},

  int \hy-8{2165}{ height = -1})}

Makes a string form item, given a label, a pointer to the variable
holding the value, an item type, and a list of constraints (see below).
\hy-7{2166}{style} may be wxHORIZONTAL or wxVERTICAL (for label orientation).
\hy-7{2167}{help_string} is currently not used.

\hy-8{2168}{wxFormItemConstraint * wxMakeConstraintStrings(wxList * \hy-8{2169}{list})}

Makes a constraint specifying that the value must be one of the strings
given in the list.

\hy-8{2170}{wxFormItemConstraint * wxMakeConstraintStrings(char * \hy-8{2171}{first},  \hy-8{2172}{...})}

Makes a constraint specifying that the value must be one of the strings
given in the variable-length argument list,\hy-7{2173}{terminated with a zero}.

\hy-8{2174}{wxFormItemConstraint * wxMakeConstraintFunction(wxConstraintFunction  \hy-8{2175}{func})}

Makes a constraint with a function that gets called when the value is
being checked. The function should return FALSE if the constraint was
violated, TRUE otherwise.  The function should also write an appropriate
message into the buffer passed to it if the constraint was violated.
The type \hy-8{2176}{wxConstraintFunction} is defined as follows:

\hy-8{2177}{typedef Bool (*wxConstraintFunction)(int \hy-8{2178}{ type}, char * \hy-8{2179}{value}, char * \hy-8{2180}{label}, char * \hy-8{2181}{msg})}

\hy-7{2182}{type} is the type of the item, for instance wxFORM_STRING. \hy-7{2183}{value} is
the address of the variable containing the value, and should be coerced
to the correct type, except for wxFORM_STRING, where no coercion is required.

\hy-8{2184}{wxFormItemConstraint * wxMakeConstraintRange(float \hy-8{2185}{ lo}, float \hy-8{2186}{ hi})}

Makes a range constraint; can be used for integer and floating point
form items.


\hy-10{2194}{wxFrame::wxFrame}

\hy-8{2195}{void wxFrame(wxFrame * \hy-8{2196}{parent}, char * \hy-8{2197}{title}, int \hy-8{2198}{ x = -1}, int \hy-8{2199}{ y = -1},

  int \hy-8{2200}{ width = -1}, int \hy-8{2201}{ height = -1},

  int \hy-8{2202}{ style = wxSDI | wxDEFAULT_FRAME}, char * \hy-8{2203}{name = ``frame"})}

Constructor.  The \hy-7{2204}{parent} parameter can be NULL or an existing frame;
if an existing frame is used under Windows 3, the child frame is always on top
of the parent, and will be iconized when the parent is iconized.

If \hy-7{2205}{title} is non-NULL, it is placed on the window frame.

The style parameter may be a combination of the following, using the bitwise `or' operator.


\hy-8{2206}{o}  \hy-8{2207}{wxICONIZE}: display the frame iconized (minimized) (Windows only).
\hy-8{2208}{o}  \hy-8{2209}{wxCAPTION}: puts a caption on the frame (under XView and Motif this is mandatory).
\hy-8{2210}{o}  \hy-8{2211}{wxDEFAULT_FRAME}: defined as \hy-8{2212}{(wxMINIMIZE_BOX | wxMAXIMIZE_BOX | wxTHICK_FRAME | wxSYSTEM_MENU | wxCAPTION)}.
\hy-8{2213}{o}  \hy-8{2214}{wxMDI_CHILD}: specifies a Windows MDI (multiple document interface) child frame.
\hy-8{2215}{o}  \hy-8{2216}{wxMDI_PARENT}: specifies a Windows MDI (multiple document interface) parent frame.
\hy-8{2217}{o}  \hy-8{2218}{wxMINIMIZE}: identical to \hy-8{2219}{wxICONIZE}.
\hy-8{2220}{o}  \hy-8{2221}{wxMINIMIZE_BOX}: display a minimize box on the frame (Windows only).
\hy-8{2222}{o}  \hy-8{2223}{wxMAXIMIZE}: display the frame maximized (Windows only).
\hy-8{2224}{o}  \hy-8{2225}{wxMAXIMIZE_BOX}: display a maximize box on the frame (Windows only).
\hy-8{2226}{o}  \hy-8{2227}{wxSDI}: specifies a normal SDI (single document interface) frame.
\hy-8{2228}{o}  \hy-8{2229}{wxSTAY_ON_TOP}: stay on top of other windows (Windows only).
\hy-8{2230}{o}  \hy-8{2231}{wxSYSTEM_MENU}: display a system menu (manadatory under XView and Motif).
\hy-8{2232}{o}  \hy-8{2233}{wxTHICK_FRAME}: display a thick frame around the window (manadatory under XView and Motif).


The \hy-7{2234}{name} parameter is used to associate a name with the item,
allowing the application user to set Motif resource values for
individual windows.


\hy-10{2236}{wxFrame::~wxFrame}

\hy-8{2237}{void ~wxFrame(void)}

Destructor. Destroys all child windows and menu bar if present.


\hy-10{2239}{wxFrame::Centre}

\hy-8{2240}{void Centre(int \hy-8{2241}{ direction = wxBOTH})}

Centres the frame on the display. The parameter may be \hy-14{2242}{
wxHORIZONTAL}, \hy-14{2243}{wxVERTICAL} or \hy-14{2244}{wxBOTH}.


\hy-10{2246}{wxFrame::Command}

\hy-8{2247}{void Command(int  \hy-8{2248}{id})}

Simulate a menu command. \hy-7{2249}{id} is the identifier for a menu item.


\hy-10{2251}{wxFrame::Create}

\hy-8{2252}{void Create(wxFrame * \hy-8{2253}{parent}, char * \hy-8{2254}{title}, int \hy-8{2255}{ x = -1}, int \hy-8{2256}{ y = -1},

  int \hy-8{2257}{ width = -1}, int \hy-8{2258}{ height = -1},

  int \hy-8{2259}{ style = wxSDI | wxDEFAULT_FRAME}, char * \hy-8{2260}{name = ``frame"})}

Used in two-step frame construction. See \hy-13{2261}{wxFrame::wxFrame}
for further details.


\hy-10{2263}{wxFrame::CreateStatusLine}

\hy-8{2264}{void CreateStatusLine(int \hy-8{2265}{ number = 1})}

Creates a status line at the bottom of the frame. The width of the
status line is the whole width of the frame (adjusted automatically when
resizing), and the height and text size are chosen by the host system.

The default is to create one field the width of the frame; specify a
value between 1 and 5 to create a multi-field status line.

See alo \hy-13{2266}{wxFrame::SetStatusText}.


\hy-10{2268}{wxFrame::Fit}

\hy-8{2269}{void Fit(void)}

Reize the frame to just fit around the subwindows. If a frame has only
one subwindow, that subwindow will be resized by the default \hy-13{2270}{wxFrame::OnSize}
member to fit inside the frame.


\hy-10{2272}{wxFrame::GetTitle}

\hy-8{2273}{char * GetTitle(void)}

Gets a temporary pointer to the frame title. See
\hy-13{2274}{wxFrame::SetTitle}.


\hy-10{2276}{wxFrame::Iconize}

\hy-8{2277}{void Iconize(Bool \hy-8{2278}{ iconize})}

If TRUE, iconizes the frame; if FALSE, shows and restores it.


\hy-10{2280}{wxFrame::Iconized}

\hy-8{2281}{Bool Iconized(void)}

Returns TRUE if the frame is iconized.


\hy-10{2283}{wxFrame::Maximize}

\hy-8{2284}{void Maximize(Bool  \hy-8{2285}{maximize})}

Maximizes the frame if \hy-7{2286}{maximize} is TRUE, otherwise restores it
(Windows 3.1 only).


\hy-10{2288}{wxFrame::OnClose}

\hy-8{2289}{Bool OnClose(void)}

Sent to the frame when the user has tried to close the window using the
window manager (X) or system menu (Windows).  If TRUE is returned by
\hy-8{2290}{OnClose}, the frame will be deleted by the system, otherwise the
attempt will be ignored. Derive your own class to handle this message;
the default handler returns FALSE.

This member is a good place to delete other frames which are
conceptually or actually subframes of this frame, since if all frames
are not deleted, the application cannot exit. This is the top-level
\hy-8{2291}{OnClose} handler for the `hello' demo:

\hy-14{2292}{Bool MyFrame::OnClose(void)
{
  if (subframe)
    delete subframe;

  return TRUE;
}
}

When quitting the application from inside the application, for example
from a menu item, call the frame's \hy-8{2293}{OnClose} member before deleting
the frame. wxWindows then causes the application to exit without further
ado. For example:

\hy-14{2294}{// Intercept menu commands
void MyFrame::OnMenuCommand(int id)
{
  switch (id)
  {
    ...
    case HELLO_QUIT:
    {
      OnClose();
      delete this;
      break;
    }
    ...
  }
}
}


\hy-10{2296}{wxFrame::OnMenuCommand}

\hy-8{2297}{void OnMenuCommand(int \hy-8{2298}{ id})}

Sent to the window when an item on the window's menu has been chosen.
Derive your own frame class to handle this message. For example:

\hy-14{2299}{// Intercept menu commands
void MyFrame::OnMenuCommand(int id)
{
  switch (id)
  {
    case HELLO_LOAD_FILE:
    {
      char *s = wxFileSelector("Load text file", NULL, NULL, NULL, "*.txt");
      if (s)
        frame->text_window->LoadFile(s);
      break;
    }
    case HELLO_QUIT:
    {
      OnClose();
      delete this;
      break;
    }
    case HELLO_PRINT_EPS:
    {
      wxPostScriptDC dc(NULL, TRUE);
      if (dc.Ok())
      {
        dc.StartDoc("Hello printout");
        dc.StartPage();
        Draw(dc, TRUE);
        dc.EndPage();
        dc.EndDoc();
      }
      break;
    }
    case HELLO_ABOUT:
    {
      (void)wxMessageBox("wxWindows GUI library demo", "About wxHello", wxOK|wxCENTRE);
      break;
    }
  }
}
}


\hy-10{2301}{wxFrame::OnMenuSelect}

\hy-8{2302}{void OnMenuSelect(int \hy-8{2303}{ id})}

Sent to the window when an item on the window's menu has been selected
(i.e. the cursor is on the item, but the left button has not been
released). Derive your own frame class to handle this message.

The default \hy-8{2304}{OnMenuSelect} member puts the menu item help string
on the status line, if a status line has been created.

This function is called under Windows 3 and Motif, but not XView.


\hy-10{2306}{wxFrame::OnSize}

\hy-8{2307}{void OnSize(int \hy-8{2308}{ w}, int \hy-8{2309}{ h})}

Called when the user or application resizes the frame. The parameters
give the total size of the frame. The default \hy-8{2310}{OnSize} member
looks for a single subwindow, and if one is found, resizes it to fit
inside the frame. Override this member if more complex behaviour
is required (for example, if there are several subwindows).


\hy-10{2312}{wxFrame::SetIcon}

\hy-8{2313}{void SetIcon(wxIcon * \hy-8{2314}{ icon})}

Sets the icon for this frame, deleting any existing one.  Note an
important difference between XView and Windows 3 behaviour. In Windows
3, the title of the frame is the icon label, wrapping if necessary for a
long title. If the frame title changes, the icon label changes. In
XView, the icon label cannot be changed once the icon has been
associated with the frame.  Also, there is no wrapping, and icon labels
must therefore be short.

The best thing to do to accommodate both situations is to have the frame
title set to a short string when setting the icon. Then, set the frame
title to the desired text. In XView, the icon will keep its short text.
In Windows 3, the longer (probably more meaningful) title will be
shown.

Note also that in Windows 3, icons cannot be associated with a window
after window initialization, except by explicitly drawing the icon onto
the iconized window, which is what wxWindows does. Because of this
workaround, the background of the icon will be white rather than the
usual transparent. It was felt limiting to have to pass an icon name at
frame create time.

However, drawing the icon like this does not work (for some unknown
reason) with MDI parent and child frames, and so for MDI applications
the following lines need to be added to the Windows 3 resource file:

\hy-14{2315}{wxSTD_MDIPARENTFRAME ICON icon1.ico
wxSTD_MDICHILDFRAME  ICON icon2.ico
}

where icon1.ico will be used for the MDI parent frame, and icon2.ico
will be used for MDI child frames.

To assign an icon to all SDI frames, include a line similar to the
following:

\hy-14{2316}{wxSTD_FRAME      ICON icon1.ico
}

See also \hy-13{2317}{wxIcon}.


\hy-10{2319}{wxFrame::SetMenuBar}

\hy-8{2320}{void SetMenuBar(wxMenuBar * \hy-8{2321}{frame})}

Tells the frame to show the given menu bar.  If the frame is destroyed, the
menu bar and its menus will be destroyed also, so do not delete the menu
bar explicitly (except by resetting the frame's menu bar to another
frame or NULL).

See also \hy-13{2322}{wxMenuBar}, \hy-13{2323}{wxMenu}.


\hy-10{2325}{wxFrame::SetStatusText}

\hy-8{2326}{void SetStatusText(char * \hy-8{2327}{ text}, int \hy-8{2328}{ number = 0})}

Sets the status line text and redraws the status line. Use an empty (not NULL) string
to clear the status line. Optionally use \hy-7{2329}{number} to specify a
field in the status line, starting from zero and consistent with the number
of fields specified in \hy-13{2330}{wxFrame::CreateStatusLine}.


\hy-10{2332}{wxFrame::SetTitle}

\hy-8{2333}{void SetTitle(char * \hy-8{2334}{ title})}

Sets the frame title. See \hy-13{2335}{wxFrame::GetTitle}.


\hy-10{2337}{wxFrame::StatusLineExists}

\hy-8{2338}{Bool StatusLineExists(void)}

Returns TRUE if the status line has previously been created.
See \hy-13{2339}{wxFrame::CreateStatusLine}, \hy-13{2340}{wxFrame::SetStatusText}.


\hy-10{2344}{wxFunction}

\hy-8{2345}{typedef void (*wxFunction)(wxObject& \hy-8{2346}{}, wxCommandEvent& \hy-8{2347}{})}

The type of a panel item callback function. The first parameter is a reference
to the object, and the second is a command event structure.
See \hy-13{2348}{wxItem}, \hy-13{2349}{wxCommandEvent}.


\hy-10{2357}{wxIcon::wxIcon}

\hy-8{2358}{void wxIcon(void)}

\hy-8{2359}{void wxIcon(char \hy-8{2360}{ bits[]}, int \hy-8{2361}{ width}, int \hy-8{2362}{ height})}

\hy-8{2363}{void wxIcon(char * \hy-8{2364}{ icon_name})}

Constructor. An icon can be created by passing an array of bits (X only)
or by passing a string name. \hy-7{2365}{icon_name} refers to a filename in X,
a resource name in Windows 3.  


\hy-10{2367}{wxIcon::~wxIcon}

\hy-8{2368}{void ~wxIcon(void)}

Destroys the icon.  Do not explicitly delete an icon pointer which has
been passed to a frame - the frame will delete the icon when it is
destroyed. If assigning a new icon to a frame, the old icon will be
destroyed.


\hy-10{2374}{wxHashTable::wxHashTable}

\hy-8{2375}{void wxHashTable(unsigned int \hy-8{2376}{ key_type}, int \hy-8{2377}{ size = 1000})}

Constructor. \hy-7{2378}{key_type} is one of wxKEY_INTEGER, or wxKEY_STRING,
and indicates what sort of keying is required. \hy-7{2379}{size} is optional.


\hy-10{2381}{wxHashTable::~wxHashTable}

\hy-8{2382}{void ~wxHashTable(void)}

Destroys the hash table.


\hy-10{2384}{wxHashTable::BeginFind}

\hy-8{2385}{void BeginFind(void)}

The counterpart of \hy-7{2386}{Next}.  If the application wishes to iterate
through all the data in the hash table, it can call \hy-7{2387}{BeginFind} and
then loop on \hy-7{2388}{Next}.


\hy-10{2390}{wxHashTable::Clear}

\hy-8{2391}{void Clear(void)}

Clears the hash table of all nodes (but as usual, doesn't delete user data).


\hy-10{2393}{wxHashTable::Delete}

\hy-8{2394}{wxObject * Delete(long \hy-8{2395}{ key})}

\hy-8{2396}{wxObject * Delete(char * \hy-8{2397}{ key})}

Deletes entry in hash table and returns the user's data (if found).


\hy-10{2399}{wxHashTable::Get}

\hy-8{2400}{wxObject * Get(long \hy-8{2401}{ key})}

\hy-8{2402}{wxObject * Get(char * \hy-8{2403}{ key})}

Gets data from the hash table, using an integer or string key (depending on which
has table constructor was used).


\hy-10{2405}{wxHashTable::MakeKey}

\hy-8{2406}{long MakeKey(char * \hy-8{2407}{string})}

Makes an integer key out of a string. An application may wish to make a key
explicitly (for instance when combining two data values to form a key).


\hy-10{2409}{wxHashTable::Next}

\hy-8{2410}{wxNode * Next(void)}

If the application wishes to iterate through all the data in the hash
table, it can call \hy-7{2411}{BeginFind} and then loop on \hy-7{2412}{Next}. This function
returns a \hy-8{2413}{wxNode} pointer (or NULL if there are no more nodes).  See the
description for \hy-13{2414}{wxNode}. The user will probably only wish to use the
\hy-8{2415}{wxNode::Data} function to retrieve the data; the node may also be deleted.


\hy-10{2417}{wxHashTable::Put}

\hy-8{2418}{void Put(long \hy-8{2419}{ key}, wxObject * \hy-8{2420}{object})}

\hy-8{2421}{void Put(char * \hy-8{2422}{ key}, wxObject * \hy-8{2423}{object})}

Inserts data into the hash table, using an integer or string key (depending on which
has table constructor was used).  Note that only the pointer to the string key
is stored, so it should not be deallocated by the calling program.


\hy-10{2434}{wxHelpInstance::wxHelpInstance}

\hy-8{2435}{void wxHelpInstance(Bool \hy-8{2436}{ native})}

Constructs a help instance object, but does not invoke wxHelp.
If \hy-7{2437}{native} is TRUE, tries to use the native help system where
possible (Windows Help under Windows 3.1, wxHelp on other platforms).


\hy-10{2439}{wxHelpInstance::~wxHelpInstance}

Destroys the help instance, closing down wxHelp for this application
if it is running.


\hy-10{2441}{wxHelpInstance::Initialize}

\hy-8{2442}{void Initialize(char * \hy-8{2443}{file}, int \hy-8{2444}{ server = -1})}

Initializes the help instance with a help filename, and optionally a server (socket)
number (one is chosen at random if this parameter is omitted). Does not invoke wxHelp.
This must be called directly after the help instance object is created and before
any attempts to communicate with wxHelp.

You may omit the file extension, and in fact this is recommended if you
wish to support .xlp files under X and .hlp under Windows.


\hy-10{2446}{wxHelpInstance::DisplayBlock}

\hy-8{2447}{Bool DisplayBlock(long \hy-8{2448}{ blockNo})}

If wxHelp is not running, runs wxHelp and displays the file at the given block number.
If using Windows Help, displays the file at the given context number.


\hy-10{2450}{wxHelpInstance::DisplayContents}

\hy-8{2451}{Bool DisplayContents(void)}

If wxHelp is not running, runs wxHelp (or Windows Help) and displays the
contents (the first section of the file).


\hy-10{2453}{wxHelpInstance::DisplaySection}

\hy-8{2454}{Bool DisplaySection(int \hy-8{2455}{ sectionNo})}

If wxHelp is not running, runs wxHelp and displays the given section.
Sections are numbered starting from 1, and section numbers may be viewed by running
wxHelp in edit mode.


\hy-10{2457}{wxHelpInstance::KeywordSearch}

\hy-8{2458}{Bool KeywordSearch(char * \hy-8{2459}{keyWord})}

If wxHelp (or Windows Help) is not running, runs wxHelp (or Windows
Help), and searches for sections matching the given keyword. If one
match is found, the file is displayed at this section. If more than one
match is found, the Search dialog is displayed with the matches (wxHelp)
or the first topic is displayed (Windows Help).


\hy-10{2461}{wxHelpInstance::LoadFile}

\hy-8{2462}{Bool LoadFile(char * \hy-8{2463}{file = NULL})}

If wxHelp (or Windows Help) is not running, runs wxHelp (or Windows
Help), and loads the given file. If the filename is not supplied or is
NULL, the file specified in \hy-8{2464}{Initialize} is used. If wxHelp is
already displaying the specified file, it will not be reloaded. This
member function may be used before each display call in case the user
has opened another file.


\hy-10{2466}{wxHelpInstance::OnQuit}

\hy-8{2467}{Bool OnQuit(void)}

Overridable member called when this application's wxHelp is quit
(no effect if Windows Help is being used instead).


\hy-10{2469}{wxHelpInstance::Quit}

\hy-8{2470}{Bool Quit(void)}

If wxHelp is running, quits wxHelp by disconnecting (no effect for Windows
Help).


\hy-10{2474}{wxItem::Centre}

\hy-8{2475}{void Centre(int \hy-8{2476}{ direction = wxHORIZONTAL})}

Centres the frame on the panel or dialog box. The parameter may be \hy-14{2477}{
wxHORIZONTAL}, \hy-14{2478}{wxVERTICAL} or \hy-14{2479}{wxBOTH}.

You may still use \hy-8{2480}{Fit} in conjunction with this call, but call \hy-8{2481}{Fit}
first before centring items.


\hy-10{2483}{wxItem::Command}

\hy-8{2484}{void Command(wxCommandEvent \hy-8{2485}{ event})}

Simulate the effect of the user issuing a command to the item. See \hy-13{2486}{wxCommandEvent}.


\hy-10{2488}{wxItem::SetLabel}

\hy-8{2489}{void wxItem(char * \hy-8{2490}{label})}

Sets the item's label. A copy of the label is taken.


\hy-10{2492}{wxItem::GetLabel}

\hy-8{2493}{char * wxItem(void)}

Gets a temporary pointer to the item's label.


\hy-10{2498}{wxKeyEvent::controlDown}

\hy-8{2499}{Bool  controlDown}

TRUE if control is pressed down.


\hy-10{2501}{wxKeyEvent::keyCode}

\hy-8{2502}{long  keyCode}

Virtual keycode.


\hy-10{2504}{wxKeyEvent::shiftDown}

\hy-8{2505}{Bool  shiftDown}

TRUE if shift is pressed down.


\hy-10{2507}{wxKeyEvent::wxKeyEvent}

\hy-8{2508}{void wxKeyEvent(WXTYPE \hy-8{2509}{ keyEventType})}

Constructor. Currently, the only valid event type is wxEVENT_TYPE_CHAR.


\hy-10{2511}{wxKeyEvent::ControlDown}

\hy-8{2512}{Bool ControlDown(void)}

Returns TRUE if the control key was down at the time of the key event.


\hy-10{2514}{wxKeyEvent::KeyCode}

\hy-8{2515}{long KeyCode(void)}

Returns the virtual key code. ASCII events return normal ASCII values,
while non-ASCII events return values such as \hy-8{2516}{WXK_LEFT} for the
left cursor key. See \hy-14{2517}{common.h} for a full list of the virtual key codes.


\hy-10{2519}{wxKeyEvent::ShiftDown}

\hy-8{2520}{Bool ShiftDown(void)}

Returns TRUE if the shift key was down at the time of the key event.


\hy-10{2530}{wxList::wxList}

\hy-8{2531}{void wxList(void)}

\hy-8{2532}{void wxList(unsigned int \hy-8{2533}{ key_type})}

\hy-8{2534}{void wxList(int \hy-8{2535}{ n}, wxObject * \hy-8{2536}{objects[]})}

\hy-8{2537}{void wxList(wxObject * \hy-8{2538}{object}, ...)}

Constructors. \hy-7{2539}{key_type} is one of wxKEY_NONE, wxKEY_INTEGER, or wxKEY_STRING,
and indicates what sort of keying is required (if any).

\hy-7{2540}{objects} is an array of \hy-7{2541}{n} objects with which to initialize the list.

The variable-length argument list constructor must be supplied with a
terminating NULL.


\hy-10{2543}{wxList::~wxList}

\hy-8{2544}{void ~wxList(void)}

Destroys list.  Also destroys any remaining nodes, but does not destroy
client data held in the nodes.


\hy-10{2546}{wxList::Append}

\hy-8{2547}{wxNode * Append(wxObject * \hy-8{2548}{object})}

\hy-8{2549}{wxNode * Append(long \hy-8{2550}{ key}, wxObject * \hy-8{2551}{object})}

\hy-8{2552}{wxNode * Append(char * \hy-8{2553}{key}, wxObject * \hy-8{2554}{object})}

Appends a new \hy-8{2555}{wxNode} to the end of the list and puts a pointer to the
\hy-7{2556}{object} in the node.  The last two forms store a key with the object for
later retrieval using the key. The new node is returned in each case.


\hy-10{2558}{wxList::Clear}

\hy-8{2559}{void Clear(void)}

Clears the list (but does not delete the client data stored with each node).


\hy-10{2561}{wxList::DeleteContents}

\hy-8{2562}{void DeleteContents(Bool \hy-8{2563}{ destroy})}

If \hy-7{2564}{destroy} is TRUE, instructs the list to call \hy-7{2565}{delete} on the client contents of
a node whenever the node is destroyed. The default is FALSE.


\hy-10{2567}{wxList::DeleteNode}

\hy-8{2568}{Bool DeleteNode(wxNode * \hy-8{2569}{node})}

Deletes the given node from the list, returning TRUE if successful.


\hy-10{2571}{wxList::DeleteObject}

\hy-8{2572}{Bool DeleteObject(wxObject * \hy-8{2573}{object})}

Finds the given client \hy-7{2574}{object} and deletes the appropriate node from the list, returning
TRUE if successful. The application must delete the actual object separately.


\hy-10{2576}{wxList::Find}

\hy-8{2577}{wxNode * Find(long \hy-8{2578}{ key})}

\hy-8{2579}{wxNode * Find(char * \hy-8{2580}{key})}

Returns the node whose stored key matches \hy-7{2581}{key}. Use on a keyed list only.


\hy-10{2583}{wxList::First}

\hy-8{2584}{wxNode * First(void)}

Returns the first node in the list (NULL if the list is empty).


\hy-10{2586}{wxList::Insert}

\hy-8{2587}{wxNode * Insert(wxObject * \hy-8{2588}{object})}

Insert object at front of list.

\hy-8{2589}{wxNode * Insert(wxNode * \hy-8{2590}{position}, wxObject * \hy-8{2591}{object})}

Insert object before \hy-7{2592}{position}.



\hy-10{2594}{wxList::Last}

\hy-8{2595}{wxNode * Last(void)}

Returns the last node in the list (NULL if the list is empty).


\hy-10{2597}{wxList::Member}

\hy-8{2598}{wxNode * Member(wxObject * \hy-8{2599}{object})}

Returns the node associated with \hy-7{2600}{object} if it is in the list, NULL otherwise.


\hy-10{2602}{wxList::Nth}

\hy-8{2603}{wxNode * Nth(int \hy-8{2604}{ n})}

Returns the \hy-7{2605}{nth} node in the list, indexing from zero (NULL if the list is empty
or the nth node could not be found).


\hy-10{2607}{wxList::Number}

\hy-8{2608}{int Number(void)}

Returns the number of elements in the list.


\hy-10{2613}{wxListBox::wxListBox}

\hy-8{2614}{void wxListBox(void)}

Constructor, for deriving classes.

\hy-8{2615}{void wxListBox(wxPanel * \hy-8{2616}{parent}, wxFunction \hy-8{2617}{ func}, char * \hy-8{2618}{label},

  Bool \hy-8{2619}{ multiple_selection = wxSINGLE}, int \hy-8{2620}{ x = -1}, int \hy-8{2621}{ y = -1},

  int \hy-8{2622}{ width = -1}, int \hy-8{2623}{ height = -1}, int \hy-8{2624}{ n}, char * \hy-8{2625}{choices[]},

  int \hy-8{2626}{ style = 0}, char * \hy-8{2627}{name = ``listBox"})}

Constructor, creating and showing a list box.

\hy-7{2628}{func} may be NULL; otherwise it is used as the callback for the
list box.  Note that the cast (wxFunction) must be used when passing
your callback function name, or the compiler may complain that the
function does not match the constructor declaration.

If \hy-7{2629}{label} is non-NULL, it will be used as the listbox label.

The parameters \hy-7{2630}{x} and \hy-7{2631}{y} are used to specify an absolute
position, or a position after the previous panel item if omitted or
default.

If \hy-7{2632}{width} or \hy-7{2633}{height} are omitted (or are less than zero), an
appropriate size will be used for the list box.

\hy-7{2634}{n} is the number of possible choices, and \hy-7{2635}{choices} is an array of strings
of size \hy-7{2636}{n}. wxWindows allocates its own memory for these strings so the
calling program must deallocate the array itself.

\hy-7{2637}{multiple_selection} is one of the following:


\hy-8{2638}{wxSINGLE}  Single-selection list.
\hy-8{2639}{wxMULTIPLE}  Multiple-selection list.
\hy-8{2640}{wxEXTENDED}  Extended-selection list (Motif only).
\hy-8{2641}{wxNEEDED_SB}  Create scrollbars if needed.
\hy-8{2642}{wxALWAYS_SB}  Created scrollbars immediately.


\hy-7{2643}{style} is unused at present.

The \hy-7{2644}{name} parameter is used to associate a name with the item,
allowing the application user to set Motif resource values for
individual listboxes.


\hy-10{2646}{wxListBox::~wxListBox}

\hy-8{2647}{void ~wxListBox(void)}

Destructor, destroying the list box.


\hy-10{2649}{wxListBox::Append}

\hy-8{2650}{void Append(char * \hy-8{2651}{ item})}

Adds the item to the end of the list box. \hy-7{2652}{item} must be deallocated by the calling
program, i.e. wxWindows makes its own copy.

\hy-8{2653}{void Append(char * \hy-8{2654}{ item}, char * \hy-8{2655}{client_data})}

Adds the item to the end of the list box, associating the given data
with the item. \hy-7{2656}{item} must be deallocated by the calling program.


\hy-10{2658}{wxListBox::Clear}

\hy-8{2659}{void Clear(void)}

Clears all strings from the list box.


\hy-10{2661}{wxListBox::Create}

\hy-8{2662}{Bool Create(wxPanel * \hy-8{2663}{parent}, wxFunction \hy-8{2664}{ func}, char * \hy-8{2665}{label},

  Bool \hy-8{2666}{ multiple_selection = FALSE}, int \hy-8{2667}{ x = -1}, int \hy-8{2668}{ y = -1},

  int \hy-8{2669}{ width = -1}, int \hy-8{2670}{ height = -1}, int \hy-8{2671}{ n}, char * \hy-8{2672}{choices[]},

  int \hy-8{2673}{ style = 0}, char * \hy-8{2674}{name = ``listBox"})}

Creates the listbox for two-step construction. Derived classes
should call or replace this function. See \hy-13{2675}{wxListBox::wxListBox}
for further details.


\hy-10{2677}{wxListBox::Delete}

\hy-8{2678}{void Delete(int \hy-8{2679}{ n})}

Delete the nth element in the list box.


\hy-10{2681}{wxListBox::Deselect}

\hy-8{2682}{void Deselect(int \hy-8{2683}{ n})}

Deselects the given item in the list box.


\hy-10{2685}{wxListBox::FindString}

\hy-8{2686}{int FindString(int \hy-8{2687}{ char *s})}

Finds a choice matching the given string, returning the position if found, or
-1 if not found.


\hy-10{2689}{wxListBox::GetClientData}

\hy-8{2690}{char * GetClientData(int \hy-8{2691}{ n})}

Returns a pointer to the client data associated with the given item (if any).


\hy-10{2693}{wxListBox::GetSelection}

\hy-8{2694}{int GetSelection(void)}

Gets the id (position) of the selected string - for single selection list boxes only.


\hy-10{2696}{wxListBox::GetSelections}

\hy-8{2697}{int GetSelections(int ** \hy-8{2698}{selections})}

Gets an array containing the positions of the selected strings. The number of selections
is returned.  Pass a pointer to an integer array, and do not deallocate the returned array.


\hy-10{2700}{wxListBox::GetStringSelection}

\hy-8{2701}{char * GetStringSelection(void)}

Gets the selected string - for single selection list boxes only. This
must be copied by the calling program if long term use is to be made of
it.


\hy-10{2703}{wxListBox::Selected}

\hy-8{2704}{Bool Selected(int \hy-8{2705}{ n})}

Returns TRUE if the given item is selected, FALSE otherwise.


\hy-10{2707}{wxListBox::Set}

\hy-8{2708}{void Set(int \hy-8{2709}{ n}, char * \hy-8{2710}{choices[]})}

Clears the list box and adds the given strings. Deallocate the array from the calling program
after this function has been called.


\hy-10{2712}{wxListBox::SetFirstItem}

\hy-8{2713}{void SetFirstItem(int \hy-8{2714}{ n})}
\hy-8{2715}{void SetFirstItem(char * \hy-8{2716}{item})}

Set the specified item to be the first visible item (not XView).


\hy-10{2718}{wxListBox::SetSelection}

\hy-8{2719}{void SetSelection(int \hy-8{2720}{ n}, Bool \hy-8{2721}{select = TRUE})}

Selects or deselects the given item.


\hy-10{2723}{wxListBox::SetStringSelection}

\hy-8{2724}{void SetStringSelection(char * \hy-8{2725}{ s})}

Sets the choice by passing the desired string.


\hy-10{2727}{wxListBox::GetString}

\hy-8{2728}{char * GetString(int \hy-8{2729}{ n})}

Returns a temporary pointer to the string at position \hy-7{2730}{n}.


\hy-10{2739}{wxMemoryDC::wxMemoryDC}

\hy-8{2740}{void wxMemoryDC(void)}

Constructs a new memory device context.

\hy-8{2741}{void wxMemoryDC(wxCanvasDC * \hy-8{2742}{oldDC})}

Constructs a new memory device context with similar attributes to the
given canvas device context.

Use the \hy-7{2743}{Ok} member to test whether the constructor was successful
in creating a useable device context. Don't forget to select a bitmap
into the DC before drawing on it.


\hy-10{2745}{wxMemoryDC::SelectObject}

\hy-8{2746}{void SelectObject(wxBitmap * \hy-8{2747}{bitmap})}

Selects the given bitmap into the device context, to use as the memory
bitmap. Selecting the bitmap into a memory DC allows you to draw into
the DC (and therefore the bitmap) and also to use \hy-8{2748}{Blit} to copy
the bitmap to a canvas. For this purpose, you may find \hy-13{2749}{wxDC::DrawIcon}
easier to use instead.


\hy-10{2755}{wxMenu::wxMenu}

\hy-8{2756}{void wxMenu(char * \hy-8{2757}{title = NULL}, wxFunction \hy-8{2758}{ func = NULL})}

The first argument is presently ignored. The second argument is 
a callback function if the menu is used as a popup using \hy-13{2759}{wxWindow::PopupMenu}.


\hy-10{2761}{wxMenu::~wxMenu}

\hy-8{2762}{void ~wxMenu(void)}

Destructor, destroying the menu.


\hy-10{2764}{wxMenu::Append}

\hy-8{2765}{void Append(int \hy-8{2766}{ id}, char * \hy-8{2767}{ item}, char * \hy-8{2768}{helpString = NULL})}

\hy-8{2769}{void Append(int \hy-8{2770}{ id}, char * \hy-8{2771}{ item}, wxMenu * \hy-8{2772}{submenu},
  char * \hy-8{2773}{helpString = NULL})}

Adds the item to the end of the menu. \hy-7{2774}{item} must be deallocated by the calling
program.  If the second form is used, the given menu will be a pullright submenu (must be
created already).  Do not use \hy-7{2775}{submenu} after this call: it will be deallocated by
wxWindows.

Each form can take an optional help string, which can be accessed using
\hy-8{2776}{wxMenu::GetHelpString}. The default \hy-8{2777}{wxFrame::OnMenuSelect} member
uses this help string to give help on the menu item currently under the
cursor.


\hy-10{2779}{wxMenu::AppendSeparator}

\hy-8{2780}{void AppendSeparator(void)}

Adds a separator to the end of the menu. Under XView, this appears as
a space.


\hy-10{2782}{wxMenu::Check}

\hy-8{2783}{void Check(int \hy-8{2784}{ id}, Bool \hy-8{2785}{ flag})}

If \hy-7{2786}{flag} is TRUE, checks the given menu item, else unchecks it.
Works in Windows 3 but has no effect in XView or Motif.


\hy-10{2788}{wxMenu::Enable}

\hy-8{2789}{void Enable(int \hy-8{2790}{ id}, Bool \hy-8{2791}{ flag})}

If \hy-7{2792}{flag} is TRUE, enables the given menu item, else disables it
(greys it).


\hy-10{2794}{wxMenu::FindItem}

\hy-8{2795}{int FindItem(char * \hy-8{2796}{itemString})}

Finds the menu item id for a menu item string, or -1 if none found.
Any special menu codes are stripped out of source and target strings
before matching.


\hy-10{2798}{wxMenu::FindItemForId}

\hy-8{2799}{wxMenuItem * FindItemForId(int \hy-8{2800}{ itemId})}

Finds the menu item object associated with the given menu item identifier,
returning NULL if not found.


\hy-10{2802}{wxMenu::GetHelpString}

\hy-8{2803}{char * GetHelpString(int \hy-8{2804}{ itemId})}

Gets a temporary pointer to the help string associated with the menu
item identifer (or NULL if there is no help string or the item was not
found).


\hy-10{2806}{wxMenu::GetLabel}

\hy-8{2807}{char * GetLabel(int \hy-8{2808}{ id})}

Gets a temporary pointer to the label of the given menu item; copy this for
long-term use. \hy-7{2809}{id} is the identifier given to \hy-13{2810}{wxMenu::Append}.


\hy-10{2812}{wxMenu::GetTitle}

\hy-8{2813}{char * GetTitle(void)}

Gets a temporary pointer to the title of the menu.


\hy-10{2815}{wxMenu::SetHelpString}

\hy-8{2816}{void SetHelpString(int \hy-8{2817}{ itemId}, char * \hy-8{2818}{helpString})}

Sets the help string associated with the menu item identifer.


\hy-10{2820}{wxMenu::SetLabel}

\hy-8{2821}{void SetLabel(int \hy-8{2822}{ id}, char * \hy-8{2823}{label})}

Sets the label of the given menu item (using the identifier used to
append the item to the menu).


\hy-10{2825}{wxMenu::SetTitle}

\hy-8{2826}{void SetTitle(char * \hy-8{2827}{title})}

Sets the title of the menu.



\hy-10{2832}{wxMenuBar::wxMenuBar}

\hy-8{2833}{void wxMenuBar(void)}

\hy-8{2834}{void wxMenuBar(int \hy-8{2835}{ n}, wxMenu * \hy-8{2836}{menus[]}, char * \hy-8{2837}{titles[]})}

Construct a menu bar. In the second form, the calling program must have
created an array of menus and an array of titles. Do not use the
submenus again after this call.


\hy-10{2839}{wxMenuBar::~wxMenuBar}

\hy-8{2840}{void ~wxMenuBar(void)}

Destructor, destroying the menu bar and removing it from the parent frame (if any).


\hy-10{2842}{wxMenuBar::Append}

\hy-8{2843}{void Append(wxMenu * \hy-8{2844}{menu}, char * \hy-8{2845}{title})}

Adds the item to the end of the menu bar. Do not use \hy-7{2846}{menu} after
this call: it will be deallocated by wxWindows.


\hy-10{2848}{wxMenuBar::Check}

\hy-8{2849}{void Check(int \hy-8{2850}{ id}, Bool \hy-8{2851}{ flag})}

If \hy-7{2852}{flag} is TRUE, checks the given menu item, else unchecks it.
Works in Windows but has no effect in XView or Motif. Only use this when the menu
bar has been associated with a frame; otherwise, use the wxMenu
equivalent call.


\hy-10{2854}{wxMenuBar::Enable}

\hy-8{2855}{void Enable(int \hy-8{2856}{ id}, Bool \hy-8{2857}{ flag})}

If \hy-7{2858}{flag} is TRUE, enables the given menu item, else disables it
(greys it). Only use this when the menu bar has been associated with a
frame; otherwise, use the wxMenu equivalent call.


\hy-10{2860}{wxMenuBar::EnableTop}

\hy-8{2861}{void EnableTop(int \hy-8{2862}{ pos}, Bool \hy-8{2863}{ flag})}

If \hy-7{2864}{flag} is TRUE, enables the menu at the given position, else
disables it (greys it). Only use this when the menu bar has been
associated with a frame.


\hy-10{2866}{wxMenuBar::FindMenuItem}

\hy-8{2867}{int FindMenuItem(char * \hy-8{2868}{menuString}, char * \hy-8{2869}{itemString})}

Finds the menu item id for a menu name/menu item string pair, or -1 if none found.
Any special menu codes are stripped out of source and target strings
before matching.


\hy-10{2871}{wxMenuBar::FindItemById}

\hy-8{2872}{wxMenuItem * FindItemById(int \hy-8{2873}{ itemId})}

Finds the menu item object associated with the given menu item identifier,
returning NULL if not found.


\hy-10{2875}{wxMenuBar::GetHelpString}

\hy-8{2876}{char * GetHelpString(int \hy-8{2877}{ itemId})}

Gets the help string associated with the menu item identifer (or NULL if
there is no help string or the item was not found).


\hy-10{2879}{wxMenuBar::GetLabel}

\hy-8{2880}{char * GetLabel(int \hy-8{2881}{ itemId})}

Returns a temporary pointer to the label of the given menu item. Use only
after the menubar has been associated with a frame with \hy-8{2882}{
wxFrame::SetMenuBar}.


\hy-10{2884}{wxMenuBar::GetLabelTop}

\hy-8{2885}{char * GetLabelTop(int \hy-8{2886}{ pos})}

Returns a temporary pointer to the label of the given top-level menu. \hy-7{2887}{
pos} is the position of a menu on the menu bar. Use only after the
menubar has been associated with a frame with \hy-8{2888}{wxFrame::SetMenuBar}.


\hy-10{2890}{wxMenuBar::SetHelpString}

\hy-8{2891}{void SetHelpString(int \hy-8{2892}{ itemId}, char * \hy-8{2893}{helpString})}

Sets the help string associated with the menu item identifer.


\hy-10{2895}{wxMenuBar::SetLabel}

\hy-8{2896}{void SetLabel(int \hy-8{2897}{ itemId}, char * \hy-8{2898}{label})}

Sets the label of the given menu item. Use only after the menubar
has been associated with a frame with \hy-8{2899}{wxFrame::SetMenuBar}.


\hy-10{2901}{wxMenuBar::SetLabelTop}

\hy-8{2902}{void SetLabelTop(int \hy-8{2903}{ pos}, char * \hy-8{2904}{label})}

Sets the label of the given top-level menu. \hy-7{2905}{pos} is the position of
a menu on the menu bar. Use only after the menubar has been associated
with a frame with \hy-8{2906}{wxFrame::SetMenuBar}.


\hy-10{2910}{wxMessage::wxMessage}

\hy-8{2911}{void wxMessage(void)}

Constructor, used for deriving classes.

\hy-8{2912}{void wxMessage(wxPanel * \hy-8{2913}{panel}, char * \hy-8{2914}{message}, int  \hy-8{2915}{x = -1}, int  \hy-8{2916}{y = -1},

  int \hy-8{2917}{ style = 0}, char * \hy-8{2918}{name = ``message"})}

Creates and displays a simple text message. \hy-7{2919}{message} is the initial
value of the message.

The parameters \hy-7{2920}{x} and \hy-7{2921}{y} are used to specify an absolute
position, or a position after the previous panel item if omitted or
default.

The \hy-7{2922}{name} parameter is used to associate a name with the item,
allowing the application user to set Motif resource values for
individual message items.


\hy-10{2924}{wxMessage::~wxMessage}

\hy-8{2925}{void ~wxMessage(void)}

Destroys the message.


\hy-10{2927}{wxMessage::Create}

\hy-8{2928}{Bool Create(wxPanel * \hy-8{2929}{panel}, char * \hy-8{2930}{message}, int  \hy-8{2931}{x = -1}, int  \hy-8{2932}{y = -1},

  int \hy-8{2933}{ style = 0}, char * \hy-8{2934}{name = ``message"})}

Creates the listbox for two-step construction. Derived classes
should call or replace this function. See \hy-13{2935}{wxMessage::wxMessage}
for further details.


\hy-10{2940}{wxMetaFile::wxMetaFile}

\hy-8{2941}{void wxMetaFile(void)}

Constructor.


\hy-10{2943}{wxMetaFile::~wxMetaFile}

\hy-8{2944}{void ~wxMetaFile(void)}

Destructor.


\hy-10{2946}{wxMetaFile::SetClipboard}

\hy-8{2947}{Bool SetClipboard(int \hy-8{2948}{ width = 0}, int \hy-8{2949}{ height = 0})}

Passes the metafile data to the clipboard. The metafile can no longer be
used for anything, but the wxMetaFile object must still be destroyed by
the application.

Below is a example of metafle, metafile device context and clipboard use
from the \hy-14{2950}{hello.cc} example. Note the way the metafile dimensions
are passed to the clipboard, making use of the device context's ability
to keep track of the maximum extent of drawing commands.

\hy-14{2951}{  wxMetaFileDC dc;
  if (dc.Ok())
  {
    Draw(dc, FALSE);
    wxMetaFile *mf = dc.Close();
    if (mf)
    {
      Bool success = mf->SetClipboard((int)(dc.MaxX() + 10), (int)(dc.MaxY() + 10));
      delete mf;
    }
  }
}


\hy-10{2959}{wxMetaFileDC::wxMetaFileDC}

\hy-8{2960}{void wxMetaFileDC(char * \hy-8{2961}{filename = NULL})}

Constructor. If no filename is passed, the metafile is created
in memory.


\hy-10{2963}{wxMetaFileDC::~wxMetaFileDC}

\hy-8{2964}{void ~wxMetaFileDC(void)}

Destructor.


\hy-10{2966}{wxMetaFileDC::Close}

\hy-8{2967}{wxMetaFile * Close(void)}

This must be called after the device context is finished with. A
metafile is returned, and ownership of it passes to the calling
application (so it should be destroyed explicitly).


\hy-10{2972}{wxMouseEvent::controlDown}

\hy-8{2973}{Bool  controlDown}

TRUE if control key is pressed down.


\hy-10{2975}{wxMouseEvent::leftDown}

\hy-8{2976}{Bool  leftDown}

TRUE if the left mouse button is currently pressed down.


\hy-10{2978}{wxMouseEvent::middleDown}

\hy-8{2979}{Bool  middleDown}

TRUE if the middle mouse button is currently pressed down.


\hy-10{2981}{wxMouseEvent::rightDown}

\hy-8{2982}{Bool  rightDown}

TRUE if the right mouse button is currently pressed down.


\hy-10{2984}{wxMouseEvent::leftDown}

\hy-8{2985}{Bool  leftDown}

TRUE if the left mouse button is currently pressed down.


\hy-10{2987}{wxMouseEvent::shiftDown}

\hy-8{2988}{Bool  shiftDown}

TRUE if shift is pressed down.


\hy-10{2990}{wxMouseEvent::x}

\hy-8{2991}{float  x}

X-coordinate of the event.


\hy-10{2993}{wxMouseEvent::y}

\hy-8{2994}{float  y}

Y-coordinate of the event.


\hy-10{2996}{wxMouseEvent::wxMouseEvent}

\hy-8{2997}{void wxMouseEvent(WXTYPE \hy-8{2998}{ mouseEventType})}

Constructor. Valid event types are:


\hy-8{2999}{o}  \hy-8{3000}{wxEVENT_TYPE_LEFT_DOWN}
\hy-8{3001}{o}  \hy-8{3002}{wxEVENT_TYPE_LEFT_UP}
\hy-8{3003}{o}  \hy-8{3004}{wxEVENT_TYPE_MIDDLE_DOWN}
\hy-8{3005}{o}  \hy-8{3006}{wxEVENT_TYPE_MIDDLE_UP}
\hy-8{3007}{o}  \hy-8{3008}{wxEVENT_TYPE_RIGHT_DOWN}
\hy-8{3009}{o}  \hy-8{3010}{wxEVENT_TYPE_RIGHT_UP}
\hy-8{3011}{o}  \hy-8{3012}{wxEVENT_TYPE_MOTION}



\hy-10{3014}{wxMouseEvent::Button}

\hy-8{3015}{Bool Button(int \hy-8{3016}{ button})}

Returns TRUE if the identified mouse button is changing state. Valid
values of \hy-7{3017}{button} are 1, 2 or 3 for left, middle and right
buttons respectively.

Not all mice have middle buttons so a portable application should avoid
this one.


\hy-10{3019}{wxMouseEvent::ButtonDown}

\hy-8{3020}{Bool ButtonDown(int \hy-8{3021}{ but = -1})}

If the argument is omitted, this returns TRUE if the event was a mouse
button down event. Otherwise the argument specifies which button-down event
was generated (1, 2 or 3 for left, middle and right buttons respectively).


\hy-10{3023}{wxMouseEvent::ControlDown}

\hy-8{3024}{Bool ControlDown(void)}

Returns TRUE if the control key was down at the time of the event.


\hy-10{3026}{wxMouseEvent::Dragging}

\hy-8{3027}{Bool Dragging(void)}

Returns TRUE if this was a dragging event (motion while a button is depressed).


\hy-10{3029}{wxMouseEvent::IsButton}

\hy-8{3030}{Bool IsButton(void)}

Returns TRUE if the event was a mouse button event (not necessarily a button down event -
that may be tested using \hy-7{3031}{ButtonDown}).


\hy-10{3033}{wxMouseEvent::LeftDown}

\hy-8{3034}{Bool LeftDown(void)}

Returns TRUE if the left mouse button changed to down.


\hy-10{3036}{wxMouseEvent::LeftIsDown}

\hy-8{3037}{Bool LeftIsDown(void)}

Returns TRUE if the left mouse button is currently down, independent
of the current event type.


\hy-10{3039}{wxMouseEvent::LeftUp}

\hy-8{3040}{Bool LeftUp(void)}

Returns TRUE if the left mouse button changed to up.


\hy-10{3042}{wxMouseEvent::MiddleDown}

\hy-8{3043}{Bool MiddleDown(void)}

Returns TRUE if the middle mouse button changed to down.


\hy-10{3045}{wxMouseEvent::MiddleIsDown}

\hy-8{3046}{Bool MiddleIsDown(void)}

Returns TRUE if the middle mouse button is currently down, independent
of the current event type.


\hy-10{3048}{wxMouseEvent::MiddleUp}

\hy-8{3049}{Bool MiddleUp(void)}

Returns TRUE if the middle mouse button changed to up.


\hy-10{3051}{wxMouseEvent::Moving}

\hy-8{3052}{Bool Moving(void)}

Returns TRUE if this was a motion event (no buttons depressed).


\hy-10{3054}{wxMouseEvent::Position}

\hy-8{3055}{void Position(float * \hy-8{3056}{x}, float * \hy-8{3057}{y})}

Sets *x and *y to the position at which the event occurred. If the
window is a canvas, the position is converted to logical units
(according to the current mapping mode) with scrolling taken into
account. To get back to device units (for example to calculate where on the
screen to place a dialog box associated with a canvas mouse event), use
\hy-8{3058}{wxDC::LogicalToDeviceX} and \hy-8{3059}{wxDC::LogicalToDeviceY}.

For example, the following code calculates screen pixel coordinates
from the frame position, canvas view start (assuming the canvas is the only
subwindow on the frame and therefore at the top left of it), and the
logical event position. A menu is popped up at the position where the
mouse click occurred. (Note that the application should also check that
the dialog box will be visible on the screen, since the click could have
occurred near the screen edge!)

\hy-14{3060}{float event_x, event_y;
event.Position(&event_x, &event_y);
frame->GetPosition(&x, &y);
canvas->ViewStart(&x1, &y1);
int mouse_x = (int)(canvas->GetDC()->LogicalToDeviceX(event_x + x - x1);
int mouse_y = (int)(canvas->GetDC()->LogicalToDeviceY(event_y + y - y1);

char *choice = wxGetSingleChoice("Menu", "Pick a node action",
                                 no_choices, choices, frame, mouse_x, mouse_y);
}


\hy-10{3062}{wxMouseEvent::RightDown}

\hy-8{3063}{Bool RightDown(void)}

Returns TRUE if the right mouse button changed to down.


\hy-10{3065}{wxMouseEvent::RightIsDown}

\hy-8{3066}{Bool RightIsDown(void)}

Returns TRUE if the right mouse button is currently down, independent
of the current event type.


\hy-10{3068}{wxMouseEvent::RightUp}

\hy-8{3069}{Bool RightUp(void)}

Returns TRUE if the right mouse button changed to up.



\hy-10{3071}{wxMouseEvent::ShiftDown}

\hy-8{3072}{Bool ShiftDown(void)}

Returns TRUE if the shift key was down at the time of the event.


\hy-10{3077}{wxMultiText::GetValue}

\hy-8{3078}{char * GetValue(void)}

\hy-8{3079}{void GetValue(char * \hy-8{3080}{buffer}, int \hy-8{3081}{bufferSize})}

The first form gets a temporary pointer to the current value; copy this for
long-term use. The second form copies the value into a buffer, for
situations where a lot of text is returned (more than the capacity of
the small buffer used for the first form).


\hy-10{3086}{wxNode::Data}

\hy-8{3087}{wxObject * Data(void)}

Retrieves the client data pointer associated with the node. This will
have to be cast to the correct type.


\hy-10{3089}{wxNode::Next}

\hy-8{3090}{wxNode * Next(void)}

Retrieves the next node (NULL if at end of list).


\hy-10{3092}{wxNode::Previous}

\hy-8{3093}{wxNode * Previous(void)}

Retrieves the previous node (NULL if at start of list).


\hy-10{3095}{wxNode::SetData}

\hy-8{3096}{void SetData(void)}

Sets the data associated with the node (usually the pointer will have been
set when the node was created).


\hy-10{3100}{wxObject::__type}

\hy-8{3101}{WXTYPE  __type}

Data member used for storing dynamic type information. Most wxWindows
classes set this member to an appropriate type, which may be overridden
in derived classes. Optionally set this in your constructor. The type
may be checked using \hy-13{3102}{::wxSubType}.

Note the double underscore prefixing this name, in order to minimize clashes
with application code. There is no accessor function for this member, and
its scope is public.

See also \hy-13{3103}{wxTypeTree}.


\hy-10{3109}{wxPanel::wxPanel}

\hy-8{3110}{void wxPanel(void)}

Constructor, for deriving classes.

\hy-8{3111}{void wxPanel(wxFrame * \hy-8{3112}{parent}, int \hy-8{3113}{ x = -1}, int \hy-8{3114}{ y = -1}, int \hy-8{3115}{ width = -1}, int \hy-8{3116}{ height = -1},

  int \hy-8{3117}{ style = 0}, char * \hy-8{3118}{name = ``panel"})}

\hy-8{3119}{void wxPanel(wxPanel * \hy-8{3120}{parent}, int \hy-8{3121}{ x = -1}, int \hy-8{3122}{ y = -1}, int \hy-8{3123}{ width = -1}, int \hy-8{3124}{ height = -1},

  int \hy-8{3125}{ style = 0}, char * \hy-8{3126}{name = ``panel"})}

Constructor.

The parameters \hy-7{3127}{x}, \hy-7{3128}{y}, \hy-7{3129}{width} and \hy-7{3130}{height} can be
omitted on construction if the position and size will later be set (for
example by a application frame's \hy-8{3131}{OnSize} callback, or if there is
only one subwindow for the frame, in which case the subwindow fills the
frame).

The style parameter may be a combination of the following, using the bitwise `or' operator.


\hy-8{3132}{o}  \hy-8{3133}{wxABSOLUTE_POSITIONING}: a hint to the windowing system not to try automatic layout
  (Motif only).
\hy-8{3134}{o}  \hy-8{3135}{wxBORDER}: draw a thin border around the panel.
\hy-8{3136}{o}  \hy-8{3137}{wxVSCROLL}: give the dialog box a vertical scrollbar (XView only).


The \hy-7{3138}{name} parameter is used to associate a name with the item,
allowing the application user to set Motif resource values for
individual panels.

The parent window may be a panel in Motif and Windows, but not XView.


\hy-10{3140}{wxPanel::~wxPanel}

\hy-8{3141}{void ~wxPanel(void)}

Destructor.  Deletes any panel items before deleting the physical window.


\hy-10{3143}{wxPanel::Create}

\hy-8{3144}{void Create(wxFrame * \hy-8{3145}{parent}, int \hy-8{3146}{ x = -1}, int \hy-8{3147}{ y = -1}, int \hy-8{3148}{ width = -1}, int \hy-8{3149}{ height = -1},

  int \hy-8{3150}{ style = 0}, char * \hy-8{3151}{name = ``panel"})}

Used in two-step panel construction. See \hy-13{3152}{wxPanel::wxPanel}
for further details.


\hy-10{3154}{wxPanel::Fit}

\hy-8{3155}{void Fit(void)}

Resize the panel to just fit around the panel items. Also works for dialog boxes.


\hy-10{3157}{wxPanel::GetButtonFont}

\hy-8{3158}{wxFont * GetButtonFont(void)}

Get the current font for drawing panel item values.


\hy-10{3160}{wxPanel::GetCursor}

\hy-8{3161}{void GetCursor(int * \hy-8{3162}{x}, int * \hy-8{3163}{y})}

Gets the current panel `cursor' position, i.e. where the next panel item
will be placed.


\hy-10{3165}{wxPanel::GetDefaultItem}

\hy-8{3166}{wxButton * GetDefaultItem(void)}

Retrieves the default button, previously set with \hy-13{3167}{wxButton::SetDefault}.


\hy-10{3169}{wxPanel::GetHorizontalSpacing}

\hy-8{3170}{int GetHorizontalSpacing(void)}

Gets the horizontal spacing for placing items on a panel.


\hy-10{3172}{wxPanel::GetLabelFont}

\hy-8{3173}{wxFont * GetLabelFont(void)}

Get the current font for drawing panel item labels.


\hy-10{3175}{wxPanel::GetVerticalSpacing}

\hy-8{3176}{int GetVerticalSpacing(void)}

Gets the vertical spacing for placing items on a panel.


\hy-10{3178}{wxPanel::NewLine}

\hy-8{3179}{void NewLine(void)}

Cause the next item to be positioned at the beginning of the next line,
using the current vertical spacing. More than one new line in succession
causes extra vertical spacing to be inserted.


\hy-10{3181}{wxPanel::OnDefaultAction}

\hy-8{3182}{void OnDefaultAction(wxItem * \hy-8{3183}{item})}

Called when the user initiates the default action for a panel or
dialog box, for example by double clicking on a listbox. \hy-7{3184}{item}
is the panel item which caused the default action.


The default behaviour for this member is to retrieve the default button
for the panel, and send it a command event, as if the user had clicked
on the button. This gives default listbox double-click behaviour under
Motif and Windows 3. The default code is as follows:

\hy-14{3185}{void wxbPanel::OnDefaultAction(wxItem *initiatingItem)
{
  wxButton *but = GetDefaultItem();
  if (but)
  {
    wxCommandEvent event(wxEVENT_TYPE_BUTTON_COMMAND);
    but->Command(event);
  }
}
}


\hy-10{3187}{wxPanel::SetHorizontalSpacing}

\hy-8{3188}{void SetHorizontalSpacing(int \hy-8{3189}{ sp})}

Sets the horizontal spacing for placing items on a panel.


\hy-10{3191}{wxPanel::SetLabelPosition}

\hy-8{3192}{void SetLabelPosition(int \hy-8{3193}{ position})}

Determines the current method of placing labels on panel items: if \hy-7{3194}{
position} is \hy-14{3195}{wxHORIZONTAL}, labels are placed to the left of the
item value. If \hy-7{3196}{position} is \hy-14{3197}{wxVERTICAL}, the label is placed
above the item value. The default behaviour is to have horizontal label
placing.

Under Windows 3, this function words for \hy-8{3198}{wxText}, \hy-8{3199}{wxChoice}
and \hy-8{3200}{wxListBox}. Under XView, absolute positioning must be used
for the wxVERTICAL position to work in some cases. This is because of
some strange behaviour in XView where setting a horizontal layout
orientation but a vertical label position causes items after list box
to appear too low on the panel. So, where it is necessary to have
vertical labels, use absolute positioning where results are not as
expected.


\hy-10{3202}{wxPanel::SetButtonFont}

\hy-8{3203}{void SetButtonFont(wxFont * \hy-8{3204}{font})}

Specify the font for drawing panel item values (not XView).


\hy-10{3206}{wxPanel::SetLabelFont}

\hy-8{3207}{void SetLabelFont(wxFont * \hy-8{3208}{font})}

Specify the font for drawing panel item labels (not XView).


\hy-10{3210}{wxPanel::SetVerticalSpacing}

\hy-8{3211}{void SetVerticalSpacing(int \hy-8{3212}{ sp})}

Sets the vertical spacing for placing items on a panel.


\hy-10{3214}{wxPanel::Tab}

\hy-8{3215}{void Tab(int \hy-8{3216}{ pixels})}

Tabs by the given number of pixels.


\hy-10{3221}{wxPathList::wxPathList}

\hy-8{3222}{void wxPathList(void)}

Constructor.


\hy-10{3224}{wxPathList::AddEnvList}

\hy-8{3225}{void AddEnvList(char * \hy-8{3226}{env_variable})}

Finds the value of the given environment variable, and adds all paths
to the path list. Useful for finding files in the PATH variable, for
example.


\hy-10{3228}{wxPathList::AddPath}

\hy-8{3229}{void AddPath(char * \hy-8{3230}{path})}

Adds the given directory to the path list.


\hy-10{3232}{wxPathList::FindValidPath}

\hy-8{3233}{char * FindValidPath(char * \hy-8{3234}{file})}

Searches for a full path for an existing file by appending \hy-7{3235}{file} to
successive members of the path list.  If the file exists, a temporary
pointer to the full path is returned.


\hy-10{3237}{wxPathList::Member}

\hy-8{3238}{Bool Member(char * \hy-8{3239}{file})}

TRUE if the path is in the path list (ignoring case).


\hy-10{3248}{wxPen::wxPen}

\hy-8{3249}{void wxPen(void)}

\hy-8{3250}{void wxPen(wxColour & \hy-8{3251}{colour}, int \hy-8{3252}{ width}, int \hy-8{3253}{ style})}

\hy-8{3254}{void wxPen(char * \hy-8{3255}{colour_name}, int \hy-8{3256}{ width}, int \hy-8{3257}{ style})}

Constructs a pen, uninitialized, initialized with an RGB colour, a
width and a style, or initialized using a colour name, a width and a
style.  If the named colour form is used, an appropriate \hy-8{3258}{
wxColour} structure is found in the colour database.


\hy-10{3260}{wxPen::~wxPen}

\hy-8{3261}{void ~wxPen(void)}

Destructor, destroying the pen. Note that pens should very rarely be deleted
since windows may contain pointers to them. All pens will be deleted when the
application terminates.


\hy-10{3263}{wxPen::GetColour}

\hy-8{3264}{wxColour& GetColour(void)}

Returns a reference to the pen colour.


\hy-10{3266}{wxPen::GetStyle}

\hy-8{3267}{int GetStyle(void)}

Returns the pen style.


\hy-10{3269}{wxPen::GetWidth}

\hy-8{3270}{int GetWidth(void)}

Returns the pen width.


\hy-10{3272}{wxPen::SetColour}

\hy-8{3273}{void SetColour(wxColour & \hy-8{3274}{colour})}

\hy-8{3275}{void SetColour(char * \hy-8{3276}{colour_name})}

\hy-8{3277}{void SetColour(int \hy-8{3278}{ red}, int \hy-8{3279}{ green}, int \hy-8{3280}{ blue})}

The pen's colour is changed to the given colour.


\hy-10{3282}{wxPen::SetStyle}

\hy-8{3283}{void SetStyle(int \hy-8{3284}{ style})}

Set the pen style (wxSOLID or wxTRANSPARENT).


\hy-10{3286}{wxPen::SetWidth}

\hy-8{3287}{void SetWidth(int \hy-8{3288}{ width})}

Set the pen width.

\hy-10{3293}{wxPenList::wxPenList}

\hy-8{3294}{void wxPenList(void)}

Constructor.  The application should not construct its own pen list:
use the object pointer \hy-8{3295}{wxThePenList}.


\hy-10{3297}{wxPenList::AddPen}

\hy-8{3298}{void AddPen(wxPen * \hy-8{3299}{pen})}

Used by wxWindows to add a pen to the list, called in the pen constructor.


\hy-10{3301}{wxPenList::FindOrCreatePen}

\hy-8{3302}{wxPen * FindOrCreatePen(wxColour * \hy-8{3303}{colour}, int \hy-8{3304}{ width}, int \hy-8{3305}{ style})}

\hy-8{3306}{wxPen * FindOrCreatePen(char * \hy-8{3307}{colour_name}, int \hy-8{3308}{ width}, int \hy-8{3309}{ style})}

Finds a pen of the given specification, or creates one and adds it to the list.


\hy-10{3311}{wxPenList::RemovePen}

\hy-8{3312}{void RemovePen(wxPen * \hy-8{3313}{pen})}

Used by wxWindows to remove a pen from the list.


\hy-10{3320}{wxPoint::wxPoint}

\hy-8{3321}{void wxPoint(void)}

\hy-8{3322}{void wxPoint(float \hy-8{3323}{ x}, float \hy-8{3324}{ y})}

Create a point.

\hy-8{3325}{float  x}

\hy-8{3326}{float  y}

Members of the \hy-8{3327}{wxPoint} object.


\hy-10{3332}{wxPostScriptDC::wxPostScriptDC}

\hy-8{3333}{void wxPostScriptDC(char * \hy-8{3334}{output}, Bool  \hy-8{3335}{interactive = TRUE})}

Constructor. \hy-7{3336}{output} is an optional file for printing to, and if
\hy-7{3337}{interactive} is TRUE a dialog box will be displayed for adjusting
various parameters.

Use the \hy-7{3338}{Ok} member to test whether the constructor was successful
in creating a useable device context.

The following global variables are defined in wxWindows, edited by the
user in the printer dialog and used by the PostScript driver. An
application may wish to set them to appropriate default values.


\hy-8{3339}{o}  char *wx_portrait = TRUE
\hy-8{3340}{o}  char *wx_printer_command =``lpr''
\hy-8{3341}{o}  char *wx_printer_flags = ``''
\hy-8{3342}{o}  Bool wx_preview = TRUE
\hy-8{3343}{o}  char *wx_preview_command = ``ghostview''
\hy-8{3344}{o}  float wx_printer_scale_x = 1.0
\hy-8{3345}{o}  float wx_printer_scale_y = 1.0
\hy-8{3346}{o}  float wx_printer_translate_x = 0.0
\hy-8{3347}{o}  float wx_printer_translate_y = 0.0
\hy-8{3348}{o}  Bool wx_print_to_file = FALSE



\hy-10{3353}{wxPrinterDC::wxPrinterDC}

\hy-8{3354}{void wxPrinterDC(char * \hy-8{3355}{driver}, char * \hy-8{3356}{device}, char * \hy-8{3357}{output}, Bool  \hy-8{3358}{interactive = TRUE})}

Constructor.  With three NULLs, the default printer dialog is
displayed. \hy-7{3359}{device} indicates the type of printer and \hy-7{3360}{output}
is an optional file for printing to. The \hy-7{3361}{driver} parameter is
currently unused.  Use the \hy-7{3362}{Ok} member to test whether the
constructor was successful in creating a useable device context.


\hy-10{3366}{wxRadioBox::wxRadioBox}

\hy-8{3367}{void wxRadioBox(void)}

Constructor, for use by derived classes.

\hy-8{3368}{void wxRadioBox(wxPanel * \hy-8{3369}{parent}, wxFunction \hy-8{3370}{ func}, char * \hy-8{3371}{label},

  int \hy-8{3372}{ x = -1}, int \hy-8{3373}{ y = -1}, int \hy-8{3374}{ width = -1}, int \hy-8{3375}{ height = -1},

  int \hy-8{3376}{ n}, char * \hy-8{3377}{choices[]}, int \hy-8{3378}{ majorDim = 0}, int \hy-8{3379}{ style = 0}, char * \hy-8{3380}{name = ``radioBox"})}

\hy-8{3381}{void wxRadioBox(wxPanel * \hy-8{3382}{parent}, wxFunction \hy-8{3383}{ func}, char * \hy-8{3384}{label},

  int \hy-8{3385}{ x = -1}, int \hy-8{3386}{ y = -1}, int \hy-8{3387}{ width = -1}, int \hy-8{3388}{ height = -1},

  int \hy-8{3389}{ n}, wxBitmap * \hy-8{3390}{choices[]}, int \hy-8{3391}{ majorDim = 0}, int \hy-8{3392}{ style = 0}, char * \hy-8{3393}{name = ``radioBox"})}

Constructor, creating and showing a radiobox.

\hy-7{3394}{func} may be NULL; otherwise it is used as the callback for the
choice.  Note that the cast (wxFunction) must be used when passing your
callback function name, or the compiler may complain that the function
does not match the constructor declaration.

If \hy-7{3395}{label} is non-NULL, it will be used to label the radiobox.

The parameters \hy-7{3396}{x} and \hy-7{3397}{y} are used to specify an absolute
position, or a position after the previous panel item if omitted or
default.

If \hy-7{3398}{width} or \hy-7{3399}{height} are omitted (or are less than zero), an
appropriate size will be used for the radiobox.

\hy-7{3400}{n} is the number of possible choices, and \hy-7{3401}{choices} is an
array of strings or bitmaps of size \hy-7{3402}{n}. wxWindows allocates its own memory
for these strings so the calling program must deallocate the array
itself.

\hy-7{3403}{majorDim} specifies the number of rows for a two-dimensional
radiobox.

\hy-7{3404}{style} specifies a bitwise-or list of styles (none so far).

The \hy-7{3405}{name} parameter is used to associate a name with the item,
allowing the application user to set Motif resource values for
individual radioboxes.


\hy-10{3407}{wxRadioBox::~wxRadioBox}

\hy-8{3408}{void ~wxRadioBox(void)}

Destructor, destroying the radiobox item.


\hy-10{3410}{wxRadioBox::Create}

\hy-8{3411}{Bool Create(wxPanel * \hy-8{3412}{parent}, wxFunction \hy-8{3413}{ func}, char * \hy-8{3414}{label}, 

  int \hy-8{3415}{ x = -1}, int \hy-8{3416}{ y = -1}, int \hy-8{3417}{ width = -1}, int \hy-8{3418}{ height = -1},

  int \hy-8{3419}{ n}, char * \hy-8{3420}{choices[]}, int \hy-8{3421}{ majorDim = 0}, int \hy-8{3422}{ style = 0}, char * \hy-8{3423}{name = ``radioBox"})}

\hy-8{3424}{Bool Create(wxPanel * \hy-8{3425}{parent}, wxFunction \hy-8{3426}{ func}, char * \hy-8{3427}{label}, 

  int \hy-8{3428}{ x = -1}, int \hy-8{3429}{ y = -1}, int \hy-8{3430}{ width = -1}, int \hy-8{3431}{ height = -1},

  int \hy-8{3432}{ n}, wxBitmap * \hy-8{3433}{choices[]}, int \hy-8{3434}{ majorDim = 0}, int \hy-8{3435}{ style = 0}, char * \hy-8{3436}{name = ``radioBox"})}

Creates the choice for two-step construction. Derived classes
should call or replace this function. See \hy-13{3437}{wxRadioBox::wxRadioBox}
for further details.


\hy-10{3439}{wxRadioBox::Enable}

\hy-8{3440}{void Enable(Bool \hy-8{3441}{ enable})}

Enables or disables the entire radiobox.

\hy-8{3442}{void Enable(int \hy-8{3443}{ n}, Bool \hy-8{3444}{ enable})}

Enables or disables an individual button in the radiobox (does nothing
in XView).


\hy-10{3446}{wxRadioBox::FindString}

\hy-8{3447}{int FindString(char * \hy-8{3448}{s})}

Finds a choice matching the given string, returning the position if found, or
-1 if not found.


\hy-10{3450}{wxRadioBox::GetSelection}

\hy-8{3451}{int GetSelection(void)}

Gets the id (position) of the selected string.


\hy-10{3453}{wxRadioBox::GetStringSelection}

\hy-8{3454}{char * GetStringSelection(void)}

Gets the selected string. This must be copied by the calling program
if long term use is to be made of it.


\hy-10{3456}{wxRadioBox::Number}

\hy-8{3457}{int Number(void)}

Returns the number of choices in the radiobox.


\hy-10{3459}{wxRadioBox::SetSelection}

\hy-8{3460}{void SetSelection(int \hy-8{3461}{ n})}

Sets the choice by passing the desired string position.


\hy-10{3463}{wxRadioBox::SetStringSelection}

\hy-8{3464}{void SetStringSelection(char * \hy-8{3465}{ s})}

Sets the choice by passing the desired string.


\hy-10{3467}{wxRadioBox::GetString}

\hy-8{3468}{char * GetString(int \hy-8{3469}{ n})}

Returns a temporary pointer to the string at position \hy-7{3470}{n}.


\hy-10{3475}{wxServer::wxServer}

\hy-8{3476}{void wxServer(void)}

Constructs a server object.


\hy-10{3478}{wxServer::Create}

\hy-8{3479}{Bool Create(char * \hy-8{3480}{service})}

Registers the server using the given service name. Under UNIX, the
string must contain an integer id which is used as an Internet port
number. FALSE is returned if the call failed (for example, the port
number is already in use).


\hy-10{3482}{wxServer::OnAcceptConnection}

\hy-8{3483}{wxConnection * OnAcceptConnection(char * \hy-8{3484}{topic})}

When a client calls \hy-8{3485}{MakeConnection}, the server receives the
message and this member is called. The application should derive a
member to intercept this message and return a connection object of
either the standard wxConnection type, or of a user-derived type. If the
topic is ``STDIO'', the application may wish to refuse the connection.
Under UNIX, when a server is created the OnAcceptConnection message is
always sent for standard input and output, but in the context of DDE
messages it doesn't make a lot of sense.


\hy-10{3489}{wxSlider::wxSlider}

\hy-8{3490}{void wxSlider(wxPanel * \hy-8{3491}{parent}, wxFunction \hy-8{3492}{ func}, char * \hy-8{3493}{label},

  int \hy-8{3494}{ value}, int \hy-8{3495}{ min_value}, int \hy-8{3496}{ max_value}, int \hy-8{3497}{ width},

  int \hy-8{3498}{ x = -1}, int \hy-8{3499}{ y = -1}, int \hy-8{3500}{ style = 0}, char * \hy-8{3501}{name = ``slider"})}

Constructor, creating and showing a horizontal slider.

\hy-7{3502}{func} may be NULL; otherwise it is used as the callback for the
slider.  Note that the cast (wxFunction) must be used when passing your
callback function name, or the compiler may complain that the function
does not match the constructor declaration.

If \hy-7{3503}{label} is non-NULL, it will be used to label the slider.

The parameters \hy-7{3504}{x} and \hy-7{3505}{y} are used to specify an absolute
position, or a position after the previous panel item if omitted or
default.

The \hy-7{3506}{width} is in pixels, and the scroll increment will be adjusted
to a suitable value given the minimum and maximum integer values.

The \hy-7{3507}{name} parameter is used to associate a name with the item,
allowing the application user to set Motif resource values for
individual sliders.


\hy-10{3509}{wxSlider::~wxSlider}

\hy-8{3510}{void ~wxSlider(void)}

Destructor, destroying the slider.


\hy-10{3512}{wxSlider::Create}

\hy-8{3513}{void Create(wxPanel * \hy-8{3514}{parent}, wxFunction \hy-8{3515}{ func}, char * \hy-8{3516}{label},

  int \hy-8{3517}{ value}, int \hy-8{3518}{ min_value}, int \hy-8{3519}{ max_value}, int \hy-8{3520}{ width},

  int \hy-8{3521}{ x = -1}, int \hy-8{3522}{ y = -1}, int \hy-8{3523}{ style = 0}, char * \hy-8{3524}{name = ``slider"})}

Used for two-step slider construction. See \hy-13{3525}{wxSlider::wxSlider}
for further details.


\hy-10{3527}{wxSlider::GetValue}

\hy-8{3528}{int GetValue(void)}

Gets the current slider value.


\hy-10{3530}{wxSlider::SetValue}

\hy-8{3531}{void SetValue(int \hy-8{3532}{ value})}

Sets the value (and displayed position) of the slider).


\hy-10{3537}{wxStringList::wxStringList}

\hy-8{3538}{void wxStringList(void)}

Constructor.

\hy-8{3539}{void wxStringList(char * \hy-8{3540}{first}, ...)}

Constructor, taking NULL-terminated string argument list. wxStringList
allocates memory for the strings.


\hy-10{3542}{wxStringList::~wxStringList}

\hy-8{3543}{void ~wxStringList(void)}

Deletes string list, deallocating strings.


\hy-10{3545}{wxStringList::Add}

\hy-8{3546}{void Add(char * \hy-8{3547}{s})}

Adds string to list, allocating memory.


\hy-10{3549}{wxStringList::Delete}

\hy-8{3550}{void Delete(char * \hy-8{3551}{s})}

Searches for string and deletes from list, deallocating memory.


\hy-10{3553}{wxStringList::ListToArray}

\hy-8{3554}{char ** ListToArray(Bool \hy-8{3555}{ new_copies = FALSE})}

Converts the list to an array of strings, only allocating new memory if
\hy-8{3556}{new_copies} is TRUE.


\hy-10{3558}{wxStringList::Member}

\hy-8{3559}{Bool Member(char * \hy-8{3560}{s})}

Returns TRUE if \hy-8{3561}{s} is a member of the list (tested using \hy-8{3562}{strcmp}).


\hy-10{3564}{wxStringList::Sort}

\hy-8{3565}{void Sort(void)}

Sorts the strings in ascending alphabetical order. Note that all nodes
(but not strings) get deallocated and new ones allocated.


\hy-10{3569}{wxText::wxText}

\hy-8{3570}{void wxText(void)}

Constructor, for deriving classes.

\hy-8{3571}{void wxText(wxPanel * \hy-8{3572}{parent}, wxFunction \hy-8{3573}{ func}, char * \hy-8{3574}{label},

  char * \hy-8{3575}{value = ``"}, int \hy-8{3576}{ x = -1}, int \hy-8{3577}{ y = -1}, int \hy-8{3578}{ width = -1}, int \hy-8{3579}{ height = -1},

  int \hy-8{3580}{ style = 0}, char * \hy-8{3581}{name = ``text"})}

Constructor, creating and showing a text item with the given string
value. 

\hy-7{3582}{func} may be NULL; otherwise it is used as the callback for the
list box.  Note that the cast (wxFunction) must be used when passing
your callback function name, or the compiler may complain that the
function does not match the constructor declaration.

If \hy-7{3583}{label} is non-NULL, it will be used to label the text item.

The parameters \hy-7{3584}{x} and \hy-7{3585}{y} are used to specify an absolute
position, or a position after the previous panel item if omitted or
default.

If \hy-7{3586}{width} or \hy-7{3587}{height} are omitted (or are less than zero), an
appropriate size will be used for the item.

The \hy-7{3588}{name} parameter is used to associate a name with the item,
allowing the application user to set Motif resource values for
individual text items.


\hy-10{3590}{wxText::~wxText}

\hy-8{3591}{void ~wxText(void)}

Destructor, destroying the text item.


\hy-10{3593}{wxText::Create}

\hy-8{3594}{Bool Create(wxPanel * \hy-8{3595}{parent}, wxFunction \hy-8{3596}{ func}, char * \hy-8{3597}{label},

  char * \hy-8{3598}{value = ``"}, int \hy-8{3599}{ x = -1}, int \hy-8{3600}{ y = -1}, int \hy-8{3601}{ width = -1}, int \hy-8{3602}{ height = -1},

  int \hy-8{3603}{ style = 0}, char * \hy-8{3604}{name = ``text"})}

Creates the text item for two-step construction. Derived classes
should call or replace this function. See \hy-13{3605}{wxText::wxText}
for further details.


\hy-10{3607}{wxText::GetValue}

\hy-8{3608}{char * GetValue(void)}

Gets a pointer to the current value. Copy this for long-term use.


\hy-10{3610}{wxText::SetValue}

\hy-8{3611}{void SetValue(char * \hy-8{3612}{ value})}

Sets the text. \hy-7{3613}{value} must be deallocated by the calling program.


\hy-10{3617}{wxTextWindow::wxTextWindow}

\hy-8{3618}{void wxTextWindow(void)}

Constructor, for deriving classes.

\hy-8{3619}{void wxTextWindow(wxFrame * \hy-8{3620}{parent}, int \hy-8{3621}{ x = -1}, int \hy-8{3622}{ y = -1},

  int \hy-8{3623}{ width = -1}, int \hy-8{3624}{ height = -1}, int \hy-8{3625}{ style = 0}, char * \hy-8{3626}{name = ``textWindow"})}

Constructor.

The parameters \hy-7{3627}{x}, \hy-7{3628}{y}, \hy-7{3629}{width} and \hy-7{3630}{height} can be
omitted on construction if the position and size will later be set (for
example by a application frame's \hy-8{3631}{OnSize} callback, or if there is
only one subwindow for the frame, in which case the subwindow fills the
frame).

Set style to wxBORDER to draw a thin border in Windows 3.

The \hy-7{3632}{name} parameter is used to associate a name with the item,
allowing the application user to set Motif resource values for
individual text windows.


\hy-10{3634}{wxTextWindow::~wxTextWindow}

\hy-8{3635}{void ~wxTextWindow(void)}

Destructor.  Deletes any stored text before deleting the physical window.


\hy-10{3637}{wxTextWindow::Clear}

\hy-8{3638}{void Clear(void)}

Clears the window and deletes the stored text.


\hy-10{3640}{wxTextWindow::Create}

\hy-8{3641}{Bool Create(wxFrame * \hy-8{3642}{parent}, int \hy-8{3643}{ x = -1}, int \hy-8{3644}{ y = -1},

  int \hy-8{3645}{ width = -1}, int \hy-8{3646}{ height = -1}, int \hy-8{3647}{ style = 0}, char * \hy-8{3648}{name = ``textWindow"})}

Creates the text item for two-step construction. Derived classes
should call or replace this function. See \hy-13{3649}{wxTextWindow::wxTextWindow}
for further details.


\hy-10{3651}{wxTextWindow::DiscardEdits}

\hy-8{3652}{void DiscardEdits(void)}

Clears the window and deletes the stored text (same as \hy-8{3653}{Clear}).


\hy-10{3655}{wxTextWindow::GetContents}

\hy-8{3656}{char * GetContents(void)}

Gets a pointer to a newly allocated buffer containing the text window contents.
Free the buffer with the C++ delete operator.


\hy-10{3658}{wxTextWindow::GetInsertionPoint}

\hy-8{3659}{long GetInsertionPoint(void)}

Gets the current insertion point (XView only).


\hy-10{3661}{wxTextWindow::GetLastPosition}

\hy-8{3662}{long GetLastPosition(void)}

Gets the position representing the end of the text window contents.
XView only.


\hy-10{3664}{wxTextWindow::GetLineLength}

\hy-8{3665}{int GetLineLength(long \hy-8{3666}{ lineNo})}

Gets the length of the specified line (starting from zero).


\hy-10{3668}{wxTextWindow::GetLineText}

\hy-8{3669}{int GetLineText(long \hy-8{3670}{ lineNo}, char * \hy-8{3671}{buffer})}

Puts the contents of the specified line (starting from zero) into
the given buffer, returning the number of characters copied.


\hy-10{3673}{wxTextWindow::GetNumberOfLines}

\hy-8{3674}{int GetNumberOfLines(void)}

Gets the number of lines in the text window buffer.


\hy-10{3676}{wxTextWindow::Highlight}

\hy-8{3677}{void Highlight(long  \hy-8{3678}{from}, long  \hy-8{3679}{to})}

Highlights (selects) the text between \hy-7{3680}{from} and \hy-7{3681}{to}. XView only.


\hy-10{3683}{wxTextWindow::LoadFile}

\hy-8{3684}{Bool LoadFile(char * \hy-8{3685}{ file})}

Loads and displays the named file, if it exists. Success is indicated by a return
value of TRUE.


\hy-10{3687}{wxTextWindow::Modified}

\hy-8{3688}{Bool Modified(void)}

Returns TRUE if the text has been modified. Under Windows 3, this always returns
FALSE.


\hy-10{3690}{wxTextWindow::Remove}

\hy-8{3691}{void Remove(long  \hy-8{3692}{from}, long  \hy-8{3693}{to})}

Removes the text between \hy-7{3694}{from} and \hy-7{3695}{to}. XView only.


\hy-10{3697}{wxTextWindow::Replace}

\hy-8{3698}{void Replace(long  \hy-8{3699}{from}, long  \hy-8{3700}{to}, char * \hy-8{3701}{value})}

Replaces the text between \hy-7{3702}{from} and \hy-7{3703}{to} with \hy-7{3704}{value}. XView only.


\hy-10{3706}{wxTextWindow::SetFont}

\hy-8{3707}{void SetFont(wxFont * \hy-8{3708}{font})}

Sets the font for the text window (Windows only).


\hy-10{3710}{wxTextWindow::ShowPosition}

\hy-8{3711}{void ShowPosition(long \hy-8{3712}{ pos})}

Makes the line containing the given position visible. XView only.


\hy-10{3714}{wxTextWindow::SetInsertionPoint}

\hy-8{3715}{void SetInsertionPoint(long \hy-8{3716}{ pos})}

Sets the current insertion point to \hy-7{3717}{pos} (XView only).


\hy-10{3719}{wxTextWindow::SetInsertionPointEnd}

\hy-8{3720}{void SetInsertionPointEnd(void)}

Sets the current insertion point to the end of the text (XView only).


\hy-10{3722}{wxTextWindow::SaveFile}

\hy-8{3723}{Bool SaveFile(char * \hy-8{3724}{ file})}

Saves the text in the named file. Success is indicated by a return
value of TRUE.


\hy-10{3726}{wxTextWindow::WriteText}

\hy-8{3727}{void WriteText(char * \hy-8{3728}{ text})}

Writes the text into the text window. Presently there is no means of writing
text to other than the end of the existing text.  Newlines in the text string
are the only control characters allowed, and they will cause appropriate
line breaks.  See \hy-13{3729}{<<} for more convenient ways of writing to the
window.


\hy-10{3731}{wxTextWindow::XYToPosition}

\hy-8{3732}{long XYToPosition(long \hy-8{3733}{ x}, long \hy-8{3734}{ y})}

Converts given character and line position to a position. XView and Windows only.


\hy-10{3736}{wxTextWindow::<<}

\hy-8{3737}{wxTextWindow& <<(char * \hy-8{3738}{s})}

\hy-8{3739}{wxTextWindow& <<(int \hy-8{3740}{ i})}

\hy-8{3741}{wxTextWindow& <<(long \hy-8{3742}{ i})}

\hy-8{3743}{wxTextWindow& <<(float \hy-8{3744}{ f})}

\hy-8{3745}{wxTextWindow& <<(double \hy-8{3746}{ d})}

\hy-8{3747}{wxTextWindow& <<(char \hy-8{3748}{ c})}

Operator definitions for writing to a text window, for example:

\hy-14{3749}{  wxTextWindow *wnd = new wxTextWindow(my_frame);

  (*wnd) << "Welcome to text window number " << 1 << ".\n";
}


\hy-10{3758}{wxTimer::wxTimer}

\hy-8{3759}{void wxTimer(void)}

Constructor.


\hy-10{3761}{wxTimer::~wxTimer}

\hy-8{3762}{void ~wxTimer(void)}

Destructor. Stops the timer if activated.


\hy-10{3764}{wxTimer::Notify}

\hy-8{3765}{void Notify(void)}

This member should be overridden by the user. It is called on timeout.


\hy-10{3767}{wxTimer::Start}

\hy-8{3768}{Bool Start(int \hy-8{3769}{ milliseconds = -1})}

(Re)starts the timer. If \hy-7{3770}{milliseconds} is absent or -1, the
previous value is used. Returns FALSE if the timer could not be started,
TRUE otherwise (in Windows 3 timers are a limited resource).


\hy-10{3772}{wxTimer::Stop}

\hy-8{3773}{void Stop(void)}

Stops the timer.


\hy-10{3830}{wxTypeTree::wxTypeTree}

\hy-8{3831}{void wxTypeTree(void)}

Constructor. Used by wxWindows only, since there only one instance of this
class.


\hy-10{3833}{wxTypeTree::AddType}

\hy-8{3834}{void AddType(WXTYPE \hy-8{3835}{ newType}, WXTYPE \hy-8{3836}{ parentType}, char * \hy-8{3837}{name})}

Adds a type to the hierarchy. \hy-7{3838}{newType} is the type being registered,
\hy-7{3839}{parentType} is the parent type, and \hy-7{3840}{name} is an identifier
(which can used in error messages). The top (root) type is wxTYPE_ANY.

Example:

\hy-14{3841}{wxAllTypes.AddType(wxTYPE_WINDOW, wxTYPE_ANY,     "window");
wxAllTypes.AddType(wxTYPE_PANEL,  wxTYPE_WINDOW,  "panel");
wxAllTypes.AddType(wxTYPE_CANVAS, wxTYPE_WINDOW,  "canvas");
}


\hy-10{3843}{wxTypeTree::GetName}

\hy-8{3844}{char * GetName(WXTYPE  \hy-8{3845}{typ})}

Gets a temporary pointer to the name of the given type, or NULL if the type
is not found.


\hy-10{3849}{wxWindow::wxWindow}

\hy-8{3850}{void wxWindow(void)}

Constructor.


\hy-10{3852}{wxWindow::~wxWindow}

\hy-8{3853}{void ~wxWindow(void)}

Destructor. Deletes all subwindows, then deletes itself.


\hy-10{3855}{wxWindow::AddChild}

\hy-8{3856}{void AddChild(wxWindow * \hy-8{3857}{child})}

Adds a child window.  This is called automatically by window creation
functions so should not be required by the application programmer.


\hy-10{3859}{wxWindow::CaptureMouse}

\hy-8{3860}{void CaptureMouse(void)}

Directs all mouse input to this window. Call \hy-8{3861}{ReleaseMouse} to
release the capture.


\hy-10{3863}{wxWindow::Center}

\hy-8{3864}{void Center(int \hy-8{3865}{ direction})}

See \hy-13{3866}{Centre}.


\hy-10{3868}{wxWindow::Centre}

\hy-8{3869}{void Centre(int \hy-8{3870}{ direction})}

Centres the window. The parameter may be \hy-14{3871}{wxHORIZONTAL}, \hy-14{3872}{wxVERTICAL}
or \hy-14{3873}{wxBOTH}.

The actual behaviour depends on the derived window. For a frame or dialog box,
centring is relative to the whole display. For a panel item, centring is
relative to the panel.


\hy-10{3875}{wxWindow::ClientToScreen}

\hy-8{3876}{void ClientToScreen(int * \hy-8{3877}{x}, int * \hy-8{3878}{y})}

Converts the values pointed to by \hy-7{3879}{x} and \hy-7{3880}{y} to screen
coordinates from coordinates relative to this window.


\hy-10{3882}{wxWindow::DestroyChildren}

\hy-8{3883}{void DestroyChildren(void)}

Destroys all children of a window.  Called automatically by the destructor.


\hy-10{3885}{wxWindow::DragAcceptFiles}

\hy-8{3886}{void DragAcceptFiles(void)}

Under Windows, makes the window eligible for a \hy-8{3887}{OnDropFiles} event.


\hy-10{3889}{wxWindow::Enable}

\hy-8{3890}{void Enable(Bool \hy-8{3891}{ enable})}

Enable or disable the window, so input has no effect.


\hy-10{3893}{wxWindow::GetCharHeight}

\hy-8{3894}{float GetCharHeight(void)}

Get the character height for this window.


\hy-10{3896}{wxWindow::GetCharWidth}

\hy-8{3897}{float GetCharWidth(void)}

Get the average character width for this window.


\hy-10{3899}{wxWindow::GetChildren}

\hy-8{3900}{wxList * GetChildren(void)}

Returns a temporary pointer to a list of the window's children.


\hy-10{3902}{wxWindow::GetClientData}

\hy-8{3903}{char * GetClientData(void)}

Gets user-supplied client data.  Normally, any extra data the programmer wishes
to associate with the window should be made available by deriving a new class
with new data members.


\hy-10{3905}{wxWindow::GetClientSize}

\hy-8{3906}{void GetClientSize(int * \hy-8{3907}{width}, int * \hy-8{3908}{height})}

This gets the size of the window `client area' in pixels.  The client area is the
area which may be drawn on by the programmer, excluding title bar, border etc.


\hy-10{3910}{wxWindow::GetGrandParent}

\hy-8{3911}{wxWindow * GetGrandParent(void)}

Returns the grandparent of a window, if any.


\hy-10{3913}{wxWindow::GetHandle}

\hy-8{3914}{char * GetHandle(void)}

Gets the platform-specific handle of the physical window.


\hy-10{3916}{wxWindow::GetPosition}

\hy-8{3917}{void GetPosition(int * \hy-8{3918}{x}, int * \hy-8{3919}{y})}

This gets the position of the window in pixels, relative to the parent window or
if no parent, relative to the whole display.


\hy-10{3921}{wxWindow::GetLabel}

\hy-8{3922}{char * GetLabel(void)}

Generic way of getting a label from any window, perhaps for
identification purposes. Some windows do not have labels (such as
subwindows), but frames, dialogs and panel items all have labels,
where the interpretation of what constitutes a label differs from
class to class. This can be useful for meta-programs (such as testing
tools or special-needs access programs) which need to identify windows
by name rather than visually.


\hy-10{3924}{wxWindow::GetParent}

\hy-8{3925}{wxWindow * GetParent(void)}

Returns the parent of a window, if any.


\hy-10{3927}{wxWindow::GetSize}

\hy-8{3928}{void GetSize(int * \hy-8{3929}{width}, int * \hy-8{3930}{height})}

This gets the size of the entire window in pixels.


\hy-10{3932}{wxWindow::GetTextExtent}

\hy-8{3933}{void GetTextExtent(char * \hy-8{3934}{string}, int * \hy-8{3935}{x}, int * \hy-8{3936}{y})}

Gets the width and height of the string as it would be drawn on the window with the
currently selected font.


\hy-10{3938}{wxWindow::OnActivate}

\hy-8{3939}{void OnActivate(Bool \hy-8{3940}{ active})}

Called when a window is activated or deactivated (Windows 3
only). If the window is being activated, \hy-7{3941}{active} is TRUE, else it
is FALSE.


\hy-10{3943}{wxWindow::OnChar}

\hy-8{3944}{void OnChar(wxKeyEvent& \hy-8{3945}{ ch})}

Sent to the window when the user has pressed a key. See \hy-13{3946}{wxKeyEvent} for
details.

For a list of the wxWindows virtual key codes, see the include file \hy-14{3947}{base/common.h}.
Note that the ASCII values do not have explicit key codes: they are passed as ASCII
values.

See also \hy-13{3948}{wxWindow::OnEvent} for mouse event notification. \hy-8{3949}{OnChar} is
currently applicable to canvas subwindows only.


\hy-10{3951}{wxWindow::OnDropFiles}

\hy-8{3952}{void OnDropFiles(int \hy-8{3953}{ n}, char * \hy-8{3954}{files[]}, int \hy-8{3955}{ x}, int \hy-8{3956}{ y})}

Under Windows, called when files have been dragged from the file manager to the window.
\hy-7{3957}{files} is an array of \hy-7{3958}{n} strings, and \hy-7{3959}{x} and \hy-7{3960}{y} give the mouse position
where the drop occurred. The window must have previously been enabled for dropping by calling
\hy-13{3961}{wxWindow::DragAcceptFiles}.


\hy-10{3963}{wxWindow::OnEvent}

\hy-8{3964}{void OnEvent(wxMouseEvent& \hy-8{3965}{ event})}

Sent to the window when the user has initiated an event with the
mouse. Derive your own class to handle this message. So far,
only relevant to the wxCanvas class. See \hy-13{3966}{wxWindow::OnChar} for character
events, and also \hy-13{3967}{wxMouseEvent} for how to access event information.


\hy-10{3969}{wxWindow::OnKillFocus}

\hy-8{3970}{void OnKillFocus(void)}

Called when a window's focus is being killed.


\hy-10{3972}{wxWindow::OnPaint}

\hy-8{3973}{void OnPaint(void)}

Sent to the window when the window must be refreshed.
Derive your own class to handle this message. So far, only
relevant to the wxCanvas class.


\hy-10{3975}{wxWindow::PopupMenu}

\hy-8{3976}{Bool PopupMenu(wxMenu * \hy-8{3977}{menu}, float  \hy-8{3978}{x}, float  \hy-8{3979}{y})}

Pops up the given menu at the specified coordinates, relative to this
window, and returns control when the user has dismissed the menu. If a
menu item is selected, the callback defined for the menu is called with
wxMenu and wxCommandEvent reference arguments. The callback should access
the commandInt member of the event to check the selected menu identifier.

Valid only for subwindows (panels, canvases and text windows).

See also \hy-13{3980}{wxMenu}.


\hy-10{3982}{wxWindow::OnSetFocus}

\hy-8{3983}{void OnSetFocus(void)}

Called when a window's focus is being set.


\hy-10{3985}{wxWindow::OnSize}

\hy-8{3986}{void OnSize(int \hy-8{3987}{ x}, int \hy-8{3988}{ y})}

Sent to the window when the window has been resized. You may wish to use
this for frames to resize their child windows as appropriate. Derive
your own class to handle this message. Note that the size passed is of
the whole window: call \hy-8{3989}{GetClientSize} for the area which may be
used by the application. A window is sent both an OnPaint and an OnSize message
when a resize occurs.


\hy-10{3991}{wxWindow::ReleaseMouse}

\hy-8{3992}{void ReleaseMouse(void)}

Releases mouse input captured with \hy-8{3993}{CaptureMouse}.


\hy-10{3995}{wxWindow::ScreenToClient}

\hy-8{3996}{void ScreenToClient(int * \hy-8{3997}{x}, int * \hy-8{3998}{y})}

Converts the values pointed to by \hy-7{3999}{x} and \hy-7{4000}{y} to window
coordinates from screen coordinates.


\hy-10{4002}{wxWindow::SetFocus}

\hy-8{4003}{void SetFocus(void)}

This sets the window to receive keyboard input. The only panel item that will
respond to this under XView is the \hy-8{4004}{wxText} item and derived items.


\hy-10{4006}{wxWindow::SetSize}

\hy-8{4007}{void SetSize(int \hy-8{4008}{ x}, int \hy-8{4009}{ y}, int \hy-8{4010}{ width}, int \hy-8{4011}{ height})}

This sets the size of the entire window in pixels.


\hy-10{4013}{wxWindow::SetClientData}

\hy-8{4014}{void SetClientData(char * \hy-8{4015}{data})}

Sets user-supplied client data.  Normally, any extra data the programmer wishes
to associate with the window should be made available by deriving a new class
with new data members.


\hy-10{4017}{wxWindow::SetClientSize}

\hy-8{4018}{void SetClientSize(int \hy-8{4019}{ x}, int \hy-8{4020}{ y}, int \hy-8{4021}{ width}, int \hy-8{4022}{ height})}

This sets the size of the window client area in pixels. Using this function to size a window
tends to be more device-independent than \hy-8{4023}{SetSize}, since the application need not
worry about what dimensions the border or title bar have when trying to fit the window
around panel items, for example.


\hy-10{4025}{wxWindow::SetColourMap}

\hy-8{4026}{void SetColourMap(wxColourMap * \hy-8{4027}{colourMap})}

Assigns the given colourmap to the window.


\hy-10{4029}{wxWindow::SetCursor}

\hy-8{4030}{wxCursor * SetCursor(wxCursor * \hy-8{4031}{cursor})}

Sets the window's cursor, returning the previous cursor (if any). This
function applies to all subwindows.

See also \hy-13{4032}{::wxSetCursor}, \hy-13{4033}{wxCursor}.


\hy-10{4035}{wxWindow::SetTitle}

\hy-8{4036}{void SetTitle(char * \hy-8{4037}{title})}

Sets the window's title, allocating its own string storage. Currently
applicable only to frames.


\hy-10{4039}{wxWindow::Show}

\hy-8{4040}{void Show(Bool \hy-8{4041}{ show})}

If \hy-7{4042}{show} is TRUE, displays the window and brings it to the front.  Otherwise,
hides the window.





\hy-10{4047}{::DirExists}

\hy-8{4048}{Bool DirExists(char * \hy-8{4049}{dirname})}

Returns TRUE if the directory exists.


\hy-10{4051}{::Dos2UnixFilename}

\hy-8{4052}{void Dos2UnixFilename(char * \hy-8{4053}{s})}

Converts a DOS to a UNIX filename by replacing backslashes with forward
slashes.


\hy-10{4055}{::FileExists}

\hy-8{4056}{Bool FileExists(char * \hy-8{4057}{filename})}

Returns TRUE if the file exists.


\hy-10{4059}{::FileNameFromPath}

\hy-8{4060}{char * FileNameFromPath(char * \hy-8{4061}{path})}

Returns a temporary pointer to the filename for a full path.
Copy this pointer for long-term use.


\hy-10{4063}{::IsAbsolutePath}

\hy-8{4064}{Bool IsAbsolutePath(char * \hy-8{4065}{filename})}

Returns TRUE if the argument is an absolute filename, i.e. with a slash
or drive name at the beginning.


\hy-10{4067}{::PathOnly}

\hy-8{4068}{char * PathOnly(char * \hy-8{4069}{path})}

Returns a temporary pointer to the directory part of the filename. Copy this
pointer for long-term use.


\hy-10{4071}{::Unix2DosFilename}

\hy-8{4072}{void Unix2DosFilename(char * \hy-8{4073}{s})}

Converts a UNIX to a DOS filename by replacing forward
slashes with backslashes.


\hy-10{4075}{::wxConcatFiles}

\hy-8{4076}{Bool wxConcatFiles(char * \hy-8{4077}{file1}, char * \hy-8{4078}{file2},
char * \hy-8{4079}{file3})}

Concatenates \hy-7{4080}{file1} and \hy-7{4081}{file2} to \hy-7{4082}{file3}, returning
TRUE if successful.


\hy-10{4084}{::wxCopyFile}

\hy-8{4085}{Bool wxCopyFile(char * \hy-8{4086}{file1}, char * \hy-8{4087}{file2})}

Copies \hy-7{4088}{file1} to \hy-7{4089}{file2}, returning TRUE if successful.


\hy-10{4091}{::wxGetTempFileName}

\hy-8{4092}{void wxGetTempFileName(char * \hy-8{4093}{prefix}, char * \hy-8{4094}{buf})}

Makes a temporary filename based on \hy-7{4095}{prefix}, opens and closes the file,
and places the name in \hy-7{4096}{buf}.

Under Windows, the filename will include the drive and name of the
directory allocated for temporary files (usually the contents of the
TEMP variable). Under UNIX, the \hy-14{4097}{/tmp} directory is used.

It is the application's responsibility to create and delete the file.


\hy-10{4099}{::wxIsWild}

\hy-8{4100}{Bool wxIsWild(char * \hy-8{4101}{pattern})}

Returns TRUE if the pattern contains wildcards. See \hy-13{4102}{wxMatchWild}.


\hy-10{4104}{::wxMatchWild}

\hy-8{4105}{Bool wxMatchWild(char * \hy-8{4106}{pattern}, char * \hy-8{4107}{text}, Bool \hy-8{4108}{ dot_special})}

Returns TRUE if the \hy-7{4109}{pattern} matches the \hy-7{4110}{text}; if \hy-7{4111}{
dot_special} is TRUE, filenames beginning with a dot are not matched
with wildcard characters. See \hy-13{4112}{wxIsWild}.


\hy-10{4114}{::wxMkdir}

\hy-8{4115}{Bool wxMkdir(char * \hy-8{4116}{dir})}

Makes the directory \hy-7{4117}{dir}, returning TRUE if successful.


\hy-10{4119}{::wxRemoveFile}

\hy-8{4120}{Bool wxRemoveFile(char * \hy-8{4121}{file})}

Removes \hy-7{4122}{file}, returning TRUE if successful.


\hy-10{4124}{::wxRenameFile}

\hy-8{4125}{Bool wxRenameFile(char * \hy-8{4126}{file1}, char * \hy-8{4127}{file2})}

Renames \hy-7{4128}{file1} to \hy-7{4129}{file2}, returning TRUE if successful.


\hy-10{4131}{::wxRmdir}

\hy-8{4132}{Bool wxRmdir(char * \hy-8{4133}{dir})}

Removes the directory \hy-7{4134}{dir}, returning TRUE if successful.


\hy-10{4138}{::copystring}

\hy-8{4139}{char * copystring(char * \hy-8{4140}{s})}

Makes a copy of the string \hy-7{4141}{s} using the C++ new operator, so it can be
deleted with the \hy-7{4142}{delete} operator.


\hy-10{4144}{::StringMatch}

\hy-8{4145}{Bool StringMatch(char * \hy-8{4146}{s1}, char * \hy-8{4147}{s2},

  Bool \hy-8{4148}{ subString = TRUE}, Bool \hy-8{4149}{ exact = FALSE})}

Returns TRUE if the substring \hy-7{4150}{s1} is found within \hy-7{4151}{s2},
ignoring case if \hy-7{4152}{exact} is FALSE. If \hy-7{4153}{subString} is FALSE,
no substring matching is done.


\hy-10{4157}{::wxFileSelector}

\hy-8{4158}{char * wxFileSelector(char * \hy-8{4159}{message}, char * \hy-8{4160}{default_path = NULL},

  char * \hy-8{4161}{default_filename = NULL}, char * \hy-8{4162}{default_extension = NULL},

  char * \hy-8{4163}{wildcard = ``*.*''}, int  \hy-8{4164}{flags = 0}, wxFrame * \hy-8{4165}{parent = NULL},

  int \hy-8{4166}{ x = -1}, int \hy-8{4167}{ y = -1})}

Pops up a file selector box. In Windows, this is the common file selector
dialog. In X, this is a file selector box with somewhat less functionality.
The path and filename are distinct elements of a full file pathname.
If path is NULL, the current directory will be used. If filename is NULL,
no default filename will be supplied. The wildcard determines what files
are displayed in the file selector, and file extension supplies a type
extension for the required filename. Flags may be a combination of wxOPEN,
wxSAVE, wxOVERWRITE_PROMPT, wxHIDE_READONLY, or 0. They are only significant
at present in Windows.

Both the X and Windows versions implement a wildcard filter. Typing a
filename containing wildcards (*, ?) in the filename text item, and
clicking on Ok, will result in only those files matching the pattern being
displayed. In the X version, supplying no default name will result in the
wildcard filter being inserted in the filename text item; the filter is
ignored if a default name is supplied.

The application must check for a NULL return value (the user pressed
Cancel). For example:

\hy-14{4168}{char *s = wxFileSelector("Choose a file to open");
if (s)
{
  ...
}
}


\hy-10{4170}{::wxGetTextFromUser}

\hy-8{4171}{char * wxGetTextFromUser(char * \hy-8{4172}{message}, char * \hy-8{4173}{caption = ``Input text"},

  char * \hy-8{4174}{default_value = ``"}, wxFrame * \hy-8{4175}{parent = NULL},

  int \hy-8{4176}{ x = -1}, int \hy-8{4177}{ y = -1}, Bool \hy-8{4178}{ centre = TRUE})}

Pop up a dialog box with title set to \hy-7{4179}{caption}, message \hy-7{4180}{message}, and a
\hy-7{4181}{default_value}.  The user may type in text and press OK to return this text,
or press Cancel to return NULL.

If \hy-7{4182}{centre} is TRUE, the message text (which may include new line characters)
is centred; if FALSE, the message is left-justified.


\hy-10{4184}{::wxGetSingleChoice}

\hy-8{4185}{char * wxGetSingleChoice(char * \hy-8{4186}{message}, char * \hy-8{4187}{caption}, int \hy-8{4188}{ n}, char * \hy-8{4189}{choices[]},

  wxFrame * \hy-8{4190}{parent = NULL}, int \hy-8{4191}{ x = -1}, int \hy-8{4192}{ y = -1},

  Bool \hy-8{4193}{ centre = TRUE})}

Pops up a dialog box containing a message, OK/Cancel buttons and a single-selection
listbox. The user may choose an item and press OK to return a string or
Cancel to return NULL.

\hy-7{4194}{choices} is an array of \hy-7{4195}{n} strings for the listbox.

If \hy-7{4196}{centre} is TRUE, the message text (which may include new line characters)
is centred; if FALSE, the message is left-justified.


\hy-10{4198}{::wxGetSingleChoiceIndex}

\hy-8{4199}{int wxGetSingleChoiceIndex(char * \hy-8{4200}{message}, char * \hy-8{4201}{caption}, int \hy-8{4202}{ n}, char * \hy-8{4203}{choices[]},

  wxFrame * \hy-8{4204}{parent = NULL}, int \hy-8{4205}{ x = -1}, int \hy-8{4206}{ y = -1},

  Bool \hy-8{4207}{ centre = TRUE})}

As \hy-8{4208}{wxGetSingleChoice} but returns the index representing the selected string.
If the user pressed cancel, -1 is returned.


\hy-10{4210}{::wxGetSingleChoiceData}

\hy-8{4211}{char * wxGetSingleChoiceData(char * \hy-8{4212}{message}, char * \hy-8{4213}{caption}, int \hy-8{4214}{ n}, char * \hy-8{4215}{choices[]},

  char * \hy-8{4216}{client_data[]}, wxFrame * \hy-8{4217}{parent = NULL}, int \hy-8{4218}{ x = -1},

  int \hy-8{4219}{ y = -1}, Bool \hy-8{4220}{ centre = TRUE})}

As \hy-8{4221}{wxGetSingleChoice} but takes an array of client data pointers
corresponding to the strings, and returns one of these pointers.


\hy-10{4223}{::wxMessageBox}

\hy-8{4224}{int wxMessageBox(char * \hy-8{4225}{message}, char * \hy-8{4226}{caption = ``Message"}, int \hy-8{4227}{ style = wxOK | wxCENTRE},

  wxFrame * \hy-8{4228}{parent = NULL}, int \hy-8{4229}{ x = -1}, int \hy-8{4230}{ y = -1})}

General purpose message dialog.  \hy-7{4231}{style} may be a bit list of the
following identifiers:


\hy-8{4232}{wxYES_NO}  Puts Yes and No buttons on the message box. May be combined with
wxCANCEL. 
\hy-8{4233}{wxCANCEL}  Puts a Cancel button on the message box. May be combined with
wxYES_NO or wxOK.
\hy-8{4234}{wxOK}  Puts an Ok button on the message box. May be combined with wxCANCEL.
\hy-8{4235}{wxCENTRE}  Centres the text.
\hy-8{4236}{wxICON_EXCLAMATION}  Under Windows, displays an exclamation mark symbol.
\hy-8{4237}{wxICON_HAND}   Under Windows, displays a hand symbol.
\hy-8{4238}{wxICON_QUESTION}   Under Windows, displays a question mark symbol.
\hy-8{4239}{wxICON_INFORMATION}   Under Windows, displays an information symbol.


The return value is one of: wxYES, wxNO, wxCANCEL, wxOK.

For example:

\hy-14{4240}{  ...
  int answer = wxMessageBox("Quit program?", "Confirm",
                            wxYES_NO | wxCANCEL, main_frame);
  if (answer == wxYES)
    delete main_frame;
  ...
}

\hy-7{4241}{message} may contain newline characters, in which case the
message will be split into separate lines, to cater for large messages.

Under Windows, the native MessageBox function is used unless wxCENTRE
is specified in the style, in which case a generic function is used.
This is because the native MessageBox function cannot centre text.
The symbols are not shown when the generic function is used.


\hy-10{4245}{::wxColourDisplay}

\hy-8{4246}{Bool wxColourDisplay(void)}

Returns TRUE if the display is colour, FALSE otherwise.


\hy-10{4248}{::wxDisplayDepth}

\hy-8{4249}{int wxDisplayDepth(void)}

Returns the depth of the display (a value of 1 denotes a monochrome display).


\hy-10{4251}{::wxMakeMetaFilePlaceable}

\hy-8{4252}{Bool wxMakeMetaFilePlaceable(char * \hy-8{4253}{filename}, float \hy-8{4254}{minX}, float \hy-8{4255}{minY},
 float \hy-8{4256}{maxX}, float \hy-8{4257}{maxY})}

Given a filename for an existing, valid metafile (as constructed using \hy-13{4258}{wxMetaFileDC})
makes it into a placeable metafile by prepending a header containing the given
bounding box. The bounding box may be obtained from a device context after drawing
into it, using the functions wxDC::MinX, wxDC::MinY, wxDC::MaxX and wxDC::MaxY.

In addition to adding the placeable metafile header, this function adds
the equivalent of the following code to the start of the metafile data:

\hy-14{4259}{ SetMapMode(dc, MM_ANISOTROPIC);
 SetWindowOrg(dc, minX, minY);
 SetWindowExt(dc, maxX - minX, maxY - minY);
}

This simulates the MM_TEXT mapping mode, which wxWindows assumes.

Placeable metafiles may be imported by many Windows applications, and can be
used in RTF (Rich Text Format) files.

This function is only available under Windows.


\hy-10{4261}{::wxSetCursor}

\hy-8{4262}{void wxSetCursor(wxCursor * \hy-8{4263}{cursor})}

Globally sets the cursor; only has an effect in Windows 3.
See also \hy-13{4264}{wxCursor}, \hy-13{4265}{wxWindow::SetCursor}.


\hy-10{4273}{::wxAddPrimaryEventHandler}

\hy-8{4274}{Bool wxAddPrimaryEventHandler(wxEventHandler \hy-8{4275}{ handlerFunc})}

Add a primary event handler---the normal event handler for this
event. For built-in events, these would include moving and resizing
windows. User-defined primary events might include the code to
select an image in a diagram (which could of course be achieved by a series
of external events for mouse-clicking, but would be more difficult to specify
and less robust).

Returns TRUE if it succeeds.

An event handler takes a pointer to a wxEvent and a boolean flag which is
TRUE if the event was externally generated, and returns a boolean which is
TRUE if that event was handled.


\hy-10{4277}{::wxAddSecondaryEventHandler}

\hy-8{4278}{Bool wxAddSecondaryEventHandler(wxEventHandler \hy-8{4279}{ handlerFunc}, Bool \hy-8{4280}{ pre},

  Bool \hy-8{4281}{ override}, Bool  \hy-8{4282}{append})}

Add a secondary event handler, pre = TRUE iff it should be called before the
event is executed. override = TRUE iff the handler is allowed to override
all subsequent events by returning TRUE. Returns TRUE if succeeds.

A secondary event handler is an application-defined handler that may
intercept normal events, possibly overriding them. A primary event handler
provides the normal behaviour for the event.

An event handler takes a pointer to a wxEvent and a boolean flag which is
TRUE if the event was externally generated, and returns a boolean which is
TRUE if that event was handled.


\hy-10{4284}{::wxNotifyEvent}

\hy-8{4285}{Bool wxNotifyEvent(wxEvent& \hy-8{4286}{ event}, Bool \hy-8{4287}{ pre})}

Notify the system of the event you are about to execute/have just
executed.  If TRUE is returned and pre = TRUE, the calling code should
not execute the event (since it has been intercepted by a handler and
vetoed).

These events are always internal, because they're generated from within
the main application code.


\hy-10{4289}{::wxRegisterEventClass}

\hy-8{4290}{void wxRegisterEventClass(WXTYPE \hy-8{4291}{ eventClassId},WXTYPE \hy-8{4292}{ superClassId},

  wxEventConstructor \hy-8{4293}{ constructor}, char * \hy-8{4294}{description})}

Register a new event class (derived from wxEvent), giving the new
event class type, its superclass, a function for creating a new event
object of this class, and an optional description.


\hy-10{4296}{::wxRegisterEventName}

\hy-8{4297}{void wxRegisterEventName(WXTYPE \hy-8{4298}{ eventTypeId},WXTYPE \hy-8{4299}{ eventClassId},

  char * \hy-8{4300}{eventName})}

Register the name of the event. This will allow a simple command
language where giving the event type name and some arguments will
cause a new event of class \hy-7{4301}{eventClassId} to be created, with given
event type, and some arguments, allows an event to be dynamically
constructed and sent.


\hy-10{4303}{::wxRegisterExternalEventHandlers}

\hy-8{4304}{void wxRegisterExternalEventHandlers(void)}

Define this and link before wxWindows library to allow registering
events from `outside' the main application.


\hy-10{4306}{::wxRemoveSecondaryEventHandler}

\hy-8{4307}{Bool wxRemoveSecondaryEventHandler(wxEventHandler \hy-8{4308}{ handlerFunc}, Bool \hy-8{4309}{ pre})}

Remove a secondary event handler. Returns TRUE if it succeeds.


\hy-10{4311}{::wxSendEvent}

\hy-8{4312}{Bool wxSendEvent(wxEvent& \hy-8{4313}{ event}, Bool \hy-8{4314}{ external})}

Send an event to the system; usually it will be external, but set
external to FALSE if calling from within the main application in
response to other events.

Returns TRUE if the event was processed.


\hy-10{4318}{::NewId}

\hy-8{4319}{long NewId(void)}

Generates an integer identifier unique to this run of the program.


\hy-10{4321}{::RegisterId}

\hy-8{4322}{void RegisterId(long \hy-8{4323}{ id})}

Ensures that ids subsequently generated by \hy-8{4324}{NewId} do not clash with
the given \hy-8{4325}{id}.


\hy-10{4327}{::wxBell}

\hy-8{4328}{void wxBell(void)}

Ring the system bell.


\hy-10{4330}{::wxDebugMsg}

\hy-8{4331}{void wxDebugMsg(char * \hy-8{4332}{fmt}, ... \hy-8{4333}{})}

Display a debugging message; under Windows, this will appear on the
debugger command window, and under UNIX, it will be written to standard
error.

The syntax is identical to \hy-8{4334}{printf}: pass a format string and a
variable list of arguments.

Note that under Windows, you can see the debugging messages without a
debugger if you have the DBWin debug log application that comes with
Microsoft C++. The hello.exe demo outputs debug messages.


\hy-10{4336}{::wxDisplaySize}

\hy-8{4337}{void wxDisplaySize(int * \hy-8{4338}{width}, int * \hy-8{4339}{height})}

Gets the physical size of the display in pixels.


\hy-10{4341}{::wxError}

\hy-8{4342}{void wxError(char * \hy-8{4343}{msg}, char * \hy-8{4344}{title = "wxWindows Internal Error"})}

Displays \hy-7{4345}{msg} and continues. This writes to standard error under
UNIX, and pops up a message box under Windows. Used for internal
wxWindows errors. See also \hy-13{4346}{wxFatalError}.


\hy-10{4348}{::wxExecute}

\hy-8{4349}{void wxExecute(char * \hy-8{4350}{command})}

Executes a command in UNIX or Windows. Note that under Windows, the
function immediately returns, whereas under UNIX, it does
returns only after the command has finished executing, unless the
command is executed in the background (append an ampersand).


\hy-10{4352}{::wxExit}

\hy-8{4353}{void wxExit(void)}

Exits application after calling \hy-13{4354}{wxApp::OnExit}.
Should only be used in an emergency: normally the top-level frame
should be deleted (after deleting all other frames) to terminate the
application. See \hy-13{4355}{wxFrame::OnClose} and \hy-13{4356}{wxApp}.


\hy-10{4358}{::wxFatalError}

\hy-8{4359}{void wxFatalError(char * \hy-8{4360}{msg}, char * \hy-8{4361}{title = "wxWindows Fatal Error"})}

Displays \hy-7{4362}{msg} and exits. This writes to standard error under UNIX,
and pops up a message box under Windows. Used for fatal internal
wxWindows errors. See also \hy-13{4363}{wxError}.


\hy-10{4365}{::wxFindMenuItemId}

\hy-8{4366}{int wxFindMenuItemId(wxFrame * \hy-8{4367}{frame}, char * \hy-8{4368}{menuString}, char * \hy-8{4369}{itemString})}

Find a menu item identifier associated with the given frame's menu bar.


\hy-10{4371}{::wxFindWindowByLabel}

\hy-8{4372}{wxWindow * wxFindWindowByLabel(wxWindow * \hy-8{4373}{parent}, char * \hy-8{4374}{label})}

Find a window by its label. Depending on the type of window, the label may be a window title
or panel item label. If \hy-7{4375}{parent} is NULL, the search will start from all top-level
frames and dialog boces; if non-NULL, the search will be limited to the given window hierarchy.
The search is recursive in both cases.


\hy-10{4377}{::wxGetHostName}

\hy-8{4378}{Bool wxGetHostName(char * \hy-8{4379}{buf}, int \hy-8{4380}{ bufSize})}

Copies the host name of the machine the program is running on into the
buffer \hy-7{4381}{buf}, of maximum size \hy-7{4382}{bufSize}, returning TRUE if
successful. Under UNIX, this will return a machine name. Under Windows,
this returns ``windows''.


\hy-10{4384}{::wxGetElapsedTime}

\hy-8{4385}{long wxGetElapsedTime(void)}

Gets the time in milliseconds since the last \hy-8{4386}{::wxGetElapsedTime} or
\hy-13{4387}{::wxStartTimer}.

See also \hy-13{4388}{wxTimer}.


\hy-10{4390}{::wxGetFreeMemory}

\hy-8{4391}{long wxGetFreeMemory(void)}

Returns the amount of free memory in Kbytes under environments which
support it, and -1 if not supported. Currently, returns a positive value
under Windows, and -1 under UNIX.


\hy-10{4393}{::wxGetResource}

\hy-8{4394}{Bool wxGetResource(char * \hy-8{4395}{section}, char * \hy-8{4396}{entry},
 char ** \hy-8{4397}{value}, char * \hy-8{4398}{file = NULL})}

\hy-8{4399}{Bool wxGetResource(char * \hy-8{4400}{section}, char * \hy-8{4401}{entry},
 float * \hy-8{4402}{value}, char * \hy-8{4403}{file = NULL})}

\hy-8{4404}{Bool wxGetResource(char * \hy-8{4405}{section}, char * \hy-8{4406}{entry},
 long * \hy-8{4407}{value}, char * \hy-8{4408}{file = NULL})}

\hy-8{4409}{Bool wxGetResource(char * \hy-8{4410}{section}, char * \hy-8{4411}{entry},
 int * \hy-8{4412}{value}, char * \hy-8{4413}{file = NULL})}

Gets a resource value from the resource database (for example, WIN.INI, or
.Xdefaults). If \hy-7{4414}{file} is NULL, WIN.INI or .Xdefaults is used,
otherwise the specified file is used.

Under X, if an application class (wxApp::wx_class) has been defined,
it is appended to the string /usr/lib/X11/app-defaults/ to try to find
an applications default file when merging all resource databases.

The reason for passing the result in an argument is that it
can be convenient to define a default value, which gets overridden
if the value exists in the resource file. It saves a separate
test for that resource's existence, and it also allows
the overloading of the function for different types.

See also \hy-13{4415}{wxWriteResource}.


\hy-10{4417}{::wxGetUserId}

\hy-8{4418}{Bool wxGetUserId(char * \hy-8{4419}{buf}, int \hy-8{4420}{ bufSize})}

Copies the user's login identity (such as ``jacs'') into the buffer \hy-7{4421}{
buf}, of maximum size \hy-7{4422}{bufSize}, returning TRUE if successful.
Under Windows, this returns ``user''.


\hy-10{4424}{::wxGetUserName}

\hy-8{4425}{Bool wxGetUserName(char * \hy-8{4426}{buf}, int \hy-8{4427}{ bufSize})}

Copies the user's name (such as ``Julian Smart'') into the buffer \hy-7{4428}{
buf}, of maximum size \hy-7{4429}{bufSize}, returning TRUE if successful.
Under Windows, this returns ``unknown''.


\hy-10{4431}{::wxIPCInitialize}

\hy-8{4432}{void wxIPCInitialize(void)}

Initializes for interprocess communication operation. May
be called multiple times without harm.

See also \hy-13{4433}{wxServer}, \hy-13{4434}{wxClient}, \hy-13{4435}{wxConnection}
and the relevant section of the user manual.


\hy-10{4437}{::wxSleep}

\hy-8{4438}{void wxSleep(int \hy-8{4439}{ secs})}

Under X, sleeps for the specified number of seconds using the
technique specified in the XView manual, not UNIX \hy-8{4440}{sleep}.


\hy-10{4442}{::wxStripMenuCodes}

\hy-8{4443}{void wxStripMenuCodes(char * \hy-8{4444}{in}, char * \hy-8{4445}{out})}

Strips any menu codes from \hy-7{4446}{in} and places the result
in \hy-7{4447}{out}. Menu codes include & (mark the next character with an underline
as a keyboard shortkey in Windows and Motif) and \t (tab in Windows).


\hy-10{4449}{::wxStartTimer}

\hy-8{4450}{void wxStartTimer(void)}

Starts a stopwatch; use \hy-13{4451}{::wxGetElapsedTime} to get the elapsed time.

See also \hy-13{4452}{wxTimer}.


\hy-10{4454}{::wxSubType}

\hy-8{4455}{Bool wxSubType(WXTYPE \hy-8{4456}{ type1}, WXTYPE \hy-8{4457}{ type2})}

TRUE if \hy-7{4458}{type1} is a subtype of, or the same type as, \hy-7{4459}{type2}. This can
be useful when determining whether an object is an instance of a class derived from
some other class, and its usage can make for generic code.

See also \hy-13{4460}{wxTypeTree} and \hy-13{4461}{wxObject::__type}.

Example:

\hy-14{4462}{  wxNode *node = GetChildren()->First();
  while (node)
  {
    // Find a child that's a subwindow, but not a dialog box.
    wxWindow *child = (wxWindow *)node->Data();
    if ((wxSubType(child->__type, wxTYPE_PANEL) &&
         !wxSubType(child->__type, wxTYPE_DIALOG_BOX)) ||
        wxSubType(child->__type, wxTYPE_TEXT_WINDOW) ||
        wxSubType(child->__type, wxTYPE_CANVAS))
    {
      child->SetFocus();
      return;
    }
    node = node->Next();
  }
}


\hy-10{4464}{::wxWriteResource}

\hy-8{4465}{Bool wxWriteResource(char * \hy-8{4466}{section}, char * \hy-8{4467}{entry},
 char * \hy-8{4468}{value}, char * \hy-8{4469}{file = NULL})}

\hy-8{4470}{Bool wxWriteResource(char * \hy-8{4471}{section}, char * \hy-8{4472}{entry},
 float  \hy-8{4473}{value}, char * \hy-8{4474}{file = NULL})}

\hy-8{4475}{Bool wxWriteResource(char * \hy-8{4476}{section}, char * \hy-8{4477}{entry},
 long  \hy-8{4478}{value}, char * \hy-8{4479}{file = NULL})}

\hy-8{4480}{Bool wxWriteResource(char * \hy-8{4481}{section}, char * \hy-8{4482}{entry},
 int  \hy-8{4483}{value}, char * \hy-8{4484}{file = NULL})}

Writes a resource value into the resource database (for example, WIN.INI, or
.Xdefaults). If \hy-7{4485}{file} is NULL, WIN.INI or .Xdefaults is used,
otherwise the specified file is used.

Under X, the resource databases are cached until the internal function
\hy-8{4486}{wxFlushResources} is called automatically on exit, when
all updated resource databases are written to their files.

Note that it is considered bad manners to write to the .Xdefaults
file under UNIX, although the WIN.INI file is fair game under Windows.

See also \hy-13{4487}{wxGetResource}.


\hy-10{4489}{::wxYield}

\hy-8{4490}{Bool wxYield(void)}

Yields control to pending messages in the windowing system (has no
effect under XView or Motif). This can be useful, for example, when a
time-consuming process writes to a text window. Without an occasional
yield, the text window will not be updated properly, and (since Windows
multitasking is cooperative) other processes will not respond.

Caution should be exercised, however, since yielding may allow the
user to perform actions which are not compatible with the current task.
Disabling menu items or whole menus during processing can avoid unwanted
reentrance of code.


\hyindex{
"wxWindows Manual"
4 5
6 7
8 9
10 11
40 41
48 49
53 54
56 57
58 59
60 61
62 63
64 65
66 67
68 69
71 72
74 75
78 79
80 81
93 94
102 103
107 108
111 112
118 119
125 126
131 132
134 135
140 141
142 143
145 146
148 149
151 152
155 156
159 160
161 162
163 164
186 187
196 197
200 201
204 205
206 207
223 224
267 268
269 270
276 277
282 283
288 289
302 303
304 305
308 309
311 312
322 323
325 326
336 337
342 343
344 345
346 347
349 350
355 356
360 361
365 366
372 373
375 376
377 378
380 381
384 385
386 387
388 389
396 397
402 403
404 405
406 407
408 409
410 411
422 423
428 429
430 431
435 436
439 440
450 451
457 458
459 460
461 462
485 486
502 503
508 509
519 520
521 522
573 574
587 588
591 592
594 595
597 598
600 601
606 607
610 611
613 614
616 617
619 620
627 628
641 642
644 645
647 648
650 651
653 654
656 657
665 666
675 676
678 679
681 682
684 685
694 695
698 699
702 703
706 707
710 711
718 719
722 723
727 728
759 760
762 763
786 787
792 793
796 797
805 806
823 824
826 827
837 838
840 841
843 844
855 856
862 863
869 870
882 883
895 896
900 901
907 908
915 916
926 927
932 933
937 938
942 943
948 949
955 956
958 959
963 964
969 970
972 973
978 979
983 984
991 992
996 997
1002 1003
1008 1009
1013 1014
1030 1031
1036 1037
1042 1043
1051 1052
1056 1057
1060 1061
1064 1065
1066 1067
1097 1098
1100 1101
1123 1124
1126 1127
1130 1131
1134 1135
1137 1138
1163 1164
1166 1167
1171 1172
1174 1175
1189 1190
1193 1194
1196 1197
1199 1200
1203 1204
1207 1208
1212 1213
1227 1228
1230 1231
1237 1238
1244 1245
1247 1248
1256 1257
1262 1263
1265 1266
1271 1272
1276 1277
1279 1280
1283 1284
1287 1288
1290 1291
1292 1293
1295 1296
1298 1299
1302 1303
1305 1306
1308 1309
1311 1312
1314 1315
1337 1338
1340 1341
1343 1344
1346 1347
1349 1350
1352 1353
1359 1360
1367 1368
1375 1376
1383 1384
1389 1390
1397 1398
1400 1401
1407 1408
1415 1416
1424 1425
1429 1430
1434 1435
1442 1443
1449 1450
1454 1455
1459 1460
1465 1466
1501 1502
1504 1505
1518 1519
1521 1522
1524 1525
1537 1538
1540 1541
1544 1545
1548 1549
1552 1553
1564 1565
1571 1572
1577 1578
1584 1585
1597 1598
1610 1611
1615 1616
1622 1623
1630 1631
1641 1642
1648 1649
1651 1652
1654 1655
1659 1660
1664 1665
1679 1680
1683 1684
1687 1688
1690 1691
1693 1694
1696 1697
1699 1700
1702 1703
1706 1707
1711 1712
1719 1720
1724 1725
1729 1730
1735 1736
1747 1748
1751 1752
1756 1757
1761 1762
1766 1767
1770 1771
1773 1774
1782 1783
1811 1812
1814 1815
1821 1822
1834 1835
1837 1838
1843 1844
1846 1847
1850 1851
1856 1857
1863 1864
1878 1879
1881 1882
1884 1885
1888 1889
1899 1900
1904 1905
1908 1909
1916 1917
1919 1920
1924 1925
1927 1928
1930 1931
1933 1934
1936 1937
1939 1940
1942 1943
1946 1947
1950 1951
1963 1964
1977 1978
1980 1981
1984 1985
1987 1988
1991 1992
1994 1995
1998 1999
2001 2002
2005 2006
2009 2010
2017 2018
2021 2022
2023 2024
2025 2026
2027 2028
2038 2039
2044 2045
2059 2060
2062 2063
2067 2068
2071 2072
2076 2077
2080 2081
2084 2085
2088 2089
2092 2093
2095 2096
2098 2099
2101 2102
2104 2105
2187 2188
2193 2194
2235 2236
2238 2239
2245 2246
2250 2251
2262 2263
2267 2268
2271 2272
2275 2276
2279 2280
2282 2283
2287 2288
2295 2296
2300 2301
2305 2306
2311 2312
2318 2319
2324 2325
2331 2332
2336 2337
2341 2342
2343 2344
2350 2351
2356 2357
2366 2367
2369 2370
2373 2374
2380 2381
2383 2384
2389 2390
2392 2393
2398 2399
2404 2405
2408 2409
2416 2417
2424 2425
2433 2434
2438 2439
2440 2441
2445 2446
2449 2450
2452 2453
2456 2457
2460 2461
2465 2466
2468 2469
2471 2472
2473 2474
2482 2483
2487 2488
2491 2492
2494 2495
2497 2498
2500 2501
2503 2504
2506 2507
2510 2511
2513 2514
2518 2519
2521 2522
2529 2530
2542 2543
2545 2546
2557 2558
2560 2561
2566 2567
2570 2571
2575 2576
2582 2583
2585 2586
2593 2594
2596 2597
2601 2602
2606 2607
2609 2610
2612 2613
2645 2646
2648 2649
2657 2658
2660 2661
2676 2677
2680 2681
2684 2685
2688 2689
2692 2693
2695 2696
2699 2700
2702 2703
2706 2707
2711 2712
2717 2718
2722 2723
2726 2727
2731 2732
2738 2739
2744 2745
2750 2751
2754 2755
2760 2761
2763 2764
2778 2779
2781 2782
2787 2788
2793 2794
2797 2798
2801 2802
2805 2806
2811 2812
2814 2815
2819 2820
2824 2825
2828 2829
2831 2832
2838 2839
2841 2842
2847 2848
2853 2854
2859 2860
2865 2866
2870 2871
2874 2875
2878 2879
2883 2884
2889 2890
2894 2895
2900 2901
2907 2908
2909 2910
2923 2924
2926 2927
2936 2937
2939 2940
2942 2943
2945 2946
2952 2953
2958 2959
2962 2963
2965 2966
2968 2969
2971 2972
2974 2975
2977 2978
2980 2981
2983 2984
2986 2987
2989 2990
2992 2993
2995 2996
3013 3014
3018 3019
3022 3023
3025 3026
3028 3029
3032 3033
3035 3036
3038 3039
3041 3042
3044 3045
3047 3048
3050 3051
3053 3054
3061 3062
3064 3065
3067 3068
3070 3071
3073 3074
3076 3077
3082 3083
3085 3086
3088 3089
3091 3092
3094 3095
3097 3098
3099 3100
3104 3105
3108 3109
3139 3140
3142 3143
3153 3154
3156 3157
3159 3160
3164 3165
3168 3169
3171 3172
3174 3175
3177 3178
3180 3181
3186 3187
3190 3191
3201 3202
3205 3206
3209 3210
3213 3214
3217 3218
3220 3221
3223 3224
3227 3228
3231 3232
3236 3237
3240 3241
3247 3248
3259 3260
3262 3263
3265 3266
3268 3269
3271 3272
3281 3282
3285 3286
3289 3290
3292 3293
3296 3297
3300 3301
3310 3311
3314 3315
3319 3320
3328 3329
3331 3332
3349 3350
3352 3353
3363 3364
3365 3366
3406 3407
3409 3410
3438 3439
3445 3446
3449 3450
3452 3453
3455 3456
3458 3459
3462 3463
3466 3467
3471 3472
3474 3475
3477 3478
3481 3482
3486 3487
3488 3489
3508 3509
3511 3512
3526 3527
3529 3530
3533 3534
3536 3537
3541 3542
3544 3545
3548 3549
3552 3553
3557 3558
3563 3564
3566 3567
3568 3569
3589 3590
3592 3593
3606 3607
3609 3610
3614 3615
3616 3617
3633 3634
3636 3637
3639 3640
3650 3651
3654 3655
3657 3658
3660 3661
3663 3664
3667 3668
3672 3673
3675 3676
3682 3683
3686 3687
3689 3690
3696 3697
3705 3706
3709 3710
3713 3714
3718 3719
3721 3722
3725 3726
3730 3731
3735 3736
3750 3751
3757 3758
3760 3761
3763 3764
3766 3767
3771 3772
3774 3775
3829 3830
3832 3833
3842 3843
3846 3847
3848 3849
3851 3852
3854 3855
3858 3859
3862 3863
3867 3868
3874 3875
3881 3882
3884 3885
3888 3889
3892 3893
3895 3896
3898 3899
3901 3902
3904 3905
3909 3910
3912 3913
3915 3916
3920 3921
3923 3924
3926 3927
3931 3932
3937 3938
3942 3943
3950 3951
3962 3963
3968 3969
3971 3972
3974 3975
3981 3982
3984 3985
3990 3991
3994 3995
4001 4002
4005 4006
4012 4013
4016 4017
4024 4025
4028 4029
4034 4035
4038 4039
4043 4044
4046 4047
4050 4051
4054 4055
4058 4059
4062 4063
4066 4067
4070 4071
4074 4075
4083 4084
4090 4091
4098 4099
4103 4104
4113 4114
4118 4119
4123 4124
4130 4131
4135 4136
4137 4138
4143 4144
4154 4155
4156 4157
4169 4170
4183 4184
4197 4198
4209 4210
4222 4223
4242 4243
4244 4245
4247 4248
4250 4251
4260 4261
4266 4267
4272 4273
4276 4277
4283 4284
4288 4289
4295 4296
4302 4303
4305 4306
4310 4311
4315 4316
4317 4318
4320 4321
4326 4327
4329 4330
4335 4336
4340 4341
4347 4348
4351 4352
4357 4358
4364 4365
4370 4371
4376 4377
4383 4384
4389 4390
4392 4393
4416 4417
4423 4424
4430 4431
4436 4437
4441 4442
4448 4449
4453 4454
4463 4464
4488 4489
4491 4492
4493 4494
4495 4496
4498 4499
4500 4501
4502 4503
4504 4505
4506 4507
4508 4509
4510 4511
4512 4513
4514 4515
4516 4517
4518 4519
4520 4521
4523 4524
4525 4526
17 41
17 41
95 312
95 312
124 387
124 387
133 135
133 135
138 381
138 381
153 381
153 381
154 397
154 397
203 389
203 389
313 366
313 366
341 381
341 381
369 312
369 312
374 57
374 57
382 385
382 385
395 376
395 376
442 305
442 305
447 312
447 312
448 366
448 366
504 94
504 94
523 574
523 574
524 2188
524 2188
525 617
525 617
526 3105
526 3105
527 3615
527 3615
528 797
528 797
529 2829
529 2829
530 2351
530 2351
531 3105
531 3105
532 2472
532 2472
533 723
533 723
534 1065
534 1065
535 1135
535 1135
536 2610
536 2610
537 3487
537 3487
538 3364
538 3364
539 3487
539 3487
540 1774
540 1774
541 4155
541 4155
542 4223
542 4223
543 4157
543 4157
544 797
544 797
546 1505
546 1505
547 1057
547 1057
548 2732
548 2732
549 3329
549 3329
550 2732
550 2732
551 2953
551 2953
552 3350
552 3350
555 1578
555 1578
556 1642
556 1642
557 1245
557 1245
558 657
558 657
559 3248
559 3248
560 959
560 959
561 964
561 964
562 2425
562 2425
563 620
563 620
564 2522
564 2522
565 3534
565 3534
566 2370
566 2370
567 4044
567 4044
568 3218
568 3218
569 4316
569 4316
570 1213
570 1213
571 3472
571 3472
572 1353
572 1353
577 617
577 617
584 2288
584 2288
585 4352
585 4352
609 617
609 617
622 2732
622 2732
623 1525
623 1525
625 2732
625 2732
658 1720
658 1720
660 617
660 617
663 699
663 699
664 1505
664 1505
674 1245
674 1245
701 657
701 657
725 1774
725 1774
726 3105
726 3105
750 2342
750 2342
785 728
785 728
789 4002
789 4002
790 3181
790 3181
791 3165
791 3165
800 1505
800 1505
801 1057
801 1057
802 938
802 938
803 3329
803 3329
804 2732
804 2732
836 806
836 806
940 1505
940 1505
941 1057
941 1057
947 1014
947 1014
953 1545
953 1545
954 1549
954 1549
962 3943
962 3943
967 959
967 959
968 2969
968 2969
977 1014
977 1014
982 657
982 657
990 841
990 841
995 657
995 657
1000 1951
1000 1951
1001 927
1001 927
1006 1525
1006 1525
1012 3248
1012 3248
1027 933
1027 933
1028 943
1028 943
1029 949
1029 949
1035 1037
1035 1037
1041 1031
1041 1031
1049 3905
1049 3905
1050 1014
1050 1014
1058 938
1058 938
1059 1505
1059 1505
1122 1067
1122 1067
1136 2610
1136 2610
1188 1138
1188 1138
1215 1238
1215 1238
1218 1390
1218 1390
1219 4431
1219 4431
1220 1231
1220 1231
1224 3472
1224 3472
1225 1353
1225 1353
1236 1238
1236 1238
1240 1353
1240 1353
1241 1231
1241 1231
1243 1390
1243 1390
1246 1272
1246 1272
1275 1245
1275 1245
1300 2342
1300 2342
1301 4311
1301 4311
1354 1213
1354 1213
1355 3472
1355 3472
1357 1213
1357 1213
1358 3472
1358 3472
1365 3482
1365 3482
1366 1238
1366 1238
1374 1390
1374 1390
1381 1435
1381 1435
1382 1401
1382 1401
1386 1398
1386 1398
1422 1443
1422 1443
1441 1408
1441 1408
1448 1416
1448 1416
1453 1425
1453 1425
1458 1430
1458 1430
1462 2351
1462 2351
1463 4261
1463 4261
1508 3329
1508 3329
1509 2953
1509 2953
1510 2732
1510 2732
1511 3350
1511 3350
1512 1057
1512 1057
1513 797
1513 797
1514 938
1514 938
1535 1730
1535 1730
1536 2732
1536 2732
1543 1712
1543 1712
1647 1665
1647 1665
1658 1736
1658 1736
1677 1951
1677 1951
1678 1725
1678 1725
1718 1541
1718 1541
1723 657
1723 657
1728 1951
1728 1951
1733 1525
1733 1525
1741 1762
1741 1762
1779 4155
1779 4155
1780 3105
1780 3105
1781 3847
1781 3847
1833 1783
1833 1783
1862 1917
1862 1917
1922 1299
1922 1299
1923 2969
1923 2969
1972 1725
1972 1725
1973 1642
1973 1642
1974 1665
1974 1665
1976 2010
1976 2010
1983 1951
1983 1951
1990 1951
1990 1951
1997 1951
1997 1951
2189 2288
2189 2288
2190 797
2190 797
2191 3105
2191 3105
2192 3615
2192 3615
2261 2194
2261 2194
2266 2325
2266 2325
2270 2306
2270 2306
2274 2332
2274 2332
2317 2351
2317 2351
2322 2829
2322 2829
2323 2751
2323 2751
2330 2263
2330 2263
2335 2272
2335 2272
2339 2263
2339 2263
2340 2325
2340 2325
2348 2472
2348 2472
2349 1299
2349 1299
2354 1572
2354 1572
2355 620
2355 620
2372 2522
2372 2522
2414 3083
2414 3083
2486 1299
2486 1299
2496 959
2496 959
2523 2370
2523 2370
2527 3083
2527 3083
2611 1135
2611 1135
2675 2613
2675 2613
2735 620
2735 620
2736 1505
2736 1505
2737 1057
2737 1057
2749 1572
2749 1572
2752 2296
2752 2296
2753 3975
2753 3975
2759 3975
2759 3975
2810 2764
2810 2764
2935 2910
2935 2910
2955 2966
2955 2966
2956 2937
2956 2937
2957 4251
2957 4251
2970 964
2970 964
3084 2522
3084 2522
3102 4454
3102 4454
3103 3775
3103 3775
3152 3109
3152 3109
3167 787
3167 787
3246 3290
3246 3290
3330 1505
3330 1505
3351 1505
3351 1505
3437 3366
3437 3366
3525 3489
3525 3489
3605 3569
3605 3569
3649 3617
3649 3617
3729 3736
3729 3736
3755 4449
3755 4449
3756 4384
3756 4384
3776 4454
3776 4454
3777 3100
3777 3100
3866 3868
3866 3868
3946 2495
3946 2495
3948 3963
3948 3963
3961 3885
3961 3885
3966 3943
3966 3943
3967 2969
3967 2969
3980 2751
3980 2751
4032 4261
4032 4261
4033 1460
4033 1460
4045 3218
4045 3218
4102 4104
4102 4104
4112 4099
4112 4099
4258 2953
4258 2953
4264 1460
4264 1460
4265 4029
4265 4029
4270 3181
4270 3181
4346 4358
4346 4358
4354 614
4354 614
4355 2288
4355 2288
4356 574
4356 574
4363 4341
4363 4341
4387 4449
4387 4449
4388 3751
4388 3751
4415 4464
4415 4464
4433 3472
4433 3472
4434 1213
4434 1213
4435 1353
4435 1353
4451 4384
4451 4384
4452 3751
4452 3751
4460 3775
4460 3775
4461 3100
4461 3100
4487 4393
4487 4393
17 41
17 41
95 312
95 312
124 387
124 387
133 135
133 135
138 381
138 381
153 381
153 381
154 397
154 397
203 389
203 389
313 366
313 366
341 381
341 381
369 312
369 312
374 57
374 57
382 385
382 385
395 376
395 376
442 305
442 305
447 312
447 312
448 366
448 366
504 94
504 94
523 574
523 574
524 2188
524 2188
525 617
525 617
526 3105
526 3105
527 3615
527 3615
528 797
528 797
529 2829
529 2829
530 2351
530 2351
531 3105
531 3105
532 2472
532 2472
533 723
533 723
534 1065
534 1065
535 1135
535 1135
536 2610
536 2610
537 3487
537 3487
538 3364
538 3364
539 3487
539 3487
540 1774
540 1774
541 4155
541 4155
542 4223
542 4223
543 4157
543 4157
544 797
544 797
546 1505
546 1505
547 1057
547 1057
548 2732
548 2732
549 3329
549 3329
550 2732
550 2732
551 2953
551 2953
552 3350
552 3350
555 1578
555 1578
556 1642
556 1642
557 1245
557 1245
558 657
558 657
559 3248
559 3248
560 959
560 959
561 964
561 964
562 2425
562 2425
563 620
563 620
564 2522
564 2522
565 3534
565 3534
566 2370
566 2370
567 4044
567 4044
568 3218
568 3218
569 4316
569 4316
570 1213
570 1213
571 3472
571 3472
572 1353
572 1353
577 617
577 617
584 2288
584 2288
585 4352
585 4352
609 617
609 617
622 2732
622 2732
623 1525
623 1525
625 2732
625 2732
658 1720
658 1720
660 617
660 617
663 699
663 699
664 1505
664 1505
674 1245
674 1245
701 657
701 657
725 1774
725 1774
726 3105
726 3105
750 2342
750 2342
785 728
785 728
789 4002
789 4002
790 3181
790 3181
791 3165
791 3165
800 1505
800 1505
801 1057
801 1057
802 938
802 938
803 3329
803 3329
804 2732
804 2732
836 806
836 806
940 1505
940 1505
941 1057
941 1057
947 1014
947 1014
953 1545
953 1545
954 1549
954 1549
962 3943
962 3943
967 959
967 959
968 2969
968 2969
977 1014
977 1014
982 657
982 657
990 841
990 841
995 657
995 657
1000 1951
1000 1951
1001 927
1001 927
1006 1525
1006 1525
1012 3248
1012 3248
1027 933
1027 933
1028 943
1028 943
1029 949
1029 949
1035 1037
1035 1037
1041 1031
1041 1031
1049 3905
1049 3905
1050 1014
1050 1014
1058 938
1058 938
1059 1505
1059 1505
1122 1067
1122 1067
1136 2610
1136 2610
1188 1138
1188 1138
1215 1238
1215 1238
1218 1390
1218 1390
1219 4431
1219 4431
1220 1231
1220 1231
1224 3472
1224 3472
1225 1353
1225 1353
1236 1238
1236 1238
1240 1353
1240 1353
1241 1231
1241 1231
1243 1390
1243 1390
1246 1272
1246 1272
1275 1245
1275 1245
1300 2342
1300 2342
1301 4311
1301 4311
1354 1213
1354 1213
1355 3472
1355 3472
1357 1213
1357 1213
1358 3472
1358 3472
1365 3482
1365 3482
1366 1238
1366 1238
1374 1390
1374 1390
1381 1435
1381 1435
1382 1401
1382 1401
1386 1398
1386 1398
1422 1443
1422 1443
1441 1408
1441 1408
1448 1416
1448 1416
1453 1425
1453 1425
1458 1430
1458 1430
1462 2351
1462 2351
1463 4261
1463 4261
1508 3329
1508 3329
1509 2953
1509 2953
1510 2732
1510 2732
1511 3350
1511 3350
1512 1057
1512 1057
1513 797
1513 797
1514 938
1514 938
1535 1730
1535 1730
1536 2732
1536 2732
1543 1712
1543 1712
1647 1665
1647 1665
1658 1736
1658 1736
1677 1951
1677 1951
1678 1725
1678 1725
1718 1541
1718 1541
1723 657
1723 657
1728 1951
1728 1951
1733 1525
1733 1525
1741 1762
1741 1762
1779 4155
1779 4155
1780 3105
1780 3105
1781 3847
1781 3847
1833 1783
1833 1783
1862 1917
1862 1917
1922 1299
1922 1299
1923 2969
1923 2969
1972 1725
1972 1725
1973 1642
1973 1642
1974 1665
1974 1665
1976 2010
1976 2010
1983 1951
1983 1951
1990 1951
1990 1951
1997 1951
1997 1951
2189 2288
2189 2288
2190 797
2190 797
2191 3105
2191 3105
2192 3615
2192 3615
2261 2194
2261 2194
2266 2325
2266 2325
2270 2306
2270 2306
2274 2332
2274 2332
2317 2351
2317 2351
2322 2829
2322 2829
2323 2751
2323 2751
2330 2263
2330 2263
2335 2272
2335 2272
2339 2263
2339 2263
2340 2325
2340 2325
2348 2472
2348 2472
2349 1299
2349 1299
2354 1572
2354 1572
2355 620
2355 620
2372 2522
2372 2522
2414 3083
2414 3083
2486 1299
2486 1299
2496 959
2496 959
2523 2370
2523 2370
2527 3083
2527 3083
2611 1135
2611 1135
2675 2613
2675 2613
2735 620
2735 620
2736 1505
2736 1505
2737 1057
2737 1057
2749 1572
2749 1572
2752 2296
2752 2296
2753 3975
2753 3975
2759 3975
2759 3975
2810 2764
2810 2764
2935 2910
2935 2910
2955 2966
2955 2966
2956 2937
2956 2937
2957 4251
2957 4251
2970 964
2970 964
3084 2522
3084 2522
3102 4454
3102 4454
3103 3775
3103 3775
3152 3109
3152 3109
3167 787
3167 787
3246 3290
3246 3290
3330 1505
3330 1505
3351 1505
3351 1505
3437 3366
3437 3366
3525 3489
3525 3489
3605 3569
3605 3569
3649 3617
3649 3617
3729 3736
3729 3736
3755 4449
3755 4449
3756 4384
3756 4384
3776 4454
3776 4454
3777 3100
3777 3100
3866 3868
3866 3868
3946 2495
3946 2495
3948 3963
3948 3963
3961 3885
3961 3885
3966 3943
3966 3943
3967 2969
3967 2969
3980 2751
3980 2751
4032 4261
4032 4261
4033 1460
4033 1460
4045 3218
4045 3218
4102 4104
4102 4104
4112 4099
4112 4099
4258 2953
4258 2953
4264 1460
4264 1460
4265 4029
4265 4029
4270 3181
4270 3181
4346 4358
4346 4358
4354 614
4354 614
4355 2288
4355 2288
4356 574
4356 574
4363 4341
4363 4341
4387 4449
4387 4449
4388 3751
4388 3751
4415 4464
4415 4464
4433 3472
4433 3472
4434 1213
4434 1213
4435 1353
4435 1353
4451 4384
4451 4384
4452 3751
4452 3751
4460 3775
4460 3775
4461 3100
4461 3100
4487 4393
4487 4393
}
