\hy-9{0}{
}










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

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

University of Edinburgh
EH1 1HN}

October 1994





\hy-5{1}{Contents}

\hy-6{4}{Copyright notice}

\hy-6{6}{Introduction}

\hy-6{54}{Resource guide}

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

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

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

\hy-6{426}{Bugs and future directions}

\hy-6{433}{Troubleshooting}

\hy-6{462}{Tutorial}

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

\hy-6{4964}{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{51}{Acknowledgments}


\hy-10{55}{Resource guide}


This is a list of other sources of information and software
related to wxWindows. For information of supplementary libraries in
the wxWindows distribution, see \hy-13{56}{Utilities}.

\hy-8{57}{wxCLIPS}

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

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

\hy-8{63}{wxXPM}

\hy-8{65}{CURSES port}

\hy-8{67}{Imakefiles}

\hy-8{69}{QDB database}

\hy-8{71}{MEWEL}

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

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


\hy-10{81}{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{82}{Windows}

\hy-8{104}{Dialog boxes}

\hy-8{109}{Menus}

\hy-8{113}{Events}

\hy-8{127}{Keyboard input}

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

\hy-8{136}{Scrolling}

\hy-8{142}{Printing}

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

\hy-8{148}{Dimensions}

\hy-8{151}{Colour}

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

\hy-8{159}{User preferences}

\hy-8{163}{Interprocess Communication}


\hy-10{209}{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{210}{Code structure}

\hy-8{227}{Include files}

\hy-8{272}{Libraries}

\hy-8{274}{Configuration}

\hy-8{284}{Makefiles}

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

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

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

\hy-8{333}{Conditional compilation}

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

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

\hy-8{368}{File handling}

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


\hy-10{381}{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{382}{Resource Guide}.

\hy-8{383}{wxBuilder}

\hy-8{385}{wxToolBar}

\hy-8{388}{wxHelp}

\hy-8{392}{hyText}

\hy-8{394}{wxCLIPS}

\hy-8{396}{PROLOGIO}

\hy-8{404}{Tex2RTF}

\hy-8{410}{wxTreeLayout}

\hy-8{412}{wxGraphLayout}

\hy-8{414}{wxImage}

\hy-8{417}{DIB}

\hy-8{420}{rcParser}

\hy-8{422}{MFUTILS}

\hy-8{424}{Colours}


\hy-10{427}{Bugs and future directions}


\hy-8{428}{Bugs}

\hy-8{431}{Future directions}


\hy-10{434}{Troubleshooting}



This chapter tries to address common problems with compiling
and using wxWindows. To some extent it is being superceded
by the Frequently Asked Questions document which is now
distributed with wxWindows.

\hy-8{435}{General}

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

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

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


\hy-10{463}{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{464}{The demo programs}


\hy-10{525}{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.

From version 1.50 beta (j), string return values are allocated and
deallocated by wxWindows. Therefore, return values should always be
copied for long-term use, especially since the same buffer is often
used by wxWindows.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

\hy-8{2326}{wxFormItem: wxObject}

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

\hy-8{2473}{wxFunction}

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

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

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

\hy-8{2603}{wxIntPoint: wxObject}

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

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

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

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

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

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

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

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

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

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

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

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

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

\hy-8{3308}{wxObject}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

\hy-8{4321}{File functions}

\hy-8{4451}{String functions}

\hy-8{4470}{Dialog functions}

\hy-8{4575}{GDI functions}

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

\hy-8{4650}{Printer settings}

\hy-8{4716}{Miscellaneous}


\hy-10{4965}{Glossary}




\hy-8{4966}{API}

\hy-8{4968}{Canvas}

\hy-8{4971}{DDE}

\hy-8{4973}{Device context}

\hy-8{4975}{Dialog box}

\hy-8{4977}{Frame}

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

\hy-8{4981}{GUI}

\hy-8{4983}{Menu bar}

\hy-8{4985}{Metafile}

\hy-8{4987}{Open Look}

\hy-8{4989}{Panel}

\hy-8{4991}{RPC}

\hy-8{4993}{Status line}

\hy-8{4996}{Text subwindow}

\hy-8{4998}{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 contains around 60 classes, with 650 public functions.

wxWindows 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.60 API
(Application Programming Interface) please refer to the separate
wxWindows reference manual.

Please note that in the following, ``Windows 3.1" often refers to all
platforms related to Microsoft Windows, including 16-bit and 32-bit
variants, unless otherwise stated. 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. An Apple Macintosh
version is being worked on by an external contributor, and an early demonstrator
is expected around September 1994.

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 some 
for Borland C++, 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 some of the important downsides, so you can assess wxWindows's
applicability to your needs:


\hy-8{36}{o}  No commercial support (but Internet 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}  Minimal 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.x
or Motif 1.2.x
\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/beta, change transmission method to binary, and get
wx160?.tar.Z or wx160?.tgz (UNIX) and/or wx160?_1.zip, wx160?_2.zip, wx160?_3.zip (PC)
where ? represents the release letter (currently a). 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).

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{52}{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 Internet 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, Edward Zimmermann, Ian Brown.

`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{53}{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{58}{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{60}{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{62}{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{64}{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{66}{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{68}{Imakefiles}



Imakefiles are highly flexible in dealing with different sites
and configurations. It has been suggested that wxWindows
makefiles should be Imakefiles. Perhaps one day!

Meanwhile, Patrick Albert's Imake kit is in /pub/wxwin/contrib
as imake.zip. Note that it is not up to date with respect
to wxWindows, but should give a head start in using Imakefiles.


\hy-10{70}{QDB database}



QDB is a user-contributed database that can read and write DBASE files.
As the author points out, the interface has not had much time spent on it.
However, it could be a good basis for a student project.

QDB is available in the /pub/wxwin/contrib directory of the AIAI ftp site
as qdb.zip. The author, Dave Curtis, can be contacted at
dcurtis@hgmp.mrc.ac.uk.


\hy-10{72}{MEWEL}



MEWEL is a commercial library from Magma that allows Windows source code
to be compiled for DOS graphics, DOS text and OS/2 text mode. Magma use
wxWindows as one of their demonstrations; a beta of version 1.50
apparently compiled with no modifications.

See below for contact information.

\hy-14{73}{                          The MEWEL Window System
Portable User Interface Library for Text and Graphics and Microsoft Windows

Magma Systems
15 Bodwell Terrace
Millburn, New Jersey 07041
(201) 912-0192 (voice)
(201) 912-0668 (24 hour BBS, USR HST Dual Standard, 9600-1200 baud, N-8-1)
(201) 912-0103 (fax for orders only)

CIS : 75300,2062. To get to our conference, GO MAGMA.
BIX : magma. Our conference is the 'magma' conference.
Internet : 75300.2062@compuserve.com (preferred) or magma@bix.com.

Thank you very much for expressing your interest in Magma Systems' MEWEL
user interface library. MEWEL 4.0 gives your application complete portability
between Microsoft Windows, DOS text, DOS graphics, OS/2 text, UNIX text,
VMS text, and soon, OSF Motif. Since MEWEL's API is compatible with the
standard Microsoft WIndows API, you can easily port programs between Win-
dows and any of the environments which MEWEL supports, even if you already
have existing Windows programs.

Programmers can develop new stand-alone applications using MEWEL, or can port
their existing Windows applications to any of the platforms which MEWEL
supports.
}

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



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

\hy-14{76}{wxwin-users-request@aiai.ed.ac.uk or J.Smart@ed.ac.uk
}
to be added to either the discussion or the announcements list.
Announcements are generally posted to wxwin-users too, so
there is no need to be subscribed to both.


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



You can view the documentation for wxWindows on the World Wide Web
using a viewer such as Mosaic.  The wxWindows home page is at:

\hy-14{79}{ http://www.aiai.ed.ac.uk/~jacs/html/wxwin.html
}
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{83}{Windows}



An application presents the user primarily with a series of windows. A
window can be made up of a \hy-7{84}{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{85}{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{86}{panel}, \hy-7{87}{canvas} and \hy-7{88}{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{89}{wxDC} will be able to pass any device context
object to this drawing function, including \hy-8{90}{wxPostScriptDC}, \hy-8{91}{wxCanvasDC},
\hy-8{92}{wxMetaFileDC}, and \hy-8{93}{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{94}{wxWindow} class, maintaining compatibility with
existing wxWindows programs but allowing new programs more flexibility.

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


\hy-10{105}{Dialog boxes}



A \hy-7{106}{dialog box} is like a panel, with an implicit frame surrounding
it. A dialog box may be \hy-7{107}{modal} (no other window in this application
is active and the calling program flow is suspended) or \hy-7{108}{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{110}{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{111}{
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{112}{OnMenuCommand} member. For popup menus, a callback function is
executed.


\hy-10{114}{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{115}{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{116}{OnEvent}, \hy-8{117}{
OnChar} and \hy-8{118}{OnSize}.  Frames can receive \hy-8{119}{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{120}{The wxWindows event system}


\hy-10{128}{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{129}{OnChar} member
of a window with a \hy-8{130}{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{131}{wxCanvas} class has a default \hy-8{132}{OnChar} handler which scrolls
the canvas using the cursor keys.


\hy-10{134}{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{135}{Scrolling} for more information on repainting and scrolling.


\hy-10{137}{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{138}{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{139}{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{140}{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{141}{
wxCanvas::EnableScrolling}.

Scrolling panels have yet to be implemented in wxWindows.


\hy-10{143}{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{145}{Programmatic versus interactive GUI building}



Interactive tools for rapidly building GUIs are all the rage, and
wxWindows has a simple screen painter and code generator called
wxBuilder.

A different solution is taken by \hy-13{146}{GWX} which
translates DevGuide files into wxWindows code, which has
the advantages and disadvantages on relying on a third party
GUI-building tool. It is also possible to translate some
Windows .RC files into wxBuilder menus and dialog boxes,
although the quality of the translation varies from good
(with most menu bar definitions) to poor (for most dialogs).

It is not always possible to build GUI components interactively: the
`what you see is \hy-7{147}{all} you get' syndrome. When complex repositioning
of items depending on window size is required, then GUI builders
cannot be relied upon.

Using a toolkit with geometry management may be no panacea, either; for
example, the Motif constraint algorithm is difficult to understand and
much experimentation is necessary to make things work. 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.


\hy-10{149}{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{150}{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.
Mapping modes other than pixels cannot be relied upon, however; future
versions of wxWindows may support mapping modes better, and allow a
change of graphics origin.


\hy-10{152}{Colour}



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{153}{Colour} member to
TRUE and choose custom colours for drawing graphics.

The \hy-13{154}{Colours} utility can be useful for displaying
colours and their names.

Colourmaps (or palettes) are supported only for colourmaps that have
been created by platform-specific utilities such as the DIB and wxImage
utilties. So you can associate a colourmap with a window or device
context, but functions to create and manipulate colourmaps are lacking.
Future versions of wxWindows should improve upon colourmap handling.


\hy-10{156}{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{157}{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{158}{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{160}{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{161}{wxGetResource} and
\hy-8{162}{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{164}{Interprocess Communication}



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

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

\hy-8{190}{Data transfer}

\hy-8{200}{Examples}

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


\hy-10{211}{Code structure}



Since version 1.50, the files have been split as much as possible into
command and platform-specific code. The \hy-14{212}{include} and \hy-14{213}{src} directories
each have a \hy-14{214}{base} directory for the common code, plus a directory for
each platform, currently \hy-14{215}{msw} and \hy-14{216}{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{217}{wxb}, and a derived
class for the platform with prefix \hy-8{218}{wx}. Base files have a \hy-8{219}{
wb_} prefix whilst platform-specific files (or files which \hy-7{220}{never}
have corresponding platform-specific code) have a \hy-8{221}{wx_} prefix.

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

\hy-14{224}{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{225}{wx_} header file includes the corresponding \hy-8{226}{wb_} header file.


\hy-10{228}{Include files}



Under both operating systems, include the file \hy-14{229}{"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{230}{"wx.h"} only. The main header files (omitting base class files) are
as follows.


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



\hy-10{273}{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{275}{Configuration}



The following lists the options configurable in the file
\hy-14{276}{include/base/wx_setup.h.} Some settings are a matter
of taste, some help with platform-specific problems, and
others can be set to minimize the size of the library.

\hy-8{277}{General features}

\hy-8{279}{X features}

\hy-8{281}{Windows and NT features}


\hy-10{285}{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 makefiles for UNIX (suffix .UNX), MS C++ (suffix .DOS and .NT), Borland
C++ (.BCC) and Symantec C++ (.SC) are included for the library, demos
and utilities. The NT, Borland and Symantec makefiles cannot be
guaranteed to be up-to-date since the author does not have
these compilers.

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

\hy-8{289}{DOS makefiles}

\hy-8{292}{UNIX makefiles}


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



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

\hy-8{309}{Resource file}

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


\hy-10{318}{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{319}{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{320}{o}  Do not use \hy-14{321}{/ND} to name extra data segments unless the segment is READONLY.
\hy-8{322}{o}  Use the .DEF file to mark extra data segments READONLY.
\hy-8{323}{o}  Do not use __far or FAR to mark data items.
\hy-8{324}{o}  Use \hy-14{325}{/PACKDATA} to combine data segments.
\hy-8{326}{o}  Use \hy-14{327}{/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.

For Borland users, use the data threshold switch, and the following is
also recommended:


\hy-8{328}{o}  Check ``Automatic Far Data Segments"
\hy-8{329}{o}  Check ``Put Constant Strings into Code Segment"


See also the Frequently Asked Questions document for further details
on using Borland with wxWindows.


\hy-10{331}{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{332}{/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{334}{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{335}{o}  \hy-14{336}{wx_x} - for code which should work under any X toolkit
\hy-8{337}{o}  \hy-14{338}{wx_xview} - for code which should work under XView only
\hy-8{339}{o}  \hy-14{340}{wx_motif} - for code which should work under Motif only
\hy-8{341}{o}  \hy-14{342}{wx_msw} - for code which should work under Microsoft Windows only


For example:

\hy-14{343}{  ...
#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{345}{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{346}{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{347}{install.txt}, the wxHelp documentation (in \hy-14{348}{
utils/wxhelp/docs}) and \hy-13{349}{wxHelp} for further details.


\hy-10{351}{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{352}{Templates}

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

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

\hy-8{363}{Precompiled headers}


\hy-10{369}{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{370}{
wxPathList} makes adding directories and searching for files easy, and
the global function \hy-8{371}{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{372}{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{374}{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{375}{/Gt} compiler option with
a number representing the data size threshold for putting data items
in a separate segment. For example, \hy-14{376}{/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{377}{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{378}{/SEG} linker switch,
for example \hy-14{379}{/SEG:256}.

For optimum Borland compilation, please the Frequently Asked
Questions guide (docs/faq.txt, docs/faq.ps and via the
wxWindows WWW home page).


\hy-10{384}{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 best under Windows, but it will run under
Motif as well. The XView version is pending but there are problems
with modal dialogs that need to be ironed out.

wxBuilder is so far the largest freely-available program written in
wxWindows, totalling about 16,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{386}{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{387}{test.cc}. wxToolBar works under Motif,
XView, Windows and NT.

Please refer to the separate manual for further details.


\hy-10{389}{wxHelp}



wxHelp is a stand-alone program, written using wxWindows and \hy-13{390}{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{391}{wxHelpInstance} entry in the
reference section for how an application controls wxHelp.


\hy-10{393}{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{395}{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 CLIPS2C 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{397}{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{398}{o}  The data are complex, possibly involving linked records and
nested lists.
\hy-8{399}{o}  The application is under development, so the size and contents
of each record are liable to change.
\hy-8{400}{o}  Backward compatibility of data files is required.
\hy-8{401}{o}  Ability to read and edit data file is required.
\hy-8{402}{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{403}{wxBuilder} is
a good example of a program that makes extensive use of PROLOGIO.


\hy-10{405}{Tex2RTF}



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


\hy-8{406}{wxHelp} 
wxWindows help system format (XLP).
\hy-8{407}{Linear RTF} 
Rich Text Format suitable for importing into a word processor.
\hy-8{408}{Windows Help RTF} 
Rich Text Format suitable for compiling into a WinHelp HLP file with the
help compiler.
\hy-8{409}{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{411}{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{413}{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{415}{wxImage}



This is a collection of GIF/BMP/XBM bitmap loading and displaying
routines for X, which may be used in conjunction with the
Windows-only \hy-13{416}{DIB} library for multi-platform bitmap display.


\hy-10{418}{DIB}



A Windows-only BMP loading and displaying library (see also
\hy-13{419}{wxImage} for an equivalent for the X platform).


\hy-10{421}{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{423}{MFUTILS}



A very modest step towards reading Windows metafiles on the
any platform. The ClockWorks program, available from AIAI, demonstrates
how extremely simple metafiles may be read and displayed (in this
case, to be used as clock hands).


\hy-10{425}{Colours}



A colour sampler for viewing colours and their names on each
platform.


\hy-10{429}{Bugs}



These are the known bugs (the contents of bugs.txt) plus a to-do list.

\hy-14{430}{wxWindows Bug and To Do List
----------------------------

######################### BUGS ##########################


19/4/93 Version 1.40 (First version for Motif)
----------------------------------------------

-- Haven't sorted out how to set default buttons without
   messing up tab traversal.

-- Probably need to set scrollbars to force an initial paint,
   or call wxCanvas::SetSize. If you set the scrollbars,
   it works fine.

-- No default colours. Works ok on monochrome though...

-- Too many repaint messages sent sometimes.

7/9/93 Version 1.50
-------------------

-- Programmatic setting of multiple selections listboxes doesn't work
   (Motif 1.1).

-- Canvas doesn't work under Motif 1.2.

-- Colourmap still only producing a small number of colours - FIXED (was
   using too small values for RGB values)

-- PostScript driver leaves something to be desired (espec. for
   Landscape mode).

-- Windows 3.1 canvas scrolling problem with large scale factor or some
   mapping modes: leaves streaks behind. Could be a rounding error with
   SetViewport...?

-- XView: closing of dialog boxes from the Window Manager not handled
   properly

16/11/93 Version 1.50 beta (h)
------------------------------

-- Motif 1.2.1 support added, but this bug (at least) remains: setting
   panel size doesn't seem to return correct size if there are panel
   items. So a Fit on a panel then a surrounding frame doesn't work
   properly. WORKAROUND: make frame and panel very big before placing
   items.

-- Status line in Motif doesn't show separate regions for > 1 region.

-- No PostScript DrawArc, or documentation for it.

16/11/93 Version 1.50 beta (i)
------------------------------

-- Motif: listbox gets smaller when you add 1 or more items to it.
   WORKAROUND: Set the listbox size after appending, e.g.
   SetSize(-1, -1, 100 100)

-- Motif: Technicolour appears after a while on a canvas (HP only?)

-- Motif: XORing doesn't seem to work in colour

-- Panel-in-panel doesn't work for wxABSOLUTE_POSITIONING panels
   (Motif) or XView (at all)

-- In Windows, CTL3D and Fafa library seem to conflict (some items don't
   appear on a panel if both are in operation). SOLUTION: I probably
   didn't include the fafa.rc file. This should make it work...


17/1/94 Version 1.50 beta (j)
-----------------------------

-- In beta (i), users found that buttons in Motif were random
   sizes. Something to do with using gadgets??

-- Cured bad MDI bug that crashed application (and Windows) on exit.

-- Cured XView wxPanel::Fit bug.

-- wxFrame::Fit() doesn't seems to work for an MDI frame that is
   iconized. It has to be displayed first, which leads to messy
   screen redraws. Ugh. Is this a Windows problem, or wxWindows?
   I suspect the former.

17/10/94 Version 1.60
---------------------

-- PopupMenu doesn't always work under Motif, for some reason.
   The workaround is to use FakePopupMenu.

-- Dialog box destruction isn't always vetoed when it should be
   under XView (Motif?)

-- Frames don't always position properly (some interaction with
   window managers?)

-- wxGetFirst/NextFile not implemented for Borland or NT

-- wxHelp and hyText refreshing is BAD, especially under Motif
   when sometimes the text doesn't appear at all.

-- Under Motif, listboxes sometimes change size mysteriously.



######################### TO DO ##########################

October 1994
------------

-- Implement wxColourMap properly

-- Control dialog box/frame decorations under Motif

-- Implement interception of user input in wxTextWindow

-- Make wxBuilder run ok under XView

-- make wxSlider optionally vertical

-- Better PostScript support, e.g. bitmap and DrawArc support

-- `Group' panel items

-- Improve mapping mode support

-- Some OLE-2 support !!!
}

\hy-10{432}{Future directions}



wxWindows lacks some GUI features, such as the group box for
logically grouping panel items; it is anticipated that this will
be addressed quite soon.

At a higher level, wxWindows does not support a
document-oriented view of the world, as do class libraries
such as Microsoft's MFC. Such an enhancement could
eventually be merged with a future OLE-2 wrapper which will
increasingly be on programmer's shopping lists.

Users are invited to contribute ideas and code for a partial
OLE-2 wrapper (preferably one that can embrace a range of
similar technologies, including OpenDoc and CORBA).

In addition to coping with the major changes to the Windows
API (such as OLE-2 and Windows 94), wxWindows will also need
to adapt to changes in, or perhaps even the replacement of,
the Motif standard in coming years.

An Apple Macintosh version of wxWindows is currently under
development, but there is no planned OS/2 version as yet.

As ever, the future of wxWindows is largely in the hands of
its users, since no one person could cope with supporting
all platforms simultaneously. So, please don't be backward
in coming forward with project ideas and code contributions!


\hy-10{436}{General}



\hy-7{437}{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{438}{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{439}{OnInit} is called, these objects may be created with impunity.


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



\hy-7{442}{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{443}{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{445}{Windows-specific problems}



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

You probably forgot to include the file wx.rc in your resource script
(see \hy-13{447}{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{448}{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{449}{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{450}{Iconize(FALSE)} to restore the
window. This at least avoids seeing half-painted windows whilst
things get initialized.

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

See sections \hy-13{452}{Memory models} and \hy-13{453}{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{454}{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{456}{XView-specific problems}



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

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

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

\hy-14{460}{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{461}{wxIcon} class entry).


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



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

\hy-8{490}{More advanced features: the \hy-7{492}{hello} demo}

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

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


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



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

An application must have a top-level \hy-13{529}{wxFrame} window (returned by \hy-13{530}{wxApp::OnInit}),
each frame containing one or more instances of \hy-13{531}{wxPanel}, \hy-13{532}{wxTextWindow}
or \hy-13{533}{wxCanvas}.

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

A \hy-13{536}{wxPanel} is used to place items (classes derived from \hy-13{537}{wxItem})
which are used for user interaction. Examples of items are \hy-13{538}{wxButton},
\hy-13{539}{wxCheckBox}, \hy-13{540}{wxChoice}, \hy-13{541}{wxListBox}, \hy-13{542}{wxSlider},
\hy-13{543}{wxRadioBox}, \hy-13{544}{wxSlider}.

Instances of \hy-13{545}{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{546}{dialog functions}, such as \hy-13{547}{wxMessageBox}
and \hy-13{548}{wxFileSelector}.

If you want to draw arbitrary graphics, you'll need a \hy-13{549}{wxCanvas}. In fact,
you never draw directly onto a canvas---you use a \hy-7{550}{device context} (DC). \hy-13{551}{wxDC} is
the base for \hy-13{552}{wxCanvasDC}, \hy-13{553}{wxMemoryDC}, \hy-13{554}{wxPostScriptDC},
\hy-13{555}{wxMemoryDC}, \hy-13{556}{wxMetaFileDC} and \hy-13{557}{wxPrinterDC}.
If your drawing functions have \hy-8{558}{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{559}{wxDC}, such as \hy-13{560}{wxDC::DrawLine}
and \hy-13{561}{wxDC::DrawText}. Control colour on a canvas (\hy-13{562}{wxColour}) with
brushes (\hy-13{563}{wxBrush}) and pens (\hy-13{564}{wxPen}).

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

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

GUI applications aren't all graphical wizardry. List and hash table needs are
catered for by \hy-13{569}{wxList}, \hy-13{570}{wxStringList} and \hy-13{571}{wxHashTable}.
You will undoubtedly need some platform-independent \hy-13{572}{file functions},
and you may find it handy to maintain and search a list of paths using \hy-13{573}{wxPathList}.
There's a \hy-13{574}{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{575}{wxClient}, \hy-13{576}{wxServer} and
\hy-13{577}{wxConnection}. These use DDE under Windows, and a simulation using
sockets under UNIX.


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



The \hy-8{580}{wxApp} class represents the application itself.  A wxWindows
application does not have a \hy-7{581}{main} procedure; the equivalent is the
\hy-13{582}{OnInit} member defined for a class derived from \hy-8{583}{wxApp}.
\hy-7{584}{OnInit} must create and return a main window frame as a bare minimum.
If NULL is returned from \hy-7{585}{OnInit}, the application will exit.
Note that the program's command line arguments, represented by \hy-7{586}{
argc} and \hy-7{587}{argv}, are available from within \hy-8{588}{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{589}{wxFrame::OnClose}
member.

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

An example of defining an application follows:

\hy-14{591}{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{592}{wxApp::wxApp}

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

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

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

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

\hy-8{611}{wxApp::Dispatch}

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

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

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

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

\hy-8{629}{wxApp::Pending}


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



This class encapsulates the concept of a platform-dependent bitmap,
either monochrome or colour. Platform-specific methods for creating a
\hy-8{635}{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{636}{wxMemoryDC}). This
enables the bitmap to be copied to a canvas or memory device context
using \hy-13{637}{wxDC::Blit}, or to be used as a drawing surface.  The \hy-8{638}{
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{639}{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{640}{#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{641}{Loading bitmaps: further information}

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

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

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

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

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

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


\hy-10{673}{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{674}{wxDC::SetBrush} in wx_dc.cc.
Alternatively, set the \hy-8{675}{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{676}{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{677}{wxTheBrushList}, and calling the member function
\hy-8{678}{FindOrCreateBrush}. See \hy-13{679}{wxBrushList} and \hy-13{680}{wxDC}.

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

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

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

\hy-8{698}{wxBrush::GetStipple}

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

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

\hy-8{722}{wxBrush::SetStipple}

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


\hy-10{739}{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{740}{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{741}{wxBrush}.

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

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

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

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


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



A button is a \hy-7{764}{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{765}{dialog box} or \hy-13{766}{panel}.

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

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

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

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

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


\hy-10{838}{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{839}{Colour} boolean member variable.

When you draw onto a canvas, you are really drawing onto a \hy-7{840}{device
context} (see \hy-13{841}{wxDC}, \hy-13{842}{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{843}{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{844}{wxPostScriptDC}
and \hy-13{845}{wxMemoryDC}).

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

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

\hy-8{865}{wxCanvas::AllowDoubleClick}

\hy-8{870}{wxCanvas::BeginDrawing}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

\hy-8{993}{wxCanvas::EndDrawing}

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

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

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

\hy-8{1016}{wxCanvas::IntDrawLine}

\hy-8{1023}{wxCanvas::IntDrawLines}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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



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

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


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



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

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

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

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

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

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

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


\hy-10{1212}{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{1213}{wxListBox}.

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

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

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

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

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

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

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

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

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

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

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


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



A wxClient object represents the client part of a client-server DDE
(Dynamic Data Exchange) conversation (available in \hy-7{1291}{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{1292}{wxClient::OnMakeConnection} member can return
a wxConnection of the required class, when a connection is made.

For example:

\hy-14{1293}{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{1294}{MyConnection} will respond to \hy-13{1295}{OnAdvise} messages sent
by the server.

When the client application starts, it must first call \hy-13{1296}{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{1297}{wxClient::MakeConnection}
implicitly creates an instance of \hy-8{1298}{MyConnection} if the request for a
connection is accepted, and the client then requests an \hy-7{1299}{Advise} loop
from the server, where the server calls the client when data has changed.

\hy-14{1300}{  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{1301}{wxServer}, \hy-13{1302}{wxConnection},
the chapter on interprocess communication in the user manual, and
the programs in \hy-14{1303}{samples/ipc}.

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

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

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


\hy-10{1322}{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{1323}{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{1324}{wxColour::wxColour}

\hy-8{1333}{wxColour::=}

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

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

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


\hy-10{1353}{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{1354}{Append}.  There
is only one instance of this class: \hy-8{1355}{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{1356}{wxColour}.

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

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

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

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


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



Colourmap functionality is incomplete, and will be extended in the future.
Currently, colourmaps may be returned from some wxWindows libraries
that load bitmaps (e.g. wxImage, DIB). To display a bitmap, its colourmap
should normally be set for that window.

There are some strict rules for colourmap useage. A colourmap should
never be deleted before being deselected from a window or device
context (although it may be used for several windows and device
contexts simultaneously). So, call \hy-13{1373}{wxDC::SetColourMap}
with a NULL argument to make sure that its original (probably system)
colourmap is restored.

If you are relying on wxWindows to clean up your bitmaps on program
exit, then you must be extra vigilant about cleaning up colourmaps
before bitmaps (and windows) are deleted. So it may not be an option
to use global objects, where you cannot be sure of the order
that C++ destroys objects; use dynamically created and destroyed
objects instead.

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

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

\hy-8{1381}{wxColourMap::Create}


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



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

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

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

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

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

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

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

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

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

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

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


\hy-10{1450}{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{1451}{wxClient} object, or by the acceptance of a connection by a
\hy-13{1452}{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{1453}{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{1454}{wxClient}, \hy-13{1455}{wxServer}, and
the chapter on interprocess communication in the user manual.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


\hy-10{1557}{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{1558}{
wxCursor} object are catered for, and this is an occasion where
conditional compilation will probably be required (see \hy-13{1559}{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{1560}{::wxSetCursor} is also available for Windows 3 use.

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

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

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


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



A wxDC is \hy-7{1603}{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{1604}{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{1605}{wxPostScriptDC},
\hy-13{1606}{wxMetaFileDC}, \hy-13{1607}{wxMemoryDC} or \hy-13{1608}{wxPrinterDC}
(Windows only) for constructing new device contexts.  \hy-13{1609}{wxCanvasDC}
is a context that cannot be created by the user but can be retrieved from
a \hy-13{1610}{wxCanvas} by using \hy-13{1611}{wxCanvas::GetDC}.

When writing code to draw into a device context, use \hy-8{1612}{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{1613}{samples/hello} for code which
uses this device-independent method of drawing.

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

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

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

\hy-8{1621}{wxDC::BeginDrawing}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

\hy-8{1760}{wxDC::EndDrawing}

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

\hy-8{1768}{wxDC::GetBackground}

\hy-8{1772}{wxDC::GetBrush}

\hy-8{1776}{wxDC::GetFont}

\hy-8{1780}{wxDC::GetLogicalFunction}

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

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

\hy-8{1797}{wxDC::GetPen}

\hy-8{1801}{wxDC::GetTextBackground}

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

\hy-8{1820}{wxDC::GetTextForeground}

\hy-8{1824}{wxDC::IntDrawLine}

\hy-8{1831}{wxDC::IntDrawLines}

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

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

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

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

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

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

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

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

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

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

\hy-8{1880}{wxDC::SetColourMap}

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

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

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

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

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

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

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

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

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

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


\hy-10{1935}{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{1936}{1.}  A surrounding frame is implicitly created.
\hy-8{1937}{2.}  Extra functionality is automatically given to the dialog box,
  such as tabbing between items (currently Windows only).
\hy-8{1938}{3.}  If the dialog box is \hy-7{1939}{modal}, the calling program is blocked
  until the dialog box is dismissed.


Under XView, some panel items may display incorrectly in a modal dialog,
and two modal dialogs may not be open simultaneously.

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{1940}{Dialog functions}.

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

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

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

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

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

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

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

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

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

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


\hy-10{2008}{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{2009}{o}  the pin area
\hy-8{2010}{o}  the user area
\hy-8{2011}{o}  the command area
\hy-8{2012}{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{2013}{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{2014}{wxEnhDialogBox::wxEnhDialogBox}

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

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

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

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

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

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

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

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


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



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

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

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

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

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

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

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

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

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


\hy-10{2102}{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:


Point size
    This is the standard way of referring to text size.

Family
    Supported families are:
  \hy-8{2103}{wxDEFAULT, wxDECORATIVE, wxROMAN, wxSCRIPT, wxSWISS, wxMODERN}.
  \hy-8{2104}{wxMODERN} is a fixed pitch font; the others are either fixed or variable pitch.

Style
    The value can be \hy-8{2105}{wxNORMAL, wxSLANT} or \hy-8{2106}{wxITALIC}.

Weight
    The value can be \hy-8{2107}{wxNORMAL, wxLIGHT} or \hy-8{2108}{wxBOLD}.

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{2109}{wxFont::wxFont}

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

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

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

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

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

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


\hy-10{2146}{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{2147}{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{2148}{wxFontList::wxFontList}

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

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

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


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



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

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

\hy-8{2174}{Form appearance}

\hy-8{2177}{Example}

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

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

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

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

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

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

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

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

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

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

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

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

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

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


\hy-10{2327}{wxFormItem: wxObject}



A form item is a data structure for representing a panel item (control, widget) in a form.
It is returned from \hy-8{2328}{wxMakeForm...} function and normally you will not need a handle
to it except to pass it to \hy-13{2329}{wxForm::Add}. However, you may wish
to get the actual panel item from the form item, for example to disable the panel item.
In which case, save a handle to the form item, then call (for
example) \hy-13{2330}{wxFormItem::GetPanelItem} \hy-7{2331}{after} you
have associated the form and the panel or dialog box.

\hy-8{2332}{wxFormItem::GetPanelItem}


\hy-10{2338}{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{2339}{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{2340}{wxCanvas}, \hy-13{2341}{wxPanel}
and \hy-13{2342}{wxTextWindow}.

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

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

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

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

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

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

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

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

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

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

\hy-8{2406}{wxFrame::LoadAccelerators}

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

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

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

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

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

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

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

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

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

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


\hy-10{2474}{wxFunction}

.

The type of a panel item callback function.

\hy-8{2475}{wxFunction}


\hy-10{2483}{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{2484}{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{2485}{#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{2486}{wxDC::DrawIcon}, \hy-13{2487}{wxBitmap}.

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

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


\hy-10{2502}{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{2503}{  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{2504}{wxList}.

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

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

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

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

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

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

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

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

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


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



The \hy-8{2558}{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{2559}{wxHelpInstance} is called (for example in the \hy-8{2560}{
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{2561}{
wxHelpInstance} when it starts, and immediately call \hy-8{2562}{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{2563}{wx_help.h} to use this API, even if you have
included \hy-14{2564}{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{2565}{wxHelpInstance::wxHelpInstance}

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

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

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

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

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

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

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

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

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


\hy-10{2604}{wxIntPoint: wxObject}



A \hy-8{2605}{wxIntPoint} is a useful data structure for graphics operations.
It contains integer point \hy-7{2606}{x} and \hy-7{2607}{y} members.
See also \hy-13{2608}{wxPoint} for a floating point version.

\hy-8{2609}{wxIntPoint::wxIntPoint}


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



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

The following styles may be used for any panel item:


wxFIXED_LENGTH
    The label of the item is created with a width
proportional to the length of the label string, regardless of proportional
font in use. This allows alignment of items if all items are given labels
of the same length.



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

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

\hy-8{2634}{wxItem::GetBackgroundColour}

\hy-8{2637}{wxItem::GetButtonColour}

\hy-8{2640}{wxItem::GetLabelColour}

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

\hy-8{2646}{wxItem::SetBackgroundColour}

\hy-8{2650}{wxItem::SetButtonColour}

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

\hy-8{2658}{wxItem::SetLabelColour}


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



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

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

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

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

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

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

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

\hy-8{2686}{wxKeyEvent::Position}

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


\hy-10{2695}{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{2696}{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{2697}{  ...
  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{2698}{    ...
    node = node->Next();
    ...
}
with

\hy-14{2699}{    ...
    delete point;
    delete node;
    node = SomeList.First();
    ...
}
See \hy-13{2700}{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{2701}{wxObject} and derived types, other
types (such as char *) may be used with appropriate casting.

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

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

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

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

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

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

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

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

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

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

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

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

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

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


\hy-10{2783}{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).

Please note that under XView, the height of a listbox cannot be set
accurately, since internally, the number of rows must be used to set
the height. So it is unlikely that the value returned by \hy-7{2784}{GetSize} will
be the same as passed to \hy-7{2785}{SetSize}.

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

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

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

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

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

\hy-8{2830}{wxListBox::Create}

\hy-8{2846}{wxListBox::Delete}

\hy-8{2850}{wxListBox::Deselect}

\hy-8{2854}{wxListBox::FindString}

\hy-8{2858}{wxListBox::GetClientData}

\hy-8{2862}{wxListBox::GetSelection}

\hy-8{2865}{wxListBox::GetSelections}

\hy-8{2869}{wxListBox::GetStringSelection}

\hy-8{2872}{wxListBox::Selected}

\hy-8{2876}{wxListBox::Set}

\hy-8{2881}{wxListBox::SetFirstItem}

\hy-8{2887}{wxListBox::SetSelection}

\hy-8{2892}{wxListBox::SetStringSelection}

\hy-8{2896}{wxListBox::GetString}


\hy-10{2902}{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{2903}{  // 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{2904}{must} be deleted before a bitmap
can be reselected into another memory DC.

See also \hy-13{2905}{wxBitmap}, \hy-13{2906}{wxDC}, \hy-13{2907}{wxCanvasDC}.

\hy-8{2908}{wxMemoryDC::wxMemoryDC}

\hy-8{2914}{wxMemoryDC::SelectObject}


\hy-10{2921}{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{2922}{wxFrame::OnMenuCommand} and \hy-13{2923}{wxWindow::PopupMenu}.

\hy-8{2924}{wxMenu::wxMenu}

\hy-8{2930}{wxMenu::~wxMenu}

\hy-8{2933}{wxMenu::Append}

\hy-8{2950}{wxMenu::AppendSeparator}

\hy-8{2953}{wxMenu::Check}

\hy-8{2959}{wxMenu::Enable}

\hy-8{2965}{wxMenu::FindItem}

\hy-8{2969}{wxMenu::FindItemForId}

\hy-8{2973}{wxMenu::GetHelpString}

\hy-8{2977}{wxMenu::GetLabel}

\hy-8{2983}{wxMenu::GetTitle}

\hy-8{2986}{wxMenu::SetHelpString}

\hy-8{2991}{wxMenu::SetLabel}

\hy-8{2998}{wxMenu::SetTitle}


\hy-10{3003}{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{3004}{
MenuSelection} message to be passed to the frame with the menu item
integer id as the only argument.

\hy-8{3005}{wxMenuBar::wxMenuBar}

\hy-8{3012}{wxMenuBar::~wxMenuBar}

\hy-8{3015}{wxMenuBar::Append}

\hy-8{3021}{wxMenuBar::Check}

\hy-8{3027}{wxMenuBar::Enable}

\hy-8{3033}{wxMenuBar::EnableTop}

\hy-8{3039}{wxMenuBar::FindMenuItem}

\hy-8{3044}{wxMenuBar::FindItemById}

\hy-8{3048}{wxMenuBar::GetHelpString}

\hy-8{3052}{wxMenuBar::GetLabel}

\hy-8{3057}{wxMenuBar::GetLabelTop}

\hy-8{3063}{wxMenuBar::SetHelpString}

\hy-8{3068}{wxMenuBar::SetLabel}

\hy-8{3074}{wxMenuBar::SetLabelTop}


\hy-10{3082}{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{3083}{wxMessage::wxMessage}

\hy-8{3097}{wxMessage::~wxMessage}

\hy-8{3100}{wxMessage::Create}


\hy-10{3111}{wxMetaFile: wxObject}



A \hy-8{3112}{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{3113}{wxMetaFile::wxMetaFile}

\hy-8{3118}{wxMetaFile::~wxMetaFile}

\hy-8{3121}{wxMetaFile::Ok}

\hy-8{3124}{wxMetaFile::Play}

\hy-8{3128}{wxMetaFile::SetClipboard}


\hy-10{3136}{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{3137}{wxDC}. The \hy-13{3138}{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{3139}{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{3140}{::wxMakeMetaFilePlaceable} after
closing your disk-based metafile device context.

\hy-8{3141}{wxMetaFileDC::wxMetaFileDC}

\hy-8{3145}{wxMetaFileDC::~wxMetaFileDC}

\hy-8{3148}{wxMetaFileDC::Close}


\hy-10{3152}{wxMouseEvent: wxEvent}



This event class contains information about mouse events, particularly
events received by canvases. See \hy-13{3153}{wxCanvas::OnEvent}.

\hy-8{3154}{wxMouseEvent::controlDown}

\hy-8{3157}{wxMouseEvent::leftDown}

\hy-8{3160}{wxMouseEvent::middleDown}

\hy-8{3163}{wxMouseEvent::rightDown}

\hy-8{3166}{wxMouseEvent::leftDown}

\hy-8{3169}{wxMouseEvent::shiftDown}

\hy-8{3172}{wxMouseEvent::x}

\hy-8{3175}{wxMouseEvent::y}

\hy-8{3178}{wxMouseEvent::wxMouseEvent}

\hy-8{3206}{wxMouseEvent::Button}

\hy-8{3211}{wxMouseEvent::ButtonDClick}

\hy-8{3216}{wxMouseEvent::ButtonDown}

\hy-8{3220}{wxMouseEvent::ButtonUp}

\hy-8{3224}{wxMouseEvent::ControlDown}

\hy-8{3227}{wxMouseEvent::Dragging}

\hy-8{3230}{wxMouseEvent::Entering}

\hy-8{3234}{wxMouseEvent::IsButton}

\hy-8{3238}{wxMouseEvent::Leaving}

\hy-8{3242}{wxMouseEvent::LeftDown}

\hy-8{3245}{wxMouseEvent::LeftIsDown}

\hy-8{3248}{wxMouseEvent::LeftUp}

\hy-8{3251}{wxMouseEvent::MiddleDown}

\hy-8{3254}{wxMouseEvent::MiddleIsDown}

\hy-8{3257}{wxMouseEvent::MiddleUp}

\hy-8{3260}{wxMouseEvent::Moving}

\hy-8{3263}{wxMouseEvent::Position}

\hy-8{3271}{wxMouseEvent::RightDown}

\hy-8{3274}{wxMouseEvent::RightIsDown}

\hy-8{3277}{wxMouseEvent::RightUp}

\hy-8{3280}{wxMouseEvent::ShiftDown}


\hy-10{3284}{wxMultiText: wxText}



Members as for \hy-8{3285}{wxText}, but allowing multiple lines of text.

If the \hy-7{3286}{style} parameter is wxHSCROLL, a horizontal scrollbar
will be displayed. If wxHSCROLL is omitted, only a vertical
scrollbar is displayed, and lines will be wrapped. This parameter
is ignored under XView.

\hy-8{3287}{wxMultiText::GetValue}


\hy-10{3294}{wxNode: wxObject}



A node structure used in linked lists (see \hy-13{3295}{wxList}).

\hy-8{3296}{wxNode::Data}

\hy-8{3299}{wxNode::Next}

\hy-8{3302}{wxNode::Previous}

\hy-8{3305}{wxNode::SetData}


\hy-10{3309}{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{3310}{wxObject::__type}


\hy-10{3316}{wxPanel: wxWindow}



A panel is a subwindow of a frame in which \hy-7{3317}{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{3318}{Fit} to fit the panel around its items.

\hy-8{3319}{wxPanel::wxPanel}

\hy-8{3345}{wxPanel::~wxPanel}

\hy-8{3348}{wxPanel::Create}

\hy-8{3359}{wxPanel::Fit}

\hy-8{3362}{wxPanel::GetButtonFont}

\hy-8{3365}{wxPanel::GetCursor}

\hy-8{3370}{wxPanel::GetDefaultItem}

\hy-8{3374}{wxPanel::GetHorizontalSpacing}

\hy-8{3377}{wxPanel::GetLabelFont}

\hy-8{3380}{wxPanel::GetVerticalSpacing}

\hy-8{3383}{wxPanel::NewLine}

\hy-8{3386}{wxPanel::OnDefaultAction}

\hy-8{3392}{wxPanel::SetHorizontalSpacing}

\hy-8{3396}{wxPanel::SetLabelPosition}

\hy-8{3407}{wxPanel::SetButtonFont}

\hy-8{3411}{wxPanel::SetLabelFont}

\hy-8{3415}{wxPanel::SetVerticalSpacing}

\hy-8{3419}{wxPanel::Tab}


\hy-10{3424}{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{3425}{FileNameFromPath} global function to extract the filename
from the path.

\hy-8{3426}{wxPathList::wxPathList}

\hy-8{3429}{wxPathList::AddEnvList}

\hy-8{3433}{wxPathList::AddPath}

\hy-8{3437}{wxPathList::FindValidPath}

\hy-8{3442}{wxPathList::Member}


\hy-10{3447}{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{3448}{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{3449}{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{3450}{
wxThePenList}, and calling the member function \hy-8{3451}{FindOrCreatePen}.
See the entry for \hy-13{3452}{wxPenList}.

\hy-8{3453}{wxPen::wxPen}

\hy-8{3465}{wxPen::~wxPen}

\hy-8{3469}{wxPen::GetCap}

\hy-8{3476}{wxPen::GetColour}

\hy-8{3479}{wxPen::GetJoin}

\hy-8{3486}{wxPen::GetStipple}

\hy-8{3489}{wxPen::GetStyle}

\hy-8{3492}{wxPen::GetWidth}

\hy-8{3495}{wxPen::SetCap}

\hy-8{3503}{wxPen::SetColour}

\hy-8{3513}{wxPen::SetJoin}

\hy-8{3521}{wxPen::SetStipple}

\hy-8{3525}{wxPen::SetStyle}

\hy-8{3529}{wxPen::SetWidth}


\hy-10{3534}{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{3535}{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{3536}{wxPenList::wxPenList}

\hy-8{3540}{wxPenList::AddPen}

\hy-8{3544}{wxPenList::FindOrCreatePen}

\hy-8{3554}{wxPenList::RemovePen}


\hy-10{3559}{wxPoint: wxObject}



A \hy-8{3560}{wxPoint} is a useful data structure for graphics operations.
It simply contains floating point \hy-7{3561}{x} and \hy-7{3562}{y} members.
See also \hy-13{3563}{wxIntPoint} for an integer version.

\hy-8{3564}{wxPoint::wxPoint}


\hy-10{3574}{wxPostScriptDC: wxDC}



This defines the wxWindows Encapsulated PostScript device context,
which can write PostScript files on any platform. See \hy-13{3575}{wxDC} for
descriptions of the member functions.

\hy-8{3576}{wxPostScriptDC::wxPostScriptDC}


\hy-10{3586}{wxPrinterDC: wxDC}



A printer device context is specific to Windows, and allows access to
any printer with a Windows driver. See \hy-13{3587}{wxDC} for further information
on device contexts, and \hy-13{3588}{wxDC::GetSize} for advice on
achieving the correct scaling for the page.

\hy-8{3589}{wxPrinterDC::wxPrinterDC}


\hy-10{3601}{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{3602}{wxRadioBox::wxRadioBox}

\hy-8{3643}{wxRadioBox::~wxRadioBox}

\hy-8{3646}{wxRadioBox::Create}

\hy-8{3675}{wxRadioBox::Enable}

\hy-8{3682}{wxRadioBox::FindString}

\hy-8{3686}{wxRadioBox::GetSelection}

\hy-8{3689}{wxRadioBox::GetStringSelection}

\hy-8{3692}{wxRadioBox::Number}

\hy-8{3695}{wxRadioBox::SetSelection}

\hy-8{3699}{wxRadioBox::SetStringSelection}

\hy-8{3703}{wxRadioBox::Show}

\hy-8{3708}{wxRadioBox::GetString}


\hy-10{3714}{wxServer: wxIPCObject}



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

\hy-8{3716}{wxServer::wxServer}

\hy-8{3719}{wxServer::Create}

\hy-8{3723}{wxServer::OnAcceptConnection}


\hy-10{3729}{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{3730}{wxSlider::wxSlider}

\hy-8{3750}{wxSlider::~wxSlider}

\hy-8{3753}{wxSlider::Create}

\hy-8{3768}{wxSlider::GetValue}

\hy-8{3771}{wxSlider::SetValue}


\hy-10{3776}{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{3777}{Delete}
member.

\hy-8{3778}{wxStringList::wxStringList}

\hy-8{3783}{wxStringList::~wxStringList}

\hy-8{3786}{wxStringList::Add}

\hy-8{3790}{wxStringList::Delete}

\hy-8{3794}{wxStringList::ListToArray}

\hy-8{3799}{wxStringList::Member}

\hy-8{3805}{wxStringList::Sort}


\hy-10{3809}{wxText: wxWindow}



A text item is an area of editable text, with an optional label
displayed in front of it.

The callback function specified for the text item will be called
for the following events:


\hy-8{3810}{o}  wxEVENT_TYPE_TEXT_COMMAND (text has changed)
\hy-8{3811}{o}  wxEVENT_TYPE_TEXT_ENTER_COMMAND (enter has been pressed:
if the wxPROCESS_ENTER style is used)
\hy-8{3812}{o}  under Windows, wxEVENT_TYPE_SET_FOCUS, wxEVENT_TYPE_KILL_FOCUS when
the focus changes.


\hy-8{3813}{wxText::wxText}

\hy-8{3835}{wxText::~wxText}

\hy-8{3838}{wxText::Create}

\hy-8{3852}{wxText::GetValue}

\hy-8{3855}{wxText::SetValue}


\hy-10{3861}{wxTextWindow: wxWindow}



A text window is a subwindow of a frame, offering some basic ability
to display scrolling text. Editing is possible under all platforms,
but if editing is required under Windows, the \hy-8{3862}{wxNATIVE_IMPL} style
should be included. This is because the default implementation is
a read-only text window that can display more than the 64K or so
of text allowed using the standard edit control.

Some manipulation functions take integer positions, starting from zero.

Many of these functions are currently platform-specific, and have yet
to be fully implemented or tested.

\hy-8{3863}{wxTextWindow::wxTextWindow}

\hy-8{3881}{wxTextWindow::~wxTextWindow}

\hy-8{3884}{wxTextWindow::Clear}

\hy-8{3887}{wxTextWindow::Create}

\hy-8{3898}{wxTextWindow::Copy}

\hy-8{3901}{wxTextWindow::Cut}

\hy-8{3904}{wxTextWindow::DiscardEdits}

\hy-8{3908}{wxTextWindow::GetContents}

\hy-8{3911}{wxTextWindow::GetInsertionPoint}

\hy-8{3914}{wxTextWindow::GetLastPosition}

\hy-8{3917}{wxTextWindow::GetLineLength}

\hy-8{3921}{wxTextWindow::GetLineText}

\hy-8{3926}{wxTextWindow::GetNumberOfLines}

\hy-8{3929}{wxTextWindow::SetSelection}

\hy-8{3936}{wxTextWindow::LoadFile}

\hy-8{3940}{wxTextWindow::Modified}

\hy-8{3943}{wxTextWindow::Paste}

\hy-8{3946}{wxTextWindow::PositionToXY}

\hy-8{3952}{wxTextWindow::Remove}

\hy-8{3959}{wxTextWindow::Replace}

\hy-8{3968}{wxTextWindow::SaveFile}

\hy-8{3972}{wxTextWindow::SetFont}

\hy-8{3976}{wxTextWindow::SetEditable}

\hy-8{3980}{wxTextWindow::SetInsertionPoint}

\hy-8{3985}{wxTextWindow::SetInsertionPointEnd}

\hy-8{3988}{wxTextWindow::ShowPosition}

\hy-8{3992}{wxTextWindow::WriteText}

\hy-8{3997}{wxTextWindow::XYToPosition}

\hy-8{4002}{wxTextWindow::<<}


\hy-10{4018}{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{4019}{Notify} member to
perform the required action. Start with \hy-8{4020}{Start}, stop with \hy-8{4021}{
Stop}, it's as simple as that.

See also \hy-13{4022}{::wxStartTimer} and \hy-13{4023}{::wxGetElapsedTime}
for stopwatch functions.

\hy-8{4024}{wxTimer::wxTimer}

\hy-8{4027}{wxTimer::~wxTimer}

\hy-8{4030}{wxTimer::Interval}

\hy-8{4033}{wxTimer::Notify}

\hy-8{4036}{wxTimer::Start}

\hy-8{4041}{wxTimer::Stop}


\hy-10{4045}{wxTypeTree: wxList}



wxTypeTree implements an explicit type hierarchy which can be useful for
querying C++ types at run-time, usually by calling \hy-13{4046}{wxSubType}
using the \hy-13{4047}{wxObject::__type} member.

A type is added to the global variable \hy-8{4048}{wxAllTypes}; wxWindows adds
its own standard types on initialization, in \hy-8{4049}{wxInitStandardTypes},
but the application can add its own.

The standard wxWindows types, grouped by functionality, are:


\hy-8{4050}{o}  wxTYPE_ANY
\hy-8{4051}{o}  wxTYPE_OBJECT (an alias for wxTYPE_ANY)
\hy-8{4052}{o}  wxTYPE_WINDOW
\hy-8{4053}{o}  wxTYPE_DIALOG_BOX
\hy-8{4054}{o}  wxTYPE_ITEM
\hy-8{4055}{o}  wxTYPE_PANEL
\hy-8{4056}{o}  wxTYPE_CANVAS
\hy-8{4057}{o}  wxTYPE_TEXT_WINDOW
\hy-8{4058}{o}  wxTYPE_FRAME
\hy-8{4059}{o}  wxTYPE_BUTTON
\hy-8{4060}{o}  wxTYPE_TEXT
\hy-8{4061}{o}  wxTYPE_MESSAGE
\hy-8{4062}{o}  wxTYPE_CHOICE
\hy-8{4063}{o}  wxTYPE_LIST_BOX
\hy-8{4064}{o}  wxTYPE_SLIDER
\hy-8{4065}{o}  wxTYPE_CHECK_BOX
\hy-8{4066}{o}  wxTYPE_MENU
\hy-8{4067}{o}  wxTYPE_MENU_BAR
\hy-8{4068}{o}  wxTYPE_MULTI_TEXT
\hy-8{4069}{o}  wxTYPE_RADIO_BOX
\hy-8{4070}{o}  wxTYPE_EVENT
\hy-8{4071}{o}  wxTYPE_DC
\hy-8{4072}{o}  wxTYPE_DC_CANVAS
\hy-8{4073}{o}  wxTYPE_DC_POSTSCRIPT
\hy-8{4074}{o}  wxTYPE_DC_PRINTER
\hy-8{4075}{o}  wxTYPE_DC_METAFILE
\hy-8{4076}{o}  wxTYPE_DC_MEMORY
\hy-8{4077}{o}  wxTYPE_MOUSE_EVENT
\hy-8{4078}{o}  wxTYPE_KEY_EVENT
\hy-8{4079}{o}  wxTYPE_COMMAND_EVENT
\hy-8{4080}{o}  wxTYPE_PEN
\hy-8{4081}{o}  wxTYPE_BRUSH
\hy-8{4082}{o}  wxTYPE_FONT
\hy-8{4083}{o}  wxTYPE_ICON
\hy-8{4084}{o}  wxTYPE_BITMAP
\hy-8{4085}{o}  wxTYPE_METAFILE
\hy-8{4086}{o}  wxTYPE_TIMER
\hy-8{4087}{o}  wxTYPE_COLOUR
\hy-8{4088}{o}  wxTYPE_COLOURMAP
\hy-8{4089}{o}  wxTYPE_CURSOR
\hy-8{4090}{o}  wxTYPE_DDE_CLIENT
\hy-8{4091}{o}  wxTYPE_DDE_SERVER
\hy-8{4092}{o}  wxTYPE_DDE_CONNECTION
\hy-8{4093}{o}  wxTYPE_HELP_INSTANCE
\hy-8{4094}{o}  wxTYPE_LIST
\hy-8{4095}{o}  wxTYPE_STRING_LIST
\hy-8{4096}{o}  wxTYPE_HASH_TABLE
\hy-8{4097}{o}  wxTYPE_NODE
\hy-8{4098}{o}  wxTYPE_APP


\hy-8{4099}{wxTypeTree::wxTypeTree}

\hy-8{4102}{wxTypeTree::AddType}

\hy-8{4112}{wxTypeTree::GetName}


\hy-10{4117}{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{4118}{wxWindow::wxWindow}

\hy-8{4121}{wxWindow::~wxWindow}

\hy-8{4124}{wxWindow::AddChild}

\hy-8{4128}{wxWindow::CaptureMouse}

\hy-8{4132}{wxWindow::Center}

\hy-8{4137}{wxWindow::Centre}

\hy-8{4144}{wxWindow::ClientToScreen}

\hy-8{4151}{wxWindow::DestroyChildren}

\hy-8{4154}{wxWindow::DragAcceptFiles}

\hy-8{4158}{wxWindow::Enable}

\hy-8{4162}{wxWindow::GetCharHeight}

\hy-8{4165}{wxWindow::GetCharWidth}

\hy-8{4168}{wxWindow::GetChildren}

\hy-8{4171}{wxWindow::GetClientData}

\hy-8{4174}{wxWindow::GetClientSize}

\hy-8{4179}{wxWindow::GetGrandParent}

\hy-8{4182}{wxWindow::GetHandle}

\hy-8{4185}{wxWindow::GetPosition}

\hy-8{4190}{wxWindow::GetLabel}

\hy-8{4193}{wxWindow::GetParent}

\hy-8{4196}{wxWindow::GetSize}

\hy-8{4201}{wxWindow::GetTextExtent}

\hy-8{4207}{wxWindow::OnActivate}

\hy-8{4212}{wxWindow::OnChar}

\hy-8{4220}{wxWindow::OnDropFiles}

\hy-8{4232}{wxWindow::OnEvent}

\hy-8{4238}{wxWindow::OnKillFocus}

\hy-8{4241}{wxWindow::OnPaint}

\hy-8{4244}{wxWindow::PopupMenu}

\hy-8{4255}{wxWindow::OnSetFocus}

\hy-8{4258}{wxWindow::OnSize}

\hy-8{4264}{wxWindow::Refresh}

\hy-8{4267}{wxWindow::ReleaseMouse}

\hy-8{4271}{wxWindow::ScreenToClient}

\hy-8{4278}{wxWindow::SetFocus}

\hy-8{4282}{wxWindow::SetSize}

\hy-8{4289}{wxWindow::SetClientData}

\hy-8{4293}{wxWindow::SetClientSize}

\hy-8{4301}{wxWindow::SetColourMap}

\hy-8{4306}{wxWindow::SetCursor}

\hy-8{4312}{wxWindow::SetTitle}

\hy-8{4316}{wxWindow::Show}


\hy-10{4322}{File functions}



See also \hy-13{4323}{wxPathList}.

\hy-8{4324}{::DirExists}

\hy-8{4328}{::Dos2UnixFilename}

\hy-8{4332}{::FileExists}

\hy-8{4336}{::FileNameFromPath}

\hy-8{4340}{::IsAbsolutePath}

\hy-8{4344}{::PathOnly}

\hy-8{4348}{::Unix2DosFilename}

\hy-8{4352}{::wxConcatFiles}

\hy-8{4361}{::wxCopyFile}

\hy-8{4368}{::wxGetHostName}

\hy-8{4375}{::wxGetEmailAddress}

\hy-8{4382}{::wxGetUserId}

\hy-8{4389}{::wxGetUserName}

\hy-8{4398}{::wxGetWorkingDirectory}

\hy-8{4404}{::wxGetTempFileName}

\hy-8{4414}{::wxIsWild}

\hy-8{4419}{::wxMatchWild}

\hy-8{4429}{::wxMkdir}

\hy-8{4434}{::wxRemoveFile}

\hy-8{4439}{::wxRenameFile}

\hy-8{4446}{::wxRmdir}


\hy-10{4452}{String functions}



\hy-8{4453}{::copystring}

\hy-8{4459}{::StringMatch}


\hy-10{4471}{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 or Motif) the wrong window frame may be brought to
the front when the dialog box is popped up.

\hy-8{4472}{::wxFileSelector}

\hy-8{4485}{::wxGetTextFromUser}

\hy-8{4499}{::wxGetMultipleChoice}

\hy-8{4518}{::wxGetSingleChoice}

\hy-8{4534}{::wxGetSingleChoiceIndex}

\hy-8{4548}{::wxGetSingleChoiceData}

\hy-8{4563}{::wxMessageBox}


\hy-10{4576}{GDI functions}



The following are relevant to the GDI (Graphics Device Interface).

\hy-8{4577}{::wxColourDisplay}

\hy-8{4580}{::wxDisplayDepth}

\hy-8{4583}{::wxMakeMetaFilePlaceable}

\hy-8{4595}{::wxSetCursor}


\hy-10{4602}{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{4603}{wxSendEvent} will probably work if you
instantiate the event structure properly for a command event type (see
the code in \hy-14{4604}{wb_panel.cc} for \hy-13{4605}{wxPanel::OnDefaultAction}
which uses \hy-8{4606}{wxSendEvent} to send a command to the default button).

\hy-8{4607}{::wxAddPrimaryEventHandler}

\hy-8{4611}{::wxAddSecondaryEventHandler}

\hy-8{4618}{::wxNotifyEvent}

\hy-8{4623}{::wxRegisterEventClass}

\hy-8{4630}{::wxRegisterEventName}

\hy-8{4637}{::wxRegisterExternalEventHandlers}

\hy-8{4640}{::wxRemoveSecondaryEventHandler}

\hy-8{4645}{::wxSendEvent}


\hy-10{4651}{Printer settings}



The following functions are used to control PostScript printing. Under
Windows, PostScript output can only be sent to a file.

\hy-8{4652}{::wxGetPrinterCommand}

\hy-8{4656}{::wxGetPrinterFile}

\hy-8{4659}{::wxGetPrinterMode}

\hy-8{4662}{::wxGetPrinterOptions}

\hy-8{4665}{::wxGetPrinterOrientation}

\hy-8{4668}{::wxGetPrinterPreviewCommand}

\hy-8{4671}{::wxGetPrinterScaling}

\hy-8{4676}{::wxGetPrinterTranslation}

\hy-8{4681}{::wxSetPrinterCommand}

\hy-8{4686}{::wxSetPrinterFile}

\hy-8{4690}{::wxSetPrinterMode}

\hy-8{4694}{::wxSetPrinterOptions}

\hy-8{4698}{::wxSetPrinterOrientation}

\hy-8{4702}{::wxSetPrinterPreviewCommand}

\hy-8{4706}{::wxSetPrinterScaling}

\hy-8{4711}{::wxSetPrinterTranslation}


\hy-10{4717}{Miscellaneous}



\hy-8{4718}{::NewId}

\hy-8{4721}{::RegisterId}

\hy-8{4727}{::wxBeginBusyCursor}

\hy-8{4733}{::wxBell}

\hy-8{4736}{::wxDebugMsg}

\hy-8{4742}{::wxDisplaySize}

\hy-8{4747}{::wxError}

\hy-8{4754}{::wxEndBusyCursor}

\hy-8{4759}{::wxExecute}

\hy-8{4770}{::wxExit}

\hy-8{4776}{::wxFatalError}

\hy-8{4783}{::wxFindFirstFile}

\hy-8{4794}{::wxFindNextFile}

\hy-8{4799}{::wxFindMenuItemId}

\hy-8{4805}{::wxFindWindowByLabel}

\hy-8{4811}{::wxGetHomeDir}

\hy-8{4815}{::wxGetHostName}

\hy-8{4822}{::wxGetElapsedTime}

\hy-8{4829}{::wxGetFreeMemory}

\hy-8{4832}{::wxGetOsVersion}

\hy-8{4847}{::wxGetResource}

\hy-8{4871}{::wxGetUserId}

\hy-8{4878}{::wxGetUserName}

\hy-8{4885}{::wxIPCInitialize}

\hy-8{4891}{::wxIsBusy}

\hy-8{4896}{::wxShell}

\hy-8{4901}{::wxSleep}

\hy-8{4906}{::wxStripMenuCodes}

\hy-8{4913}{::wxStartTimer}

\hy-8{4918}{::wxSubType}

\hy-8{4928}{::wxToLower}

\hy-8{4932}{::wxToUpper}

\hy-8{4936}{::wxWriteResource}

\hy-8{4961}{::wxYield}


\hy-10{4967}{API}



Application Programmer's Interface - a set of calls and classes defining
how a library (in this case, wxWindows) can be used.


\hy-10{4969}{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{4970}{device context} associated with it.


\hy-10{4972}{DDE}



Dynamic Data Exchange - Microsoft's interprocess communication protocol.
wxWindows provides an abstraction of DDE under both Windows and UNIX.


\hy-10{4974}{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{4976}{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{4978}{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{4980}{GNU C++}



A free, solid C++ compiler which may be used to compile the UNIX side of
wxWindows applications.


\hy-10{4982}{GUI}



Graphical User Interface, such as Windows 3 or X.


\hy-10{4984}{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{4986}{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{4988}{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{4990}{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{4992}{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{4994}{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{4995}{hello} demo). XView has a status line (or footer) capability, but
wxWindows implements the feature explicitly under Windows 3 and Motif.


\hy-10{4997}{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{4999}{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{96}{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{97}{Memory Models}.

I have decided to include largely automatic, albeit relatively
inflexible, support for MDI for these reasons:


\hy-8{98}{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{99}{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{100}{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{101}{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{102}{mdi} shows how a program can easily be made
switchable between SDI and MDI - use the \hy-8{103}{-mdi} command switch for
MDI operation.


\hy-10{121}{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{122}{class}
encapsulates a range of similar event \hy-7{123}{types}. For example, the
instances of the \hy-8{124}{wxMouseEvent} class may be generated for a number
of event types such as \hy-8{125}{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{126}{CLIPS}).


\hy-10{166}{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
established (if long in the tooth) 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 raw 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. The WinSock implementation
will probably soon be incorporated into wxWindows.


\hy-10{168}{Principles of DDE}



The following describes how wxWindows implements DDE.  The following
three classes are crucial.


\hy-8{169}{1.}  wxClient. This represents the client application, and is used
only within a client program.
\hy-8{170}{2.}  wxServer. This represents the server application, and is used
only within a server program.
\hy-8{171}{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{172}{
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{173}{1.}  Derive a class from wxServer.
\hy-8{174}{2.}  Override the handler \hy-8{175}{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{176}{3.}  Create an instance of your server object, and call \hy-8{177}{Create} to
activate it, giving it a service name.
\hy-8{178}{4.}  Derive a class from wxConnection.
\hy-8{179}{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{180}{1.}  Derive a class from wxClient.
\hy-8{181}{2.}  Override the handler \hy-8{182}{OnMakeConnection} to create and return
an appropriate connection object.
\hy-8{183}{3.}  Create an instance of your client object.
\hy-8{184}{4.}  Derive a class from wxConnection.
\hy-8{185}{5.}  Provide handlers for various messages that are sent to the client
side of a wxConnection.
\hy-8{186}{6.}  When appropriate, create a new connection by sending a \hy-8{187}{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{188}{OnMakeConnection}
to create a connection object of the desired type.
\hy-8{189}{7.}  Use the wxConnection member functions to send messages to the server.



\hy-10{191}{Data transfer}



These are the ways that data can be transferred from one application to
another.


\hy-8{192}{o}  \hy-8{193}{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{194}{o}  \hy-8{195}{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{196}{o}  \hy-8{197}{Poke:} The client sends a data string associated with an item
string directly to the server. This succeeds or fails.
\hy-8{198}{o}  \hy-8{199}{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{201}{Examples}



See the sample programs \hy-7{202}{server} and \hy-7{203}{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{205}{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{206}{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{207}{PROLOGIO}.


\hy-10{278}{General features}




USE_POSTSCRIPT
    If 1, PostScript code is compiled.

USE_METAFILE
    If 1, Windows Metafile code is compiled.

USE_FORM
    If 1, wxForm code is compiled.

USE_IPC
    If 1, interprocess communication code is compiled.

USE_HELP
    If 1, interface to help system is compiled.

USE_ENHANCED_DIALOG
    If 1, enhanced dialog box code is compiled.

USE_RESOURCES
    If 1, resource read/write code is compiled.

USE_CLIPBOARD
    If 1, clipboard code is compiled (Windows only).

USE_SPLINES
    If 1, spline code is compiled.

USE_XFIG_SPLINE_CODE
    If 1, XFig-derived code is used for spline
drawing. If 0, AIAI code is used, which is slower.

USE_DRAG_AND_DROP
    If 1, drag and drop code is compiled (Windows only).

USE_PANEL_IN_PANEL
    If 1, experimental panel-in-panel code is used
for common dialog boxes. Not recommended, since tab traversal can suffer.

USE_TYPEDEFS
    If 1, a typedef will be used for wxPoint instead of
a class declaration, to reduce overhead and avoid a Microsoft C++ memory bug.

ENHANCED_FONTS
    Define to be 1 to have pre-defined fonts in wxEnhDialogBox.




\hy-10{280}{X features}




PIXEL0_DISABLE
    Define to disallow allocation of pixel 0 (wxXOR problem).

DEFAULT_FILE_SELECTOR_SIZE
    Let Motif choose the size of
XmFileSelectionBox. Otherwise, size is 500x600.

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

USE_BUTTON_GADGET
    Use gadgets for buttons. This can intefere with
default button selection, so the default is zero.

wxFSB_WIDTH
    Width of file selector box, if fixed.

wxFSB_HEIGHT
    Height of file selector box, if fixed.




\hy-10{282}{Windows and NT features}




CTL3D
    It is recommended that CTL3D is used under Windows, since the 3D effects
are good-looking and will be standard with Windows 4.0.  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 ctl3dv2.dll into windows/system). ctl3d.lib \hy-7{283}{should} work
with all compilers. Define CTL3D to be 1 in wx_setup.h and link your
executables with CTL3D.LIB.

If both CTL3D and FAFA are set to 1, then all controls except wxButton
will use CTL3D and have 3D appearances. wxButton will have the ability
to use bitmaps. This is the recommended configuration.

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

An application using the Fafa library must include fafa.rc in the
its RC file. Otherwise, some controls will not show up.

USE_GREY_BACKGROUND
    If 1, will use grey for panel and
dialog backgrounds (Julian Smart's preferred setting). Grey is used
by CTL3D anyway. If this is set to 0 and USE_FAFA is set to 1,
you may see unsatisfactory display of some control backgrounds.

If both CTL3D and FAFA are set to 1, then all controls except wxButton
will use CTL3D and have 3D appearances. wxButton will have the ability
to use bitmaps. This is the recommended configuration.




\hy-10{290}{DOS makefiles}



For Microsoft C++, normally it is only necessary to type \hy-14{291}{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{293}{UNIX makefiles}



All makefiles have the targets \hy-7{294}{xview}, \hy-7{295}{motif} and \hy-7{296}{hp}.

\hy-7{297}{xview} builds an Sun Open Look version of the library, \hy-7{298}{motif}
builds a Sun Motif version, and \hy-7{299}{hp} builds a Motif version for HP
workstations.

Remove object files, executables and libraries for the
current module with the \hy-7{300}{clean_ol} and \hy-7{301}{clean_motif} and
\hy-7{302}{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{303}{objects_ol} and \hy-7{304}{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{305}{strip}
command to remove debugging information from an executable.

----------------------------------------------------------------------
\hy-7{306}{Important note:} Most compiler flags are kept centrally in
src/make.env, which is included by all other makefiles. This is the
file to edit to tailor wxWindows compilation to your environment.
----------------------------------------------------------------------



\hy-10{310}{Resource file}



The least that must be defined in the resource file (extension RC)
is the following statement:

\hy-14{311}{rcinclude wx.rc
}
which includes essential internal wxWindows definitions.  The resource script
may also contain references to icons, cursors, etc., for example:

\hy-14{312}{wxicon icon wx.ico
}
The icon can then be referenced by name when creating a frame icon. See
the Windows 3.1 SDK documentation.

----------------------------------------------------------------------
Note: include wx.rc \hy-7{313}{after} any ICON statements
so programs that search your executable for icons (such
as the Program Manager) find your application icon first.
----------------------------------------------------------------------



\hy-10{315}{Module definition file}



A module definition file (extension DEF) looks like the following:

\hy-14{316}{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{353}{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{355}{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{356}{MyClass::MyClass(int x, int y):ParentClass(x, y)
{
}
}
This is not a problem where the constructor has no parameters.


\hy-10{358}{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{359}{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{360}{mycallback}
is a subtype of \hy-8{361}{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{362}{wxButton button(parent, (wxFunction)&mycallback, label, 100, 200);
}

\hy-10{364}{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{365}{``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{366}{``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. For this reason, you will find (in the common
X and Windows parts of the library) conditional
compilation that under UNIX, includes a minimal set of headers;
and when using Visual C++, includes \hy-14{367}{wx.h}. This should help provide
the optimal compilation for each compiler, although it is
biassed towards the precompiled headers facility available
in Microsoft C++.


\hy-10{467}{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{468}{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{469}{File} menu
which in turn has a \hy-8{470}{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{471}{minimal.cc}.

\hy-12{472}{
\hy-14{473}{/*
 * 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, 400);

  panel->SetLabelPosition(wxHORIZONTAL) ;
  (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{474}{#include "wx.h"} provides the program with access to
all the wxWindows classes and functions.

The first class declaration, \hy-8{475}{MyApp}, declares a new application,
overriding one member function \hy-8{476}{OnInit}. This is an essential part
of writing a wxWindows program, since \hy-8{477}{OnInit} is the equivalent of
\hy-8{478}{main} in a normal C++ program.

The class \hy-8{479}{MyFrame} declares a constructor, and a message handler
for intercepting menu commands.

The definition of the global variable \hy-8{480}{myApp} looks innocuous enough
but this starts the whole application going simply by being defined.

The \hy-8{481}{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{482}{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{483}{OnMenuCommand} definition intercepts menu commands for the main
frame. If the option chosen is \hy-8{484}{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{485}{OnClose} handler so that a system-generated \hy-8{486}{
OnClose} event will enable the program to clean itself up first.
System-generated \hy-8{487}{OnClose} events delete the main frame after calling
\hy-8{488}{OnClose}, so this should not be done from within \hy-8{489}{OnClose}.


\hy-10{491}{More advanced features: the \hy-7{492}{hello} demo}



The `Hello wxWindows' demo (source files, \hy-14{493}{hello.cc} and \hy-14{494}{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{495}{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{496}{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{497}{Cursor} menu enables the canvas cursor to be changed, and lets
the potential wxWindows programmer view the available standard cursors.

The \hy-8{498}{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{499}{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{500}{
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{501}{Fit}.

\hy-8{502}{MyFrame's} \hy-8{503}{OnSize} member sizes each subwindow in proportion
to the new size of the frame. \hy-8{504}{MyCanvas's} \hy-8{505}{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{506}{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{508}{The MDI demo}



As explained in the manual (see \hy-13{509}{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{510}{mdi} example program shows this run-time switching. Invoked
without a command line switch, it defaults to SDI. Invoked with the
switch \hy-14{511}{-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{512}{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{514}{The IPC demo}



The demo in the \hy-14{515}{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{516}{server}, then \hy-14{517}{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{518}{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{519}{Request}
menu item from the client's \hy-8{520}{File} menu. The window which pops up
is created by the client and contains a message that the server sent back.

Selecting \hy-8{521}{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{522}{Poke} menu item sends a \hy-7{523}{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{593}{wxApp::wxApp}



\hy-8{594}{void wxApp(int \hy-8{595}{ 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{597}{wxApp::~wxApp}



\hy-8{598}{void ~wxApp(void)}

Destructor. Will be called implicitly on program exit if the wxApp
object is created on the stack.


\hy-10{600}{wxApp::argc}



\hy-8{601}{int argc}

Number of command line arguments (after environment-specific processing).


\hy-10{603}{wxApp::argv}



\hy-8{604}{char ** argv}

Command line arguments (after environment-specific processing).


\hy-10{606}{wxApp::wx_class}



\hy-8{607}{char * wx_class}

Currently used under Motif only, where the value is passed to \hy-7{608}{
XtOpenDisplay} on initialization. Set this member in the constructor of
your derived \hy-8{609}{wxApp} class to give the application a name other than
the default \hy-7{610}{``wxApp''}.


\hy-10{612}{wxApp::Dispatch}



\hy-8{613}{void Dispatch(void)}

Dispatches the next event in the windowing system event queue.
(Windows 3.1, WIN32, and Motif). See also \hy-13{614}{wxApp::Pending}.

This can be used for programming event loops, e.g.

\hy-14{615}{  while (app.Pending())
    Dispatch();
}

\hy-10{617}{wxApp::Initialized}



\hy-8{618}{Bool Initialized(void)}

Returns TRUE if the application has been initialized (i.e. if
\hy-13{619}{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{621}{wxApp::MainLoop}



\hy-8{622}{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{624}{wxApp::OnExit}



\hy-8{625}{void OnExit(void)}

Provide this member function for any processing which needs to be done as
the application is about to exit.


\hy-10{627}{wxApp::OnInit}



\hy-8{628}{wxFrame * OnInit(void)}

This must be provided by the application, and must create and return the
application's main window.


\hy-10{630}{wxApp::Pending}



\hy-8{631}{Bool Pending(void)}

Returns TRUE if unprocessed events are in the window system event queue
(Windows 3.1, WIN32, and Motif). See also \hy-13{632}{wxApp::Dispatch}.


\hy-10{642}{Loading bitmaps: further information}



See also the DIB and wxImage libraries distributed with
wxWindows. DIB allows loading of .BMP files under Windows, and
wxImage allows loading of a variety of bitmap formats under X.
wxBuilder makes use of both of these packages: search for wxLoadBitmap
for example of usage.


\hy-10{644}{wxBitmap::wxBitmap}



\hy-8{645}{void wxBitmap(char \hy-8{646}{ bits[]}, int \hy-8{647}{ width}, int \hy-8{648}{ height}

  int \hy-8{649}{ depth = 1})}

Constructs a (usually monochrome) bitmap from an array of pixel values, under both
X and Windows.

\hy-8{650}{void wxBitmap(int \hy-8{651}{ width}, int \hy-8{652}{ height} int \hy-8{653}{ depth = -1})}

Constructs a new bitmap. If the final argument is omitted, the display depth of
the screen is used.

\hy-8{654}{void wxBitmap(char * \hy-8{655}{ icon_name})}

Constructs a bitmap by passing a string name. \hy-7{656}{icon_name} refers
to an XBM filename in X, a resource name in Windows 3.


\hy-10{658}{wxBitmap::~wxBitmap}



\hy-8{659}{void ~wxBitmap(void)}

Destroys the bitmap. The bitmap will be destroyed automatically by wxWindows
when the application exits.


\hy-10{661}{wxBitmap::GetDepth}



\hy-8{662}{int GetDepth(void)}

Gets the colour depth of the bitmap. A value of 1 indicates a
monochrome bitmap.


\hy-10{664}{wxBitmap::GetHeight}



\hy-8{665}{int GetHeight(void)}

Gets the height of the bitmap in pixels.


\hy-10{667}{wxBitmap::GetWidth}



\hy-8{668}{int GetWidth(void)}

Gets the width of the bitmap in pixels.


\hy-10{670}{wxBitmap::Ok}



\hy-8{671}{Bool Ok(void)}

Returns TRUE if the bitmap was successfully created.


\hy-10{682}{wxBrush::wxBrush}



\hy-8{683}{void wxBrush(void)}

\hy-8{684}{void wxBrush(wxColour & \hy-8{685}{colour}, int \hy-8{686}{ style})}

\hy-8{687}{void wxBrush(char * \hy-8{688}{colour_name}, int \hy-8{689}{ 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{690}{wxColour} structure is found
in the colour database.


\hy-10{692}{wxBrush::~wxBrush}



\hy-8{693}{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.

If you have to delete a brush, then call
\hy-13{694}{wxDC::SetBrush} with a NULL argument to ensure that
the old brush is restored, and the current brush is selected out of the
device context.


\hy-10{696}{wxBrush::GetColour}



\hy-8{697}{wxColour& GetColour(void)}

Returns a reference to the brush colour.


\hy-10{699}{wxBrush::GetStipple}



\hy-8{700}{wxBitmap * GetStipple(void)}

Gets the stipple bitmap.


\hy-10{702}{wxBrush::GetStyle}



\hy-8{703}{int GetStyle(void)}

Returns the brush style, one of:


\hy-8{704}{o}  wxTRANSPARENT
\hy-8{705}{o}  wxSOLID
\hy-8{706}{o}  wxBDIAGONAL_HATCH
\hy-8{707}{o}  wxCROSSDIAG_HATCH
\hy-8{708}{o}  wxFDIAGONAL_HATCH
\hy-8{709}{o}  wxCROSS_HATCH
\hy-8{710}{o}  wxHORIZONTAL_HATCH
\hy-8{711}{o}  wxVERTICAL_HATCH



\hy-10{713}{wxBrush::SetColour}



\hy-8{714}{void SetColour(wxColour & \hy-8{715}{colour})}

\hy-8{716}{void SetColour(char * \hy-8{717}{colour_name})}

\hy-8{718}{void SetColour(int \hy-8{719}{ red}, int \hy-8{720}{ green}, int \hy-8{721}{ blue})}

The brush's colour is changed to the given colour.


\hy-10{723}{wxBrush::SetStipple}



\hy-8{724}{void SetStipple(wxBitmap * \hy-8{725}{bitmap})}

Sets the stipple bitmap.

Note that there is a big difference between stippling in X and Windows.
On X, the stipple is a mask between the wxBitmap and current colour.
On Windows, the current colour is ignored, and the bitmap colour is used.
However, for pre-defined modes like wxCROSS_HATCH, the behaviour is the
same for both platforms.


\hy-10{727}{wxBrush::SetStyle}



\hy-8{728}{void SetStyle(int \hy-8{729}{ style})}

Sets the brush style, one of:


\hy-8{730}{o}  wxTRANSPARENT
\hy-8{731}{o}  wxSOLID
\hy-8{732}{o}  wxBDIAGONAL_HATCH
\hy-8{733}{o}  wxCROSSDIAG_HATCH
\hy-8{734}{o}  wxFDIAGONAL_HATCH
\hy-8{735}{o}  wxCROSS_HATCH
\hy-8{736}{o}  wxHORIZONTAL_HATCH
\hy-8{737}{o}  wxVERTICAL_HATCH



\hy-10{743}{wxBrushList::wxBrushList}



\hy-8{744}{void wxBrushList(void)}

Constructor.  The application should not construct its own brush list:
use the object pointer \hy-8{745}{wxTheBrushList}.


\hy-10{747}{wxBrushList::AddBrush}



\hy-8{748}{void AddBrush(wxBrush * \hy-8{749}{brush})}

Used by wxWindows to add a brush to the list, called in the brush constructor.


\hy-10{751}{wxBrushList::FindOrCreateBrush}



\hy-8{752}{wxBrush * FindOrCreateBrush(wxColour * \hy-8{753}{colour}, int \hy-8{754}{ style})}

\hy-8{755}{wxBrush * FindOrCreateBrush(char * \hy-8{756}{colour_name}, int \hy-8{757}{ style})}

Finds a brush of the given specification, or creates one and adds it to the list.


\hy-10{759}{wxBrushList::RemoveBrush}



\hy-8{760}{void RemoveBrush(wxBrush * \hy-8{761}{brush})}

Used by wxWindows to remove a brush from the list.


\hy-10{768}{wxButton::wxButton}



\hy-8{769}{void wxButton(wxPanel * \hy-8{770}{parent}, wxFunction \hy-8{771}{ func}, char * \hy-8{772}{label},

  int \hy-8{773}{ x = -1}, int \hy-8{774}{ y = -1}, int \hy-8{775}{ width = -1}, int \hy-8{776}{ height = -1},

  long \hy-8{777}{ style = 0}, char * \hy-8{778}{name = ``button"})}

\hy-8{779}{void wxButton(wxPanel * \hy-8{780}{parent}, wxFunction \hy-8{781}{ func}, wxBitmap * \hy-8{782}{wxBitmap},

  int \hy-8{783}{ x = -1}, int \hy-8{784}{ y = -1}, int \hy-8{785}{ width = -1}, int \hy-8{786}{ height = -1},

  long \hy-8{787}{ style = 0}, char * \hy-8{788}{name = ``button"})}

Constructor, creating and showing a button. The parent must be a valid
panel or dialog box pointer.

\hy-7{789}{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{790}{wxFunction}.

The parameters \hy-7{791}{x} and \hy-7{792}{y} are used to specify an absolute
position, or a position after the previous panel item if omitted or
default.

If \hy-7{793}{width} or \hy-7{794}{height} are omitted (or are less than zero), an
appropriate size will be used for the item.  The \hy-7{795}{style} parameter
is reserved for future use. The \hy-7{796}{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{797}{label} will be shown on the button.
If the seond form is used, the \hy-7{798}{bitmap} will be used.


\hy-10{800}{wxButton::~wxButton}



\hy-8{801}{void ~wxButton(void)}

Destructor, destroying the button.


\hy-10{803}{wxButton::Create}



\hy-8{804}{void Create(wxPanel * \hy-8{805}{parent}, wxFunction \hy-8{806}{ func}, char * \hy-8{807}{label},

  int \hy-8{808}{ x = -1}, int \hy-8{809}{ y = -1}, int \hy-8{810}{ width = -1}, int \hy-8{811}{ height = -1},

  long \hy-8{812}{ style = 0}, char * \hy-8{813}{name = ``button"})}

\hy-8{814}{void Create(wxPanel * \hy-8{815}{parent}, wxFunction \hy-8{816}{ func}, wxBitmap * \hy-8{817}{wxBitmap},

  int \hy-8{818}{ x = -1}, int \hy-8{819}{ y = -1}, int \hy-8{820}{ width = -1}, int \hy-8{821}{ height = -1},

  long \hy-8{822}{ style = 0}, char * \hy-8{823}{name = ``button"})}

Button creation functions called by the button constructors. Call these
when a derived button class uses the zero-argument \hy-8{824}{wxButton}
constructor, but can reuse the existing button creation code.
See \hy-13{825}{wxButton::wxButton} for details.


\hy-10{827}{wxButton::SetDefault}



\hy-8{828}{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{829}{wxWindow::SetFocus}
which sets the keyboard focus for windows and text panel items, \hy-13{830}{wxPanel::OnDefaultAction}
and \hy-13{831}{wxPanel::GetDefaultItem}.

Note that under Motif, calling this function immediately after
creation of a button and before the creation of other buttons
will cause misalignment of the row of buttons, since default
buttons are larger. To get around this, call \hy-7{832}{SetDefault}
after you have created a row of buttons: wxWindows will
then set the size of all buttons currently on the panel to
the same size.


\hy-10{834}{wxButton::SetLabel}



\hy-8{835}{void SetLabel(wxBitmap * \hy-8{836}{label})}

Sets the bitmap for a bitmap button.


\hy-10{847}{wxCanvas::wxCanvas}



\hy-8{848}{void wxCanvas(wxFrame * \hy-8{849}{parent}, int \hy-8{850}{ x = -1}, int \hy-8{851}{ y = -1},

  int \hy-8{852}{ width = -1}, int \hy-8{853}{ height = -1},

  long \hy-8{854}{ style = wxRETAINED}, char * \hy-8{855}{name})}

Constructor.

The parameters \hy-7{856}{x}, \hy-7{857}{y}, \hy-7{858}{width} and \hy-7{859}{height}
can be omitted on construction if the position and size will later
be set (for example by a application frame's \hy-8{860}{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:


wxBORDER
    Gives the canvas a thin border (Windows 3 and Motif only).

wxRETAINED
    Gives the canvas a wxWindows-implemented backing store, making
repainting much faster but at a potentially costly memory premium (XView and Motif only).

wxBACKINGSTORE
    Gives the canvas an X-implemented backing store
(XView and Motif only). The X server may choose to ignore this request, whereas
wxRETAINED is always implemented under X.



The \hy-7{861}{name} parameter is used to associate a name with the canvas,
allowing the application user to set Motif resources for individual
canvases.


\hy-10{863}{wxCanvas::~wxCanvas}



\hy-8{864}{void ~wxCanvas(void)}

Destructor.


\hy-10{866}{wxCanvas::AllowDoubleClick}



\hy-8{867}{void AllowDoubleClick(Bool \hy-8{868}{ allow})}

Allows or disables double click handling on a canvas (Motif, Windows 3.1 and WIN32).
The default is FALSE. Note that this feature has not been rigorously tested.

See also \hy-13{869}{wxMouseEvent::ButtonDClick}.


\hy-10{871}{wxCanvas::BeginDrawing}



\hy-8{872}{void BeginDrawing(void)}

Allows optimization of drawing code under Windows 3.1 and WIN32. Enclose
drawing primitives between \hy-8{873}{BeginDrawing} and \hy-8{874}{EndDrawing}
calls.


\hy-10{876}{wxCanvas::Create}



\hy-8{877}{void Create(wxFrame * \hy-8{878}{parent}, int \hy-8{879}{ x = -1}, int \hy-8{880}{ y = -1},

  int \hy-8{881}{ width = -1}, int \hy-8{882}{ height = -1},

  long \hy-8{883}{ style = wxRETAINED}, char * \hy-8{884}{name})}

Creates the canvas for two-step construction. Derived classes
should call or replace this function. See \hy-13{885}{wxCanvas::wxCanvas}
for details.


\hy-10{887}{wxCanvas::Clear}



\hy-8{888}{void Clear(void)}

Clears the canvas (fills it with the current background brush).


\hy-10{890}{wxCanvas::DestroyClippingRegion}



\hy-8{891}{void DestroyClippingRegion(void)}

Destroys the current clipping region so that none of the canvas is clipped.


\hy-10{893}{wxCanvas::DrawArc}



\hy-8{894}{void DrawArc(float \hy-8{895}{ x1}, float \hy-8{896}{ y1}, float \hy-8{897}{ x2}, float \hy-8{898}{ y2}, float \hy-8{899}{xc}, float \hy-8{900}{yc})}

Draws an arc, centred on (\hy-7{901}{xc, yc}), with starting point (\hy-7{902}{x1, y1})
and ending at (\hy-7{903}{x2, y2}).   The current pen is used for the outline
and the current brush for filling the shape.


\hy-10{905}{wxCanvas::DrawEllipse}



\hy-8{906}{void DrawEllipse(float \hy-8{907}{ x}, float \hy-8{908}{ y}, float \hy-8{909}{ width},
float \hy-8{910}{ 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{912}{wxCanvas::DrawLine}



\hy-8{913}{void DrawLine(float \hy-8{914}{ x1}, float \hy-8{915}{ y1}, float \hy-8{916}{ x2},
float \hy-8{917}{ y2})}

Draws a line from the first point to the second. The current pen is
used for drawing the line.


\hy-10{919}{wxCanvas::DrawLines}



\hy-8{920}{void DrawLines(int \hy-8{921}{ n}, wxPoint \hy-8{922}{ points[]}, float \hy-8{923}{ xoffset = 0}, float \hy-8{924}{ yoffset = 0})}

\hy-8{925}{void DrawLines(wxList * \hy-8{926}{points}, float \hy-8{927}{ xoffset = 0}, float \hy-8{928}{ yoffset = 0})}

Draw lines using an array of \hy-7{929}{points} of size \hy-7{930}{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{932}{wxCanvas::DrawPolygon}



\hy-8{933}{void DrawPolygon(int \hy-8{934}{ n}, wxPoint \hy-8{935}{ points[]}, float \hy-8{936}{ xoffset = 0}, float \hy-8{937}{ yoffset = 0},

  int  \hy-8{938}{fill_style = wxODDEVEN_RULE})}

\hy-8{939}{void DrawPolygon(wxList * \hy-8{940}{points}, float \hy-8{941}{ xoffset = 0},
float \hy-8{942}{ yoffset = 0}, int  \hy-8{943}{fill_style = wxODDEVEN_RULE})}

Draw a filled polygon using an array of \hy-7{944}{points} of size \hy-7{945}{n},
or list of pointers to points, adding the optional offset coordinate.

The last argument specifies the fill rule: \hy-8{946}{wxODDEVEN_RULE} (the
default) or \hy-8{947}{wxWINDING_RULE}.

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{949}{wxCanvas::DrawPoint}



\hy-8{950}{void DrawPoint(float \hy-8{951}{ x}, float \hy-8{952}{ y})}

Draws a point using the current pen.


\hy-10{954}{wxCanvas::DrawRectangle}



\hy-8{955}{void DrawRectangle(float \hy-8{956}{ x}, float \hy-8{957}{ y}, float \hy-8{958}{ width}, float \hy-8{959}{ 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{961}{wxCanvas::DrawRoundedRectangle}



\hy-8{962}{void DrawRoundedRectangle(float \hy-8{963}{ x}, float \hy-8{964}{ y}, float \hy-8{965}{ width},
  float \hy-8{966}{ height}, float \hy-8{967}{ 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.

If \hy-7{968}{radius} is positive, the value is assumed to be the
radius of the rounded corner. If \hy-7{969}{radius} is negative,
the absolute value is assumed to be the \hy-7{970}{proportion} of the smallest
dimension of the rectangle. This means that the corner can be
a sensible size relative to the size of the rectangle, and also avoids
the strange effects X produces when the corners are too big for
the rectangle.


\hy-10{972}{wxCanvas::DrawSpline}



\hy-8{973}{void DrawSpline(wxList * \hy-8{974}{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{975}{void DrawSpline(float \hy-8{976}{ x1}, float \hy-8{977}{ y1}, float \hy-8{978}{ x2}, float \hy-8{979}{ y2},
  float \hy-8{980}{ x3}, float \hy-8{981}{ y3})}

Draws a three-point spline using the current pen.


\hy-10{983}{wxCanvas::DrawText}



\hy-8{984}{void DrawText(char * \hy-8{985}{text}, float \hy-8{986}{ x}, float \hy-8{987}{ y})}

Draws a text string at the specified point, using the current text font,
and the current text foreground and background colours.


\hy-10{989}{wxCanvas::EnableScrolling}



\hy-8{990}{void EnableScrolling(Bool \hy-8{991}{ xScrolling}, Bool \hy-8{992}{ 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{994}{wxCanvas::EndDrawing}



\hy-8{995}{void EndDrawing(void)}

Allows optimization of drawing code under Windows 3.1 and WIN32. Enclose
drawing primitives between \hy-8{996}{BeginDrawing} and \hy-8{997}{EndDrawing}
calls.


\hy-10{999}{wxCanvas::GetDC}



\hy-8{1000}{wxCanvasDC * GetDC(void)}

Get a pointer to the canvas's device context. See \hy-13{1001}{wxDC}
and \hy-13{1002}{wxCanvasDC}.


\hy-10{1004}{wxCanvas::GetScrollUnitsPerPage}



\hy-8{1005}{void GetScrollUnitsPerPage(int * \hy-8{1006}{x_page}, int * \hy-8{1007}{y_page})}

Get the number of units per page, in each direction, as set
by \hy-13{1008}{wxCanvas::SetScrollbars}. A value of zero indicates no
scrolling in that direction.


\hy-10{1010}{wxCanvas::GetVirtualSize}



\hy-8{1011}{void GetVirtualSize(int * \hy-8{1012}{x}, int * \hy-8{1013}{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{1014}{wxDC::DeviceToLogicalX} and \hy-13{1015}{wxDC::DeviceToLogicalY}
to translate these units to logical units.


\hy-10{1017}{wxCanvas::IntDrawLine}



\hy-8{1018}{void IntDrawLine(int \hy-8{1019}{ x1}, int \hy-8{1020}{ y1}, int \hy-8{1021}{ x2},
int \hy-8{1022}{ y2})}

Draws a line from the first point to the second. The current pen is
used for drawing the line.


\hy-10{1024}{wxCanvas::IntDrawLines}



\hy-8{1025}{void IntDrawLines(int \hy-8{1026}{ n}, wxIntPoint \hy-8{1027}{ points[]}, int \hy-8{1028}{ xoffset = 0}, int \hy-8{1029}{ yoffset = 0})}

Draw lines using an array of \hy-7{1030}{points} of size \hy-7{1031}{n}. The current pen is used
for drawing the lines.  The programmer is responsible for deleting the list of points.


\hy-10{1033}{wxCanvas::IsRetained}



\hy-8{1034}{Bool IsRetained(void)}

TRUE if the canvas has a backing bitmap.


\hy-10{1036}{wxCanvas::OnChar}



\hy-8{1037}{void OnChar(wxKeyEvent&  \hy-8{1038}{event})}

This default handler interprets cursor key movement and scrolls the
canvas accordingly.  Override the function to change this behaviour
(see \hy-13{1039}{wxWindow::OnChar} for details).


\hy-10{1041}{wxCanvas::OnEvent}



\hy-8{1042}{void OnEvent(wxMouseEvent& \hy-8{1043}{ 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{1044}{wxCanvas::OnChar}
for character events, and also \hy-13{1045}{wxMouseEvent} for how to access
event information.


\hy-10{1047}{wxCanvas::OnPaint}



\hy-8{1048}{void OnPaint(void)}

Sent to the canvas when the canvas must be refreshed. Derive your own
class to handle this message.


\hy-10{1050}{wxCanvas::Scroll}



\hy-8{1051}{void Scroll(int \hy-8{1052}{ x_pos}, int \hy-8{1053}{ 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{1054}{wxCanvas::SetScrollbars}.


\hy-10{1056}{wxCanvas::SetBackground}



\hy-8{1057}{void SetBackground(wxBrush * \hy-8{1058}{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{1059}{wxBrush}.


\hy-10{1061}{wxCanvas::SetClippingRegion}



\hy-8{1062}{void SetClippingRegion(float \hy-8{1063}{ x}, float \hy-8{1064}{ y}, float \hy-8{1065}{ width}, float \hy-8{1066}{ 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{1067}{wxCanvas::DestroyClippingRegion}.


\hy-10{1069}{wxCanvas::SetBrush}



\hy-8{1070}{void SetBrush(wxBrush * \hy-8{1071}{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{1072}{wxBrush}.


\hy-10{1074}{wxCanvas::SetFont}



\hy-8{1075}{void SetFont(wxFont * \hy-8{1076}{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{1077}{wxFont}, \hy-13{1078}{wxCanvas::DrawText}.


\hy-10{1080}{wxCanvas::SetLogicalFunction}



\hy-8{1081}{void SetLogicalFunction(int \hy-8{1082}{ 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{1083}{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{1084}{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{1086}{wxCanvas::SetPen}



\hy-8{1087}{void SetPen(wxPen * \hy-8{1088}{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{1089}{wxPen}.


\hy-10{1091}{wxCanvas::SetScrollbars}



\hy-8{1092}{void SetScrollbars(int \hy-8{1093}{ horiz_pixels}, int \hy-8{1094}{ vert_pixels}, int \hy-8{1095}{ x_length}, int \hy-8{1096}{ y_length},

  int  \hy-8{1097}{x_page}, int \hy-8{1098}{ y_page}, int  \hy-8{1099}{x_pos = 0}, int \hy-8{1100}{ 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{1101}{x_pos} and \hy-7{1102}{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{1103}{canvas->SetScrollbars(20, 20, 50, 50, 4, 4);
}
See also \hy-13{1104}{wxCanvas::EnableScrolling},
\hy-13{1105}{wxCanvas::GetScrollUnitsPerPage}, \hy-13{1106}{wxCanvas::GetVirtualSize}.


\hy-10{1108}{wxCanvas::SetTextBackground}



\hy-8{1109}{void SetTextBackground(wxColour * \hy-8{1110}{colour})}

Sets the current text background colour for the canvas.  Do not
delete \hy-7{1111}{colour}. See also \hy-13{1112}{wxCanvas::SetTextForeground}.


\hy-10{1114}{wxCanvas::SetTextForeground}



\hy-8{1115}{void SetTextForeground(wxColour * \hy-8{1116}{colour})}

Sets the current text foreground colour for the canvas. Do not
delete \hy-7{1117}{colour}.  See also \hy-13{1118}{wxCanvas::SetTextBackground}.


\hy-10{1120}{wxCanvas::ViewStart}



\hy-8{1121}{void ViewStart(int * \hy-8{1122}{x}, int * \hy-8{1123}{ 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{1124}{x} and/or
\hy-7{1125}{y} will be greater than zero.  Combined with \hy-13{1126}{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{1127}{wxCanvas::SetScrollbars}.


\hy-10{1129}{wxCanvas::WarpPointer}



\hy-8{1130}{void WarpPointer(int \hy-8{1131}{ x}, int \hy-8{1132}{ y})}

Moves the pointer to the given position on the canvas.


\hy-10{1138}{wxCanvasDC::wxCanvasDC}



\hy-8{1139}{void wxCanvasDC(wxCanvas * \hy-8{1140}{canvas})}

Constructor for internal use only.


\hy-10{1144}{wxCheckBox::wxCheckBox}



\hy-8{1145}{void wxCheckBox(void)}

Constructor, used when deriving from this class.

\hy-8{1146}{void wxCheckBox(wxPanel * \hy-8{1147}{parent}, wxFunction \hy-8{1148}{ func},
  char * \hy-8{1149}{label}, 
int \hy-8{1150}{ x = -1}, int \hy-8{1151}{ y = -1},
  int \hy-8{1152}{ width = -1}, int \hy-8{1153}{ height = -1},

  long \hy-8{1154}{ style = 0}, char * \hy-8{1155}{name = ``checkBox"})}

\hy-8{1156}{void wxCheckBox(wxPanel * \hy-8{1157}{parent}, wxFunction \hy-8{1158}{ func},
  wxBitmap * \hy-8{1159}{bitmap}, 
int \hy-8{1160}{ x = -1}, int \hy-8{1161}{ y = -1},
  int \hy-8{1162}{ width = -1}, int \hy-8{1163}{ height = -1},

  long \hy-8{1164}{ style = 0}, char * \hy-8{1165}{name = ``checkBox"})}

Constructor, creating and showing a checkbox.

\hy-7{1166}{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{1167}{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{1168}{x} and \hy-7{1169}{y} are used to specify an absolute
position, or a position after the previous panel item if omitted or
default.

If \hy-7{1170}{width} or \hy-7{1171}{height} are omitted (or are less than zero), an
appropriate size will be used for the check box.

The \hy-7{1172}{style} parameter is reserved for future use.

The \hy-7{1173}{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{1175}{wxCheckBox::~wxCheckBox}



\hy-8{1176}{void ~wxCheckBox(void)}

Destructor, destroying the checkbox.


\hy-10{1178}{wxCheckBox::Create}



\hy-8{1179}{Bool Create(wxPanel * \hy-8{1180}{parent}, wxFunction \hy-8{1181}{ func},
  char * \hy-8{1182}{label}, 
int \hy-8{1183}{ x = -1}, int \hy-8{1184}{ y = -1},
  int \hy-8{1185}{ width = -1}, int \hy-8{1186}{ height = -1},

  long \hy-8{1187}{ style = 0}, char * \hy-8{1188}{name = ``checkBox"})}

\hy-8{1189}{Bool Create(wxPanel * \hy-8{1190}{parent}, wxFunction \hy-8{1191}{ func},
  char * \hy-8{1192}{bitmap}, 
int \hy-8{1193}{ x = -1}, int \hy-8{1194}{ y = -1},
  int \hy-8{1195}{ width = -1}, int \hy-8{1196}{ height = -1},

  long \hy-8{1197}{ style = 0}, char * \hy-8{1198}{name = ``checkBox"})}

Creates the checkbox for two-step construction. Derived classes
should call or replace this function. See \hy-13{1199}{wxCheckBox::wxCheckBox}
for details.


\hy-10{1201}{wxCheckBox::GetValue}



\hy-8{1202}{Bool GetValue(void)}

Gets the state of the checkbox, TRUE if it is checked, FALSE otherwise.


\hy-10{1204}{wxCheckBox::SetLabel}



\hy-8{1205}{void SetLabel(wxBitmap * \hy-8{1206}{label})}

Sets the bitmap for a bitmap checkbox.


\hy-10{1208}{wxCheckBox::SetValue}



\hy-8{1209}{void SetValue(Bool \hy-8{1210}{ state})}

Sets the checkbox to the given state: if the state is TRUE, the check is on,
otherwise it is off.



\hy-10{1215}{wxChoice::wxChoice}



\hy-8{1216}{void wxChoice(void)}

Constructor, for use by derived classes.

\hy-8{1217}{void wxChoice(wxPanel * \hy-8{1218}{parent}, wxFunction \hy-8{1219}{ func},
  char * \hy-8{1220}{label}, 
int \hy-8{1221}{ x = -1}, int \hy-8{1222}{ y = -1}, int \hy-8{1223}{ width = -1},
  int \hy-8{1224}{ height = -1}, 
int \hy-8{1225}{ n}, char * \hy-8{1226}{choices[]},

  long \hy-8{1227}{ style = 0}, char * \hy-8{1228}{name = ``choice"})}

Constructor, creating and showing a choice. 

\hy-7{1229}{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{1230}{label} is non-NULL, it is used as the label for the choice item.

The parameters \hy-7{1231}{x} and \hy-7{1232}{y} are used to specify an absolute
position, or a position after the previous panel item if omitted or
default.

If \hy-7{1233}{width} or \hy-7{1234}{height} are omitted (or are less than zero), an
appropriate size will be used for the choice.

\hy-7{1235}{n} is the number of possible choices, and \hy-7{1236}{choices} is an
array of strings of size \hy-7{1237}{n}. wxWindows allocates its own memory
for these strings so the calling program must deallocate the array
itself.

The \hy-7{1238}{style} parameter is reserved for future use.

The \hy-7{1239}{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{1241}{wxChoice::~wxChoice}



\hy-8{1242}{void ~wxChoice(void)}

Destructor, destroying the choice item.


\hy-10{1244}{wxChoice::Append}



\hy-8{1245}{void Append(char * \hy-8{1246}{ item})}

Adds the item to the end of the choice item. \hy-7{1247}{item} must be
deallocated by the calling program, i.e. wxWindows makes its own copy.


\hy-10{1249}{wxChoice::Clear}



\hy-8{1250}{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{1252}{wxChoice::Create}



\hy-8{1253}{Bool Create(wxPanel * \hy-8{1254}{parent}, wxFunction \hy-8{1255}{ func},
  char * \hy-8{1256}{label}, 
int \hy-8{1257}{ x = -1}, int \hy-8{1258}{ y = -1}, int \hy-8{1259}{ width = -1},
  int \hy-8{1260}{ height = -1}, int \hy-8{1261}{ n}, char * \hy-8{1262}{choices[]}

  long \hy-8{1263}{ style = 0}, char * \hy-8{1264}{name = ``choice"})}

Creates the choice for two-step construction. Derived classes
should call or replace this function. See \hy-13{1265}{wxChoice::wxChoice}
for further details.


\hy-10{1267}{wxChoice::FindString}



\hy-8{1268}{int FindString(char * \hy-8{1269}{s})}

Finds a choice matching the given string, returning the position if found, or
-1 if not found.


\hy-10{1271}{wxChoice::GetSelection}



\hy-8{1272}{int GetSelection(void)}

Gets the id (position) of the selected string.


\hy-10{1274}{wxChoice::GetStringSelection}



\hy-8{1275}{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{1277}{wxChoice::SetSelection}



\hy-8{1278}{void SetSelection(int \hy-8{1279}{ n})}

Sets the choice by passing the desired string position. 


\hy-10{1281}{wxChoice::SetStringSelection}



\hy-8{1282}{void SetStringSelection(char * \hy-8{1283}{ s})}

Sets the choice by passing the desired string.


\hy-10{1285}{wxChoice::GetString}



\hy-8{1286}{char * GetString(int \hy-8{1287}{ n})}

Returns a temporary pointer to the string at position \hy-7{1288}{n}.


\hy-10{1305}{wxClient::wxClient}



\hy-8{1306}{void wxClient(void)}

Constructs a client object.


\hy-10{1308}{wxClient::MakeConnection}



\hy-8{1309}{wxConnection * MakeConnection(char * \hy-8{1310}{host}, char * \hy-8{1311}{service}, char * \hy-8{1312}{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{1313}{wxClient::OnMakeConnection} member to return your own
derived connection object.


\hy-10{1315}{wxClient::OnMakeConnection}



\hy-8{1316}{wxConnection * OnMakeConnection(void)}

The type of \hy-13{1317}{wxConnection} returned from a \hy-13{1318}{wxClient::MakeConnection} call can
be altered by deriving the \hy-8{1319}{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{1320}{wxConnection::OnAdvise}. You may also want to
store application-specific data in instances of the new class.


\hy-10{1325}{wxColour::wxColour}



\hy-8{1326}{void wxColour(char \hy-8{1327}{ red}, char \hy-8{1328}{ green}, char \hy-8{1329}{ blue})}

\hy-8{1330}{void wxColour(char * \hy-8{1331}{ colour_name})}

Construct a colour object from the RGB values or using a colour name
(uses \hy-8{1332}{wxTheColourDatabase}).


\hy-10{1334}{wxColour::=}



\hy-8{1335}{wxColour& =(wxColour& \hy-8{1336}{ src})}

Assignment from source to destination colour.


\hy-10{1338}{wxColour::Get}



\hy-8{1339}{void Get(char * \hy-8{1340}{ red}, char * \hy-8{1341}{ green}, char * \hy-8{1342}{ blue})}

Gets the RGB values---pass pointers to three char variables.


\hy-10{1344}{wxColour::Ok}



\hy-8{1345}{Bool Ok(void)}

Returns TRUE if the colour object is valid.


\hy-10{1347}{wxColour::Set}



\hy-8{1348}{void Set(char \hy-8{1349}{ red}, char \hy-8{1350}{ green}, char \hy-8{1351}{ blue})}

Sets the RGB value.


\hy-10{1358}{wxColourDatabase::wxColourDatabase}



\hy-8{1359}{void wxColourDatabase(void)}

Constructs the colour database.  Should not need to be used by an 
application.


\hy-10{1361}{wxColourDatabase::FindColour}



\hy-8{1362}{wxColour * FindColour(char * \hy-8{1363}{colour_name})}

Finds a colour given the name.  Returns NULL if not found.


\hy-10{1365}{wxColourDatabase::FindName}



\hy-8{1366}{char * FindName(wxColour& \hy-8{1367}{ colour})}

Finds a colour name given the colour. Returns NULL if not found.


\hy-10{1369}{wxColourDatabase::Initialize}



\hy-8{1370}{char * Initialize(void)}

Initializes the database with a number of stock colours.  Called by wxWindows
on start-up.


\hy-10{1375}{wxColourMap::wxColourMap}



\hy-8{1376}{void wxColourMap(void)}

Constructor.


\hy-10{1378}{wxColourMap::~wxColourMap}



\hy-8{1379}{void ~wxColourMap(void)}

Destructor.

If you have to delete the colourmap (for example, you are creating a lot of
them), then call \hy-13{1380}{wxDC::SetColourMap} with a NULL argument
to ensure that the old colourmap is restored, and the current colourmap is selected
out of the device context.


\hy-10{1382}{wxColourMap::Create}



\hy-8{1383}{Bool Create(const int \hy-8{1384}{ n}, const char * \hy-8{1385}{red},

 const char * \hy-8{1386}{green}, const char * \hy-8{1387}{blue})}

Creates a colourmap from arrays of size \hy-7{1388}{n}, one for each
red, blue or green component. Implemented only under Windows.


\hy-10{1394}{wxCommandEvent::clientData}



\hy-8{1395}{char * clientData}

Contains a pointer to client data for listboxes and choices, if the event
was a selection.


\hy-10{1397}{wxCommandEvent::commandInt}



\hy-8{1398}{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{1400}{wxCommandEvent::commandString}



\hy-8{1401}{char * commandString}

Contains a string corresponding to a listbox or choice selection.


\hy-10{1403}{wxCommandEvent::extraLong}



\hy-8{1404}{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{1406}{wxCommandEvent::wxCommandEvent}



\hy-8{1407}{void wxCommandEvent(WXTYPE \hy-8{1408}{ commandEventType})}

Constructor. \hy-7{1409}{commandEventType} may be one of the following:


\hy-8{1410}{o}  \hy-8{1411}{wxEVENT_TYPE_BUTTON_COMMAND}
\hy-8{1412}{o}  \hy-8{1413}{wxEVENT_TYPE_CHECKBOX_COMMAND}
\hy-8{1414}{o}  \hy-8{1415}{wxEVENT_TYPE_CHOICE_COMMAND}
\hy-8{1416}{o}  \hy-8{1417}{wxEVENT_TYPE_LISTBOX_COMMAND}
\hy-8{1418}{o}  \hy-8{1419}{wxEVENT_TYPE_TEXT_COMMAND}
\hy-8{1420}{o}  \hy-8{1421}{wxEVENT_TYPE_TEXT_ENTER_COMMAND}
\hy-8{1422}{o}  \hy-8{1423}{wxEVENT_TYPE_MULTITEXT_COMMAND}
\hy-8{1424}{o}  \hy-8{1425}{wxEVENT_TYPE_MENU_COMMAND}
\hy-8{1426}{o}  \hy-8{1427}{wxEVENT_TYPE_SLIDER_COMMAND}
\hy-8{1428}{o}  \hy-8{1429}{wxEVENT_TYPE_RADIOBOX_COMMAND}
\hy-8{1430}{o}  \hy-8{1431}{wxEVENT_TYPE_SET_FOCUS}
\hy-8{1432}{o}  \hy-8{1433}{wxEVENT_TYPE_KILL_FOCUS}



\hy-10{1435}{wxCommandEvent::Checked}



\hy-8{1436}{Bool Checked(void)}

Returns TRUE or FALSE for a checkbox selection event.


\hy-10{1438}{wxCommandEvent::GetClientData}



\hy-8{1439}{char * GetClientData(void)}

Returns client data pointer for a listbox or choice selection event
(not valid for a deselection).


\hy-10{1441}{wxCommandEvent::GetSelection}



\hy-8{1442}{int GetSelection(void)}

Returns item index for a listbox or choice selection event (not valid for
a deselection).


\hy-10{1444}{wxCommandEvent::GetString}



\hy-8{1445}{char * GetString(void)}

Returns item string for a listbox or choice selection event (not valid for
a deselection).


\hy-10{1447}{wxCommandEvent::IsSelection}



\hy-8{1448}{Bool IsSelection(void)}

For a listbox or choice event, returns TRUE if it is a selection, FALSE if it
is a deselection.


\hy-10{1457}{wxConnection::wxConnection}



\hy-8{1458}{void wxConnection(void)}

\hy-8{1459}{void wxConnection(char * \hy-8{1460}{buffer}, int \hy-8{1461}{ 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{1462}{wxServer::OnAcceptConnection}
and/or \hy-13{1463}{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{1465}{wxConnection::Advise}



\hy-8{1466}{Bool Advise(char * \hy-8{1467}{item}, char * \hy-8{1468}{data}, int \hy-8{1469}{ size = -1}, int \hy-8{1470}{ 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{1471}{wxConnection::OnAdvise}
member to be called. Returns TRUE if successful.


\hy-10{1473}{wxConnection::Execute}



\hy-8{1474}{Bool Execute(char * \hy-8{1475}{data}, int \hy-8{1476}{ size = -1},
int \hy-8{1477}{ 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{1478}{wxConnection::Poke} in that respect). Causes the
server connection's \hy-13{1479}{wxConnection::OnExecute} member to be
called. Returns TRUE if successful.


\hy-10{1481}{wxConnection::Disconnect}



\hy-8{1482}{Bool Disconnect(void)}

Called by the client or server application to disconnect from the other
program; it causes the \hy-13{1483}{wxConnection::OnDisconnect} message
to be sent to the corresponding connection object in the other
program. The default behaviour of \hy-8{1484}{OnDisconnect} is to delete the
connection, but the calling application must explicitly delete its
side of the connection having called \hy-8{1485}{Disconnect}. Returns TRUE if
successful.


\hy-10{1487}{wxConnection::OnAdvise}



\hy-8{1488}{Bool OnAdvise(char * \hy-8{1489}{topic}, char * \hy-8{1490}{item}, char * \hy-8{1491}{data}, int \hy-8{1492}{ size}, int \hy-8{1493}{ 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{1495}{wxConnection::OnDisconnect}



\hy-8{1496}{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{1498}{wxConnection::OnExecute}



\hy-8{1499}{Bool OnExecute(char * \hy-8{1500}{topic}, char * \hy-8{1501}{data}, int \hy-8{1502}{ size}, int \hy-8{1503}{ 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{1505}{wxConnection::OnPoke}



\hy-8{1506}{Bool OnPoke(char * \hy-8{1507}{topic}, char * \hy-8{1508}{item}, char * \hy-8{1509}{data}, int \hy-8{1510}{ size}, int \hy-8{1511}{ format})}

Message sent to the server application when the client notifies it to
accept the given data.


\hy-10{1513}{wxConnection::OnRequest}



\hy-8{1514}{char * OnRequest(char * \hy-8{1515}{topic}, char * \hy-8{1516}{item}, int * \hy-8{1517}{size}, int \hy-8{1518}{ format})}

Message sent to the server application when the client
calls \hy-13{1519}{wxConnection::Request}. The server
should respond by returning a character string from \hy-8{1520}{OnRequest},
or NULL to indicate no data.


\hy-10{1522}{wxConnection::OnStartAdvise}



\hy-8{1523}{Bool OnStartAdvise(char * \hy-8{1524}{topic}, char * \hy-8{1525}{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{1527}{wxConnection::OnStopAdvise}



\hy-8{1528}{Bool OnStopAdvise(char * \hy-8{1529}{topic}, char * \hy-8{1530}{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{1532}{wxConnection::Poke}



\hy-8{1533}{Bool Poke(char * \hy-8{1534}{item}, char * \hy-8{1535}{data}, int \hy-8{1536}{ size = -1}, int \hy-8{1537}{ 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{1538}{wxConnection::OnPoke} member
to be called. Returns TRUE if successful.


\hy-10{1540}{wxConnection::Request}



\hy-8{1541}{char * Request(char * \hy-8{1542}{item}, int * \hy-8{1543}{size}, int \hy-8{1544}{ format = wxCF_TEXT})}

Called by the client application to request data from the server. Causes
the server connection's \hy-13{1545}{wxConnection::OnRequest} member to be called. Returns a
character string (actually a pointer to the connection's buffer) if
successful, NULL otherwise.


\hy-10{1547}{wxConnection::StartAdvise}



\hy-8{1548}{Bool StartAdvise(char * \hy-8{1549}{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{1550}{wxConnection::OnStartAdvise}
member to be called. Returns TRUE if the server okays it, FALSE
otherwise.


\hy-10{1552}{wxConnection::StopAdvise}



\hy-8{1553}{Bool StopAdvise(char * \hy-8{1554}{item})}

Called by the client application to ask if an advise loop can be
stopped. Causes the server connection's \hy-13{1555}{wxConnection::OnStopAdvise} member
to be called. Returns TRUE if the server okays it, FALSE otherwise.


\hy-10{1563}{wxCursor::wxCursor}



\hy-8{1564}{void wxCursor(void)}

\hy-8{1565}{void wxCursor(short \hy-8{1566}{ bits[]}, int \hy-8{1567}{width},
int \hy-8{1568}{ height})}

\hy-8{1569}{void wxCursor(char * \hy-8{1570}{ cursor_name})}

\hy-8{1571}{void wxCursor(int \hy-8{1572}{ 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{1573}{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{1574}{o}  wxCURSOR_ARROW
\hy-8{1575}{o}  wxCURSOR_BULLSEYE
\hy-8{1576}{o}  wxCURSOR_CHAR
\hy-8{1577}{o}  wxCURSOR_CROSS
\hy-8{1578}{o}  wxCURSOR_HAND
\hy-8{1579}{o}  wxCURSOR_IBEAM
\hy-8{1580}{o}  wxCURSOR_LEFT_BUTTON
\hy-8{1581}{o}  wxCURSOR_MAGNIFIER
\hy-8{1582}{o}  wxCURSOR_MIDDLE_BUTTON
\hy-8{1583}{o}  wxCURSOR_NO_ENTRY
\hy-8{1584}{o}  wxCURSOR_PAINT_BRUSH
\hy-8{1585}{o}  wxCURSOR_PENCIL
\hy-8{1586}{o}  wxCURSOR_POINT_LEFT
\hy-8{1587}{o}  wxCURSOR_POINT_RIGHT
\hy-8{1588}{o}  wxCURSOR_QUESTION_ARROW
\hy-8{1589}{o}  wxCURSOR_RIGHT_BUTTON
\hy-8{1590}{o}  wxCURSOR_SIZENESW
\hy-8{1591}{o}  wxCURSOR_SIZENS
\hy-8{1592}{o}  wxCURSOR_SIZENWSE
\hy-8{1593}{o}  wxCURSOR_SIZEWE
\hy-8{1594}{o}  wxCURSOR_SIZING
\hy-8{1595}{o}  wxCURSOR_SPRAYCAN
\hy-8{1596}{o}  wxCURSOR_WAIT
\hy-8{1597}{o}  wxCURSOR_WATCH



\hy-10{1599}{wxCursor::~wxCursor}



\hy-8{1600}{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{1616}{wxDC::wxDC}



\hy-8{1617}{void wxDC(void)}

Constructor.


\hy-10{1619}{wxDC::~wxDC}



\hy-8{1620}{void ~wxDC(void)}

Destructor.


\hy-10{1622}{wxDC::BeginDrawing}



\hy-8{1623}{void BeginDrawing(void)}

Allows optimization of drawing code under Windows 3.1 and WIN32. Enclose
drawing primitives between \hy-8{1624}{BeginDrawing} and \hy-8{1625}{EndDrawing}
calls.


\hy-10{1627}{wxDC::Blit}



\hy-8{1628}{Bool Blit(float \hy-8{1629}{ xdest}, float \hy-8{1630}{ ydest}, float \hy-8{1631}{ width}, float \hy-8{1632}{ height},

  wxDC * \hy-8{1633}{source}, float \hy-8{1634}{ xsrc}, float \hy-8{1635}{ ysrc}, int \hy-8{1636}{ 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{1637}{wxDC::SetLogicalFunction}).
See \hy-13{1638}{wxMemoryDC} for typical usage.


\hy-10{1640}{wxDC::Clear}



\hy-8{1641}{void Clear(void)}



\hy-10{1643}{wxDC::DestroyClippingRegion}



\hy-8{1644}{void DestroyClippingRegion(void)}

Destroys the current clipping region so that none of the DC is clipped.
See also \hy-13{1645}{wxDC::SetClippingRegion}.


\hy-10{1647}{wxDC::DeviceToLogicalX}



\hy-8{1648}{float DeviceToLogicalX(int \hy-8{1649}{ x})}

Convert device X coordinate to logical coordinate, using the current
mapping mode.


\hy-10{1651}{wxDC::DeviceToLogicalY}



\hy-8{1652}{float DeviceToLogicalY(int \hy-8{1653}{ y})}

Converts device Y coordinate to logical coordinate, using the current
mapping mode.


\hy-10{1655}{wxDC::DrawArc}



\hy-8{1656}{void DrawArc(float \hy-8{1657}{ x1}, float \hy-8{1658}{ y1}, float \hy-8{1659}{ x2}, float \hy-8{1660}{ y2}, float \hy-8{1661}{xc}, float \hy-8{1662}{yc})}

Draws an arc, centred on (\hy-7{1663}{xc, yc}), with starting point (\hy-7{1664}{x1, y1})
and ending at (\hy-7{1665}{x2, y2}).   The current pen is used for the outline
and the current brush for filling the shape.


\hy-10{1667}{wxDC::DrawEllipse}



\hy-8{1668}{void DrawEllipse(float \hy-8{1669}{ x}, float \hy-8{1670}{ y}, float \hy-8{1671}{ width}, float \hy-8{1672}{ 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{1674}{wxDC::DrawIcon}



\hy-8{1675}{void DrawIcon(wxIcon * \hy-8{1676}{icon}, float \hy-8{1677}{ x}, float \hy-8{1678}{ 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{1680}{wxDC::DrawLine}



\hy-8{1681}{void DrawLine(float \hy-8{1682}{ x1}, float \hy-8{1683}{ y1}, float \hy-8{1684}{ x2}, float \hy-8{1685}{ y2})}

Draws a line from the first point to the second. The current pen is used
for drawing the line.


\hy-10{1687}{wxDC::DrawLines}



\hy-8{1688}{void DrawLines(int \hy-8{1689}{ n}, wxPoint \hy-8{1690}{ points[]}, float \hy-8{1691}{ xoffset = 0}, float \hy-8{1692}{ yoffset = 0})}

\hy-8{1693}{void DrawLines(wxList * \hy-8{1694}{points}, float \hy-8{1695}{ xoffset = 0}, float \hy-8{1696}{ yoffset = 0})}

Draws lines using an array of \hy-7{1697}{points} of size \hy-7{1698}{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{1700}{wxDC::DrawPolygon}



\hy-8{1701}{void DrawPolygon(int \hy-8{1702}{ n}, wxPoint \hy-8{1703}{ points[]}, float \hy-8{1704}{ xoffset = 0}, float \hy-8{1705}{ yoffset = 0},

  int  \hy-8{1706}{fill_style = wxODDEVEN_RULE})}

\hy-8{1707}{void DrawPolygon(wxList * \hy-8{1708}{points}, float \hy-8{1709}{ xoffset = 0}, float \hy-8{1710}{ yoffset = 0},

  int  \hy-8{1711}{fill_style = wxODDEVEN_RULE})}

Draws a filled polygon using an array of \hy-7{1712}{points} of size \hy-7{1713}{n},
or list of pointers to points, adding the optional offset coordinate.

The last argument specifies the fill rule: \hy-8{1714}{wxODDEVEN_RULE} (the
default) or \hy-8{1715}{wxWINDING_RULE}.

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{1717}{wxDC::DrawPoint}



\hy-8{1718}{void DrawPoint(float \hy-8{1719}{ x}, float \hy-8{1720}{ y})}

Draws a point using the current pen.


\hy-10{1722}{wxDC::DrawRectangle}



\hy-8{1723}{void DrawRectangle(float \hy-8{1724}{ x}, float \hy-8{1725}{ y}, float \hy-8{1726}{ width}, float \hy-8{1727}{ 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{1729}{wxDC::DrawRoundedRectangle}



\hy-8{1730}{void DrawRoundedRectangle(float \hy-8{1731}{ x}, float \hy-8{1732}{ y}, float \hy-8{1733}{ width}, float \hy-8{1734}{ height}, float \hy-8{1735}{ 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.

If \hy-7{1736}{radius} is positive, the value is assumed to be the
radius of the rounded corner. If \hy-7{1737}{radius} is negative,
the absolute value is assumed to be the \hy-7{1738}{proportion} of the smallest
dimension of the rectangle. This means that the corner can be
a sensible size relative to the size of the rectangle, and also avoids
the strange effects X produces when the corners are too big for
the rectangle.


\hy-10{1740}{wxDC::DrawSpline}



\hy-8{1741}{void DrawSpline(wxList * \hy-8{1742}{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{1743}{void DrawSpline(float \hy-8{1744}{ x1}, float \hy-8{1745}{ y1}, float \hy-8{1746}{ x2}, float \hy-8{1747}{ y2}, float \hy-8{1748}{ x3}, float \hy-8{1749}{ y3})}

Draws a three-point spline using the current pen.


\hy-10{1751}{wxDC::DrawText}



\hy-8{1752}{void DrawText(char * \hy-8{1753}{text}, float \hy-8{1754}{ x}, float \hy-8{1755}{ 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{1756}{wxDC::GetTextExtent} for how
to get the dimensions of a text string, which can be used to position the
text more precisely.


\hy-10{1758}{wxDC::EndDoc}



\hy-8{1759}{void EndDoc(void)}

Ends a document (only relevant when outputting to a printer).


\hy-10{1761}{wxDC::EndDrawing}



\hy-8{1762}{void EndDrawing(void)}

Allows optimization of drawing code under Windows 3.1 and WIN32. Enclose
drawing primitives between \hy-8{1763}{BeginDrawing} and \hy-8{1764}{EndDrawing}
calls.


\hy-10{1766}{wxDC::EndPage}



\hy-8{1767}{void EndPage(void)}

Ends a document page (only relevant when outputting to a printer).


\hy-10{1769}{wxDC::GetBackground}



\hy-8{1770}{wxBrush * GetBackground(void)}

Gets the brush used for painting the background (see \hy-13{1771}{wxDC::SetBackground}).


\hy-10{1773}{wxDC::GetBrush}



\hy-8{1774}{wxBrush * GetBrush(void)}

Gets the current brush (see \hy-13{1775}{wxDC::SetBrush}).


\hy-10{1777}{wxDC::GetFont}



\hy-8{1778}{wxFont * GetFont(void)}

Gets the current font (see \hy-13{1779}{wxDC::SetFont}).


\hy-10{1781}{wxDC::GetLogicalFunction}



\hy-8{1782}{int GetLogicalFunction(void)}

Gets the current logical function (see \hy-13{1783}{wxDC::SetLogicalFunction}).


\hy-10{1785}{wxDC::GetMapMode}



\hy-8{1786}{int GetMapMode(void)}

Gets the \hy-7{1787}{mapping mode} for the device context (see \hy-13{1788}{wxDC::SetMapMode}).


\hy-10{1790}{wxDC::GetSize}



\hy-8{1791}{void GetSize(int * \hy-8{1792}{width}, int * \hy-8{1793}{height})}

For a PostScript device context, this gets the maximum size of graphics
drawn so far on the device context.

For a Windows printer device context, this gets the horizontal and vertical
resolution. It can be used to scale graphics to fit the page when using
a Windows printer device context. For example, if \hy-7{1794}{maxX} and \hy-7{1795}{maxY}
represent the maximum horizontal and vertical `pixel' values used in your
application, the following code will scale the graphic to fit on the
printer page:

\hy-14{1796}{  float w, h;
  dc.GetSize(&w, &h);
  float scaleX=(float)(maxX/w);
  float scaleY=(float)(maxY/h);
  dc.SetUserScale(min(scaleX,scaleY),min(scaleX,scaleY)).
}

\hy-10{1798}{wxDC::GetPen}



\hy-8{1799}{wxPen * GetPen(void)}

Gets the current pen (see \hy-13{1800}{wxDC::SetPen}).


\hy-10{1802}{wxDC::GetTextBackground}



\hy-8{1803}{wxColour& GetTextBackground(void)}

Gets the current text background colour (see \hy-13{1804}{wxDC::SetTextBackground}).


\hy-10{1806}{wxDC::GetTextExtent}



\hy-8{1807}{void GetTextExtent(char * \hy-8{1808}{string}, float * \hy-8{1809}{w}, float * \hy-8{1810}{h},

  float * \hy-8{1811}{descent = NULL}, float * \hy-8{1812}{externalLeading = NULL})}

Gets the dimensions of the string using the currently selected font.
\hy-7{1813}{string} is the text string to measure, \hy-7{1814}{w} and \hy-7{1815}{h} are
the total width and height respectively, \hy-7{1816}{descent} is the
dimension from the baseline of the font to the bottom of the
descender, and \hy-7{1817}{externalLeading} is any extra vertical space added
to the font by the font designer (usually is zero).

See also \hy-13{1818}{wxFont}, \hy-13{1819}{wxDC::SetFont}.


\hy-10{1821}{wxDC::GetTextForeground}



\hy-8{1822}{wxColour& GetTextForeground(void)}

Gets the current text foreground colour (see \hy-13{1823}{wxDC::SetTextForeground}).


\hy-10{1825}{wxDC::IntDrawLine}



\hy-8{1826}{void IntDrawLine(int \hy-8{1827}{ x1}, int \hy-8{1828}{ y1}, int \hy-8{1829}{ x2},
int \hy-8{1830}{ y2})}

Draws a line from the first point to the second. The current pen is
used for drawing the line.


\hy-10{1832}{wxDC::IntDrawLines}



\hy-8{1833}{void IntDrawLines(int \hy-8{1834}{ n}, wxIntPoint \hy-8{1835}{ points[]}, int \hy-8{1836}{ xoffset = 0}, int \hy-8{1837}{ yoffset = 0})}

Draw lines using an array of \hy-7{1838}{points} of size \hy-7{1839}{n}. The current pen is used
for drawing the lines.  The programmer is responsible for deleting the list of points.


\hy-10{1841}{wxDC::LogicalToDeviceX}



\hy-8{1842}{int LogicalToDeviceX(float \hy-8{1843}{ x})}

Converts logical X coordinate to device coordinate, using the current
mapping mode.


\hy-10{1845}{wxDC::LogicalToDeviceY}



\hy-8{1846}{int LogicalToDeviceY(float \hy-8{1847}{ y})}

Converts logical Y coordinate to device coordinate, using the current
mapping mode.


\hy-10{1849}{wxDC::MaxX}



\hy-8{1850}{float MaxX(void)}

Gets the maximum horizontal extent used in drawing commands so far.


\hy-10{1852}{wxDC::MaxY}



\hy-8{1853}{float MaxY(void)}

Gets the maximum vertical extent used in drawing commands so far.


\hy-10{1855}{wxDC::MinX}



\hy-8{1856}{float MinX(void)}

Gets the minimum horizontal extent used in drawing commands so far.


\hy-10{1858}{wxDC::MinY}



\hy-8{1859}{float MinY(void)}

Gets the minimum vertical extent used in drawing commands so far.


\hy-10{1861}{wxDC::Ok}



\hy-8{1862}{Bool Ok(void)}

Returns TRUE if the DC is ok to use.


\hy-10{1864}{wxDC::SetBackground}



\hy-8{1865}{void SetBackground(wxBrush * \hy-8{1866}{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{1868}{wxDC::SetBackgroundMode}



\hy-8{1869}{void SetBackgroundMode(int \hy-8{1870}{ mode})}

\hy-7{1871}{mode} may be one of wxSOLID and wxTRANSARENT. This setting determines
whether text will be drawn with a background colour or not.


\hy-10{1873}{wxDC::SetClippingRegion}



\hy-8{1874}{void SetClippingRegion(float \hy-8{1875}{ x}, float \hy-8{1876}{ y}, float \hy-8{1877}{ width}, float \hy-8{1878}{ 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{1879}{wxDC::DestroyClippingRegion}.


\hy-10{1881}{wxDC::SetColourMap}



\hy-8{1882}{void SetColourMap(wxColourMap * \hy-8{1883}{colourMap})}

If this is a canvas DC or memory DC, assigns the given colourmap to the window
or bitmap associated with the DC. If the argument is NULL, the current
colourmap is selected out of the device context, and the original colourmap
restored, allowing the current colourmap to be destroyed safely.

See \hy-13{1884}{wxColourMap} for further details.


\hy-10{1886}{wxDC::SetBrush}



\hy-8{1887}{void SetBrush(wxBrush * \hy-8{1888}{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.

If the argument is NULL, the current brush is selected out of the device
context, and the original brush restored, allowing the current brush to
be destroyed safely.

See also \hy-13{1889}{wxBrush}.


\hy-10{1891}{wxDC::SetFont}



\hy-8{1892}{void SetFont(wxFont * \hy-8{1893}{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.

If the argument is NULL, the current font is selected out of the device
context, and the original font restored, allowing the current font to
be destroyed safely.

See also \hy-13{1894}{wxFont}.


\hy-10{1896}{wxDC::SetLogicalFunction}



\hy-8{1897}{void SetLogicalFunction(int \hy-8{1898}{ 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{1899}{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{1900}{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{1902}{wxDC::SetMapMode}



\hy-8{1903}{void SetMapMode(int \hy-8{1904}{ int})}

The \hy-7{1905}{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{1906}{
user scale} (see \hy-13{1907}{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:


MM_TWIPS
    Each logical unit is 1/20 of a point, or 1/1440 of
  an inch.

MM_POINTS
    Each logical unit is a point, or 1/72 of an inch.

MM_METRIC
    Each logical unit is 1 mm.

MM_LOMETRIC
    Each logical unit is 1/10 of a mm.

MM_TEXT
    Each logical unit is 1 pixel.




\hy-10{1909}{wxDC::SetPen}



\hy-8{1910}{void SetPen(wxPen * \hy-8{1911}{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.

If the argument is NULL, the current pen is selected out of the device
context, and the original pen restored, allowing the current pen to
be destroyed safely.


\hy-10{1913}{wxDC::SetTextBackground}



\hy-8{1914}{void SetTextBackground(wxColour * \hy-8{1915}{colour})}

Sets the current text background colour for the DC.  Do not delete \hy-7{1916}{
colour} while selected for use by a DC.


\hy-10{1918}{wxDC::SetTextForeground}



\hy-8{1919}{void SetTextForeground(wxColour * \hy-8{1920}{colour})}

Sets the current text foreground colour for the DC. Do not delete \hy-7{1921}{
colour} while selected for use by a DC.


\hy-10{1923}{wxDC::SetUserScale}



\hy-8{1924}{void SetUserScale(float \hy-8{1925}{ x_scale}, float \hy-8{1926}{y_scale})}

Sets the user scaling factor, useful for applications which require
`zooming'.


\hy-10{1928}{wxDC::StartDoc}



\hy-8{1929}{Bool StartDoc(char * \hy-8{1930}{message})}

Starts a document (only relevant when outputting to a printer).
Message is a message to show whilst printing.


\hy-10{1932}{wxDC::StartPage}



\hy-8{1933}{Bool StartPage(void)}

Starts a document page (only relevant when outputting to a printer).


\hy-10{1944}{wxDialogBox::wxDialogBox}



\hy-8{1945}{void wxDialogBox(wxWindow * \hy-8{1946}{parent}, char * \hy-8{1947}{title},
Bool \hy-8{1948}{ modal=FALSE},
 int \hy-8{1949}{ x=300}, int \hy-8{1950}{ y=300}, 
  int \hy-8{1951}{ width=500}, int \hy-8{1952}{ height=500},

  long \hy-8{1953}{ style = wxDEFAULT_DIALOG_STYLE},

  char * \hy-8{1954}{name = ``dialogBox"})}

Constructor. The \hy-7{1955}{parent} of the dialog box can be NULL, a frame or
a dialog box.

If \hy-7{1956}{title} is non-NULL, it is placed on the window frame.

If \hy-7{1957}{modal} is TRUE, the dialog box will wait to be
dismissed (using \hy-14{1958}{Show(FALSE)}) before returning control to the
calling program.

The \hy-7{1959}{style} parameter may be a combination of the following, using the bitwise `or' operator:


wxABSOLUTE_POSITIONING
    A hint to the windowing system not to try automatic layout
  (Motif only). \hy-7{1960}{This is now obsolete from version 1.60.}

wxCAPTION
    Puts a caption on the dialog box (Motif only).

wxSYSTEM_MENU
    Display a system menu (Motif only).

wxTHICK_FRAME
    Display a thick frame around the window (Motif only).

wxRESIZE_BORDER
    Display a resizeable frame around the window (Motif only).

wxVSCROLL
    Give the dialog box a vertical scrollbar (XView only).

wxDEFAULT_DIALOG_STYLE
    Equivalent to wxCAPTION | wxSYSTEM_MENU | wxTHICK_FRAME



Note that none take effect under Windows, only wxVSCROLL works under XView,
and for Motif the MWM (the Motif Window Manager) should be running for any to work.

The \hy-7{1961}{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{1963}{wxDialogBox::~wxDialogBox}



\hy-8{1964}{void ~wxDialogBox(void)}

Destructor.  Deletes any panel items before deleting the physical window.


\hy-10{1966}{wxDialog::Centre}



\hy-8{1967}{void Centre(int \hy-8{1968}{ direction = wxBOTH})}

Centres the dialog box on the display. The parameter may be \hy-14{1969}{
wxHORIZONTAL}, \hy-14{1970}{wxVERTICAL} or \hy-14{1971}{wxBOTH}.


\hy-10{1973}{wxDialogBox::Create}



\hy-8{1974}{void Create(wxFrame * \hy-8{1975}{parent}, char * \hy-8{1976}{title},
Bool \hy-8{1977}{ modal=FALSE},
 int \hy-8{1978}{ x=300}, int \hy-8{1979}{ y=300}, 
  int \hy-8{1980}{ width=500}, int \hy-8{1981}{ height=500},

  long \hy-8{1982}{ style = wxCAPTION | wxSYSTEM_MENU | wxTHICK_FRAME},

  char * \hy-8{1983}{name = ``dialogBox"})}

Used for two-step dialog box construction. See \hy-13{1984}{wxDialogBox::wxDialogBox}
for details.


\hy-10{1986}{wxDialogBox::GetTitle}



\hy-8{1987}{char * GetTitle(void)}

Gets a temporary pointer to the title of the dialog box.


\hy-10{1989}{wxDialogBox::Iconize}



\hy-8{1990}{void Iconize(Bool \hy-8{1991}{ 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{1992}{Iconize(FALSE)} will bring the window to the front, as does
\hy-14{1993}{Show(TRUE)}.


\hy-10{1995}{wxDialogBox::Iconized}



\hy-8{1996}{Bool Iconized(void)}

Returns TRUE if the dialog box is iconized. Always returns FALSE under
Windows for the reasons given above.


\hy-10{1998}{wxDialogBox::SetTitle}



\hy-8{1999}{void SetTitle(char * \hy-8{2000}{ title})}

Sets the title of the dialog box.


\hy-10{2002}{wxDialogBox::Show}



\hy-8{2003}{void Show(Bool \hy-8{2004}{ show})}

If \hy-7{2005}{show} is TRUE, the dialog box is shown and brought to the front;
otherwise the box is hidden. If \hy-7{2006}{show} is FALSE and the dialog is
modal, control is returned to the calling program.


\hy-10{2015}{wxEnhDialogBox::wxEnhDialogBox}



\hy-8{2016}{void wxEnhDialogBox(wxFrame * \hy-8{2017}{frame}, char * \hy-8{2018}{title},

 Bool  \hy-8{2019}{modal = FALSE}, wxFunction  \hy-8{2020}{fun = NULL}, int  \hy-8{2021}{space = -1},

 int  \hy-8{2022}{x = 0}, int  \hy-8{2023}{y = 0}, int  \hy-8{2024}{width = 10}, int  \hy-8{2025}{height = 10},

 char * \hy-8{2026}{name = "Shell"})}

Constructor. \hy-7{2027}{fun} is called when the user dismiss the window by
using the pin or the cancel button. If \hy-7{2028}{space} is greater than zero, it is
used as panel horizontal spacing for the command area.


\hy-10{2030}{wxEnhDialogBox::~wxEnhDialogBox}



\hy-8{2031}{void ~wxEnhDialogBox(void)}

Destructor.


\hy-10{2033}{wxEnhDialogBox::userPanel}



\hy-8{2034}{wxPanel * userPanel}

User application items must be created in this panel.


\hy-10{2036}{wxEnhDialogBox::SetStatus}



\hy-8{2037}{void SetStatus(char * \hy-8{2038}{label=NULL})}

Display text in the staus area.


\hy-10{2040}{wxEnhDialogBox::AddCmd}



\hy-8{2041}{wxButton * AddCmd(char * \hy-8{2042}{label}, wxFunction  \hy-8{2043}{fun=NULL},

  int  \hy-8{2044}{tag = 0})}

\hy-8{2045}{wxButton * AddCmd(wxBitmap * \hy-8{2046}{bitmap}, wxFunction  \hy-8{2047}{fun=NULL},

  int  \hy-8{2048}{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{2049}{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{2051}{wxEnhDialogBox::GetCmd}



\hy-8{2052}{wxButton * GetCmd(int  \hy-8{2053}{n})}

Returns the identifier of the \hy-7{2054}{n}th wxButton in the command area
(starting at 0).


\hy-10{2056}{wxEnhDialogBox::SetPin}



\hy-8{2057}{void SetPin(Bool  \hy-8{2058}{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{2060}{wxEnhDialogBox::Show}



\hy-8{2061}{void Show(Bool  \hy-8{2062}{show}, Bool  \hy-8{2063}{flag = FALSE})}

Dismiss or popup the dialog box. If \hy-7{2064}{show} is FALSE, the dialog box
is dismissed only if the pushpin current state is FALSE. If \hy-7{2065}{show}
is TRUE, the dialog box is popped, and the pushpin is initialized in the
state \hy-7{2066}{flag}.


\hy-10{2068}{wxEnhDialogBox::Fit}



\hy-8{2069}{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{2076}{wxEvent::wxEvent}



\hy-8{2077}{void wxEvent(void)}

Constructor. Should not need to be used by an application.


\hy-10{2079}{wxEvent::~wxEvent}



\hy-8{2080}{void ~wxEvent(void)}

Destructor. Should not need to be used by an application.


\hy-10{2082}{wxEvent::eventClass}



\hy-8{2083}{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{2085}{wxEvent::eventHandle}



\hy-8{2086}{char * eventHandle}

Handle of an underlying windowing system event handle, such as
XEvent. Not guaranteed to be instantiated.


\hy-10{2088}{wxEvent::eventObject}



\hy-8{2089}{wxObject * eventObject}

The object (usually a window) that the event was generated from,
or should be sent to.


\hy-10{2091}{wxEvent::eventType}



\hy-8{2092}{WXTYPE  eventType}

The type of the event, such as wxEVENT_TYPE_BUTTON_COMMAND.


\hy-10{2094}{wxEvent::ReadEvent}



\hy-8{2095}{pure virtual Bool ReadEvent(istream& \hy-8{2096}{ stream})}

Reads the event from the given input stream.


\hy-10{2098}{wxEvent::WriteEvent}



\hy-8{2099}{pure virtual Bool WriteEvent(ostream& \hy-8{2100}{ stream})}

Writes the event to the given output stream.


\hy-10{2110}{wxFont::wxFont}



\hy-8{2111}{void wxFont(void)}

\hy-8{2112}{void wxFont(int \hy-8{2113}{ point_size}, int \hy-8{2114}{ family}, int \hy-8{2115}{ style}, int \hy-8{2116}{ weight}, Bool \hy-8{2117}{ 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{2118}{wxDC::SetFont}, \hy-13{2119}{wxDC::DrawText}
and \hy-13{2120}{wxDC::GetTextExtent}.

All fonts are automatically added to the global pointer \hy-8{2121}{wxTheFontList}.
Call \hy-13{2122}{wxFontList::FindOrCreateFont} to return
a previously-created font if possible.


\hy-10{2124}{wxFont::~wxFont}



\hy-8{2125}{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.

If you have to delete the font (for example, you are creating a lot of
them), then call \hy-13{2126}{wxDC::SetFont} with a NULL argument
to ensure that the old font is restored, and the current font is selected
out of the device context.


\hy-10{2128}{wxFont::GetFamily}



\hy-8{2129}{int GetFamily(void)}

Gets the font family. See \hy-13{2130}{wxFont} for a list of valid
family identifiers.


\hy-10{2132}{wxFont::GetPointSize}



\hy-8{2133}{int GetPointSize(void)}

Gets the point size.


\hy-10{2135}{wxFont::GetStyle}



\hy-8{2136}{int GetStyle(void)}

Gets the font style.  See \hy-13{2137}{wxFont} for a list of valid
styles.


\hy-10{2139}{wxFont::GetUnderlined}



\hy-8{2140}{Bool GetUnderlined(void)}

TRUE if the font is underlined.


\hy-10{2142}{wxFont::GetWeight}



\hy-8{2143}{int GetWeight(void)}

Gets the font weight.   See \hy-13{2144}{wxFont} for a list of valid
weight identifiers.


\hy-10{2149}{wxFontList::wxFontList}



\hy-8{2150}{void wxFontList(void)}

Constructor.  The application should not construct its own font list:
use the object pointer \hy-8{2151}{wxTheFontList}.


\hy-10{2153}{wxFontList::AddFont}



\hy-8{2154}{void AddFont(wxFont * \hy-8{2155}{font})}

Used by wxWindows to add a font to the list, called in the font constructor.


\hy-10{2157}{wxFontList::FindOrCreateFont}



\hy-8{2158}{wxFont * FindOrCreateFont(int \hy-8{2159}{ point_size}, int \hy-8{2160}{ family}, int \hy-8{2161}{ style}, int \hy-8{2162}{ weight}, Bool \hy-8{2163}{ underline = FALSE})}

Finds a font of the given specification, or creates one and adds it to the list.


\hy-10{2165}{wxFontList::RemoveFont}



\hy-8{2166}{void RemoveFont(wxFont * \hy-8{2167}{font})}

Used by wxWindows to remove a font from the list.


\hy-10{2171}{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{2173}{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{2175}{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:


wxFORM_DEFAULT
    Let wxWindows choose a suitable panel item.

wxFORM_SINGLE_LIST
    Use a single-selection listbox. Default for
string item with a one-of constraint.

wxFORM_CHOICE
    Use a choice item.

wxFORM_CHECKBOX
    Use a checkbox. Default for boolean item.

wxFORM_TEXT
    Use a single-line text item. Default for floating
point item, and for string and integer items with no constraints.

wxFORM_MULTITEXT
    Use a multi-line text item.

wxFORM_RADIOBOX
    Use a radiobox with a one-of constraint.

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{2176}{wxForm::Add} are given in the next subsection.


\hy-10{2178}{Example}



The following is an example of a form definition, taken from the form demo.
Here, a new form \hy-8{2179}{MyForm} has been derived, and a new member \hy-8{2180}{
EditForm} has been defined to edit objects of the type \hy-8{2181}{MyObject},
given a panel to display it on.

\hy-14{2182}{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{2184}{wxForm::wxForm}



\hy-8{2185}{void wxForm(int \hy-8{2186}{ useButtons = wxFORM_BUTTON_ALL},

  int \hy-8{2187}{ placeButtons = wxFORM_BUTTON_AT_TOP})}

Constructor. The value of \hy-7{2188}{useButtons} determines which buttons are
automatically created, and must be a bit list of the following
identifiers:


\hy-8{2189}{o}  wxFORM_BUTTON_OK
\hy-8{2190}{o}  wxFORM_BUTTON_CANCEL
\hy-8{2191}{o}  wxFORM_BUTTON_HELP
\hy-8{2192}{o}  wxFORM_BUTTON_UPDATE
\hy-8{2193}{o}  wxFORM_BUTTON_REVERT
\hy-8{2194}{o}  wxFORM_BUTTON_ALL


wxFORM_BUTTON_ALL is the same as specifying all buttons except
wxFORM_BUTTON_HELP.

\hy-7{2195}{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{2196}{o}  wxFORM_BUTTON_AT_TOP
\hy-8{2197}{o}  wxFORM_BUTTON_AT_BOTTOM



\hy-10{2199}{wxForm::~wxForm}



\hy-8{2200}{void ~wxForm(void)}

Destructor. Does not delete the associated panel or any panel items, but
does delete all form items.


\hy-10{2202}{wxForm::Add}



\hy-8{2203}{void Add(wxFormItem * \hy-8{2204}{item}, long  \hy-8{2205}{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{2207}{wxForm::AssociatePanel}



\hy-8{2208}{void AssociatePanel(wxPanel * \hy-8{2209}{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{2211}{wxForm::Delete}



\hy-8{2212}{Bool Delete(long  \hy-8{2213}{id})}

Deletes the given form item by id. Returns TRUE if successful.


\hy-10{2215}{wxForm::FindItem}



\hy-8{2216}{wxNode * FindItem(long  \hy-8{2217}{id})}

Given a form item id, returns a list node containing the form item.


\hy-10{2219}{wxForm::OnCancel}



\hy-8{2220}{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{2221}{OnCancel} deletes the form and the panel associated with
it, probably the normal desired behaviour.


\hy-10{2223}{wxForm::OnOk}



\hy-8{2224}{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{2225}{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{2227}{wxForm::OnRevert}



\hy-8{2228}{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{2230}{wxForm::OnUpdate}



\hy-8{2231}{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{2233}{wxForm::RevertValues}



\hy-8{2234}{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{2236}{wxForm::Set}



\hy-8{2237}{Bool Set(long  \hy-8{2238}{id}, wxFormItem * \hy-8{2239}{item})}

Given a form item id, replaces an existing item with that id with the
given form item. Returns TRUE if successful.


\hy-10{2241}{wxForm::UpdateValues}



\hy-8{2242}{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{2244}{Functions for making form items and constraints}



These functions make form items and their associated constraints for
passing to \hy-8{2245}{wxForm::Add}.

\hy-8{2246}{wxFormItem * wxMakeFormButton(char * \hy-8{2247}{label},
wxFunction \hy-8{2248}{ fun})}

Makes a button with a conventional callback.

\hy-8{2249}{wxFormItem * wxMakeFormMessage(char * \hy-8{2250}{label})}

Makes a message.

\hy-8{2251}{wxFormItem * wxMakeFormNewLine(void)}

Adds a newline.

\hy-8{2252}{wxFormItem * wxMakeFormLong(char * \hy-8{2253}{label}, long * \hy-8{2254}{var},

  int \hy-8{2255}{ item_type = wxFORM_DEFAULT}, wxList * \hy-8{2256}{constraints = NULL},

  char * \hy-8{2257}{help_string = NULL}, int \hy-8{2258}{ style = 0}, int \hy-8{2259}{ width = -1},

  int \hy-8{2260}{ 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{2261}{style} may be wxHORIZONTAL or wxVERTICAL (for label orientation).
\hy-7{2262}{help_string} is currently not used.

\hy-8{2263}{wxFormItem * wxMakeFormShort(char * \hy-8{2264}{label}, int * \hy-8{2265}{var},

  int \hy-8{2266}{ item_type = wxFORM_DEFAULT}, wxList * \hy-8{2267}{constraints = NULL},

  char * \hy-8{2268}{help_string = NULL}, int \hy-8{2269}{ style = 0}, int \hy-8{2270}{ width = -1},

  int \hy-8{2271}{ 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{2272}{style} may be wxHORIZONTAL or wxVERTICAL (for label orientation).
\hy-7{2273}{help_string} is currently not used.

\hy-8{2274}{wxFormItem * wxMakeFormFloat(char * \hy-8{2275}{label}, float * \hy-8{2276}{var},

  int \hy-8{2277}{ item_type = wxFORM_DEFAULT}, wxList * \hy-8{2278}{constraints = NULL},

  char * \hy-8{2279}{help_string = NULL}, int \hy-8{2280}{ style = 0},
  int \hy-8{2281}{ width = -1},

  int \hy-8{2282}{ 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{2283}{style} may be wxHORIZONTAL or wxVERTICAL (for label orientation).
\hy-7{2284}{help_string} is currently not used.

\hy-8{2285}{wxFormItem * wxMakeFormBool(char * \hy-8{2286}{label}, Bool * \hy-8{2287}{var},

  int \hy-8{2288}{ item_type = wxFORM_DEFAULT}, wxList * \hy-8{2289}{constraints = NULL},

  char * \hy-8{2290}{help_string = NULL}, int \hy-8{2291}{ style = 0}, int \hy-8{2292}{ width = -1},

  int \hy-8{2293}{ 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{2294}{style} may be wxHORIZONTAL or wxVERTICAL (for label orientation).
\hy-7{2295}{help_string} is currently not used.

\hy-8{2296}{wxFormItem * wxMakeFormString(char * \hy-8{2297}{label}, char ** \hy-8{2298}{var},

  int \hy-8{2299}{ item_type = wxFORM_DEFAULT}, wxList * \hy-8{2300}{constraints = NULL},

  char * \hy-8{2301}{help_string = NULL}, int \hy-8{2302}{ style = NULL},
  int \hy-8{2303}{ width = -1},

  int \hy-8{2304}{ 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{2305}{style} may be wxHORIZONTAL or wxVERTICAL (for label orientation).
\hy-7{2306}{help_string} is currently not used.

\hy-8{2307}{wxFormItemConstraint * wxMakeConstraintStrings(wxList * \hy-8{2308}{list})}

Makes a constraint specifying that the value must be one of the strings
given in the list.

\hy-8{2309}{wxFormItemConstraint * wxMakeConstraintStrings(char * \hy-8{2310}{first},  \hy-8{2311}{...})}

Makes a constraint specifying that the value must be one of the strings
given in the variable-length argument list,\hy-7{2312}{terminated with a zero}.

\hy-8{2313}{wxFormItemConstraint * wxMakeConstraintFunction(wxConstraintFunction  \hy-8{2314}{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{2315}{wxConstraintFunction} is defined as follows:

\hy-8{2316}{typedef Bool (*wxConstraintFunction)(int \hy-8{2317}{ type}, char * \hy-8{2318}{value}, char * \hy-8{2319}{label}, char * \hy-8{2320}{msg})}

\hy-7{2321}{type} is the type of the item, for instance wxFORM_STRING. \hy-7{2322}{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{2323}{wxFormItemConstraint * wxMakeConstraintRange(float \hy-8{2324}{ lo}, float \hy-8{2325}{ hi})}

Makes a range constraint; can be used for integer and floating point
form items.


\hy-10{2333}{wxFormItem::GetPanelItem}



\hy-8{2334}{wxItem * GetPanelItem(void)}

Gets the panel item for this form item. Must only be called \hy-7{2335}{after}
\hy-13{2336}{wxForm::AssociatePanel} has been called.


\hy-10{2344}{wxFrame::wxFrame}



\hy-8{2345}{void wxFrame(wxFrame * \hy-8{2346}{parent}, char * \hy-8{2347}{title}, int \hy-8{2348}{ x = -1}, int \hy-8{2349}{ y = -1},

  int \hy-8{2350}{ width = -1}, int \hy-8{2351}{ height = -1},

  long \hy-8{2352}{ style = wxSDI | wxDEFAULT_FRAME}, char * \hy-8{2353}{name = ``frame"})}

Constructor.  The \hy-7{2354}{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{2355}{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.


wxICONIZE
    Display the frame iconized (minimized) (Windows only).

wxCAPTION
    Puts a caption on the frame (Windows and XView only).

wxDEFAULT_FRAME
    Defined as \hy-8{2356}{(wxMINIMIZE_BOX | wxMAXIMIZE_BOX | wxTHICK_FRAME | wxSYSTEM_MENU | wxCAPTION)}.

wxMDI_CHILD
    Specifies a Windows MDI (multiple document interface) child frame.

wxMDI_PARENT
    Specifies a Windows MDI (multiple document interface) parent frame.

wxMINIMIZE
    Identical to \hy-8{2357}{wxICONIZE}.

wxMINIMIZE_BOX
    Displays a minimize box on the frame (Windows and Motif only).

wxMAXIMIZE
    Displays the frame maximized (Windows only).

wxMAXIMIZE_BOX
    Displays a maximize box on the frame (Windows and Motif only).

wxSDI
    Specifies a normal SDI (single document interface) frame.

wxSTAY_ON_TOP
    Stay on top of other windows (Windows only).

wxSYSTEM_MENU
    Displays a system menu (Windows and Motif only).

wxTHICK_FRAME
    Displays a thick frame around the window (Windows and Motif only).

wxRESIZE_BORDER
    Displays a resizeable border around the window (Motif only).

wxTINY_CAPTION_HORIZ
    Under Windows 3.1, displays a small horizontal caption if USE_ITSY_BITSY is
set to 1 in wx_setup.h and the Microsoft ItsyBitsy library has been compiled. Use instead of
wxCAPTION.

wxTINY_CAPTION_VERT
    Under Windows 3.1, displays a small vertical caption if USE_ITSY_BITSY is
set to 1 in wx_setup.h and the Microsoft ItsyBitsy library has been compiled. Use instead of
wxCAPTION.



For Motif, the MWM (the Motif Window Manager) should be running for any styles to work
(otherwise all styles take effect).

The \hy-7{2358}{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{2360}{wxFrame::~wxFrame}



\hy-8{2361}{void ~wxFrame(void)}

Destructor. Destroys all child windows and menu bar if present.


\hy-10{2363}{wxFrame::Centre}



\hy-8{2364}{void Centre(int \hy-8{2365}{ direction = wxBOTH})}

Centres the frame on the display. The parameter may be \hy-14{2366}{
wxHORIZONTAL}, \hy-14{2367}{wxVERTICAL} or \hy-14{2368}{wxBOTH}.


\hy-10{2370}{wxFrame::Command}



\hy-8{2371}{void Command(int  \hy-8{2372}{id})}

Simulate a menu command. \hy-7{2373}{id} is the identifier for a menu item.


\hy-10{2375}{wxFrame::Create}



\hy-8{2376}{void Create(wxFrame * \hy-8{2377}{parent}, char * \hy-8{2378}{title}, int \hy-8{2379}{ x = -1}, int \hy-8{2380}{ y = -1},

  int \hy-8{2381}{ width = -1}, int \hy-8{2382}{ height = -1},

  long \hy-8{2383}{ style = wxSDI | wxDEFAULT_FRAME}, char * \hy-8{2384}{name = ``frame"})}

Used in two-step frame construction. See \hy-13{2385}{wxFrame::wxFrame}
for further details.


\hy-10{2387}{wxFrame::CreateStatusLine}



\hy-8{2388}{void CreateStatusLine(int \hy-8{2389}{ 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{2390}{wxFrame::SetStatusText}.


\hy-10{2392}{wxFrame::Fit}



\hy-8{2393}{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{2394}{wxFrame::OnSize}
member to fit inside the frame.


\hy-10{2396}{wxFrame::GetTitle}



\hy-8{2397}{char * GetTitle(void)}

Gets a temporary pointer to the frame title. See
\hy-13{2398}{wxFrame::SetTitle}.


\hy-10{2400}{wxFrame::Iconize}



\hy-8{2401}{void Iconize(Bool \hy-8{2402}{ iconize})}

If TRUE, iconizes the frame; if FALSE, shows and restores it.


\hy-10{2404}{wxFrame::Iconized}



\hy-8{2405}{Bool Iconized(void)}

Returns TRUE if the frame is iconized.


\hy-10{2407}{wxFrame::LoadAccelerators}



\hy-8{2408}{void LoadAccelerators(char * \hy-8{2409}{resource})}

Loads keyboard accelerators for this frame (Windows only). Accelerator
tables map keystrokes onto control and menu identifiers, so the
programmer does not have to explicitly program this correspondence.

See the hello demo (\hy-14{2410}{hello.cc} and \hy-14{2411}{hello.rc}) for
an example of accelerator usage. This is a fragment from \hy-14{2412}{hello.rc}:

\hy-14{2413}{#define HELLO_LOAD_FILE  111

menus_accel ACCELERATORS
{

"^L", HELLO_LOAD_FILE

}
}

\hy-10{2415}{wxFrame::Maximize}



\hy-8{2416}{void Maximize(Bool  \hy-8{2417}{maximize})}

Maximizes the frame if \hy-7{2418}{maximize} is TRUE, otherwise restores it
(Windows 3.1 only).


\hy-10{2420}{wxFrame::OnClose}



\hy-8{2421}{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{2422}{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{2423}{OnClose} handler for the `hello' demo:

\hy-14{2424}{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{2425}{OnClose} member before deleting
the frame. wxWindows then causes the application to exit without further
ado. For example:

\hy-14{2426}{// Intercept menu commands
void MyFrame::OnMenuCommand(int id)
{
  switch (id)
  {
    ...
    case HELLO_QUIT:
    {
      OnClose();
      delete this;
      break;
    }
    ...
  }
}
}

\hy-10{2428}{wxFrame::OnMenuCommand}



\hy-8{2429}{void OnMenuCommand(int \hy-8{2430}{ 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{2431}{// 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{2433}{wxFrame::OnMenuSelect}



\hy-8{2434}{void OnMenuSelect(int \hy-8{2435}{ 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{2436}{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{2438}{wxFrame::OnSize}



\hy-8{2439}{void OnSize(int \hy-8{2440}{ w}, int \hy-8{2441}{ h})}

Called when the user or application resizes the frame. The parameters
give the total size of the frame. The default \hy-8{2442}{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{2444}{wxFrame::SetIcon}



\hy-8{2445}{void SetIcon(wxIcon * \hy-8{2446}{ 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{2447}{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{2448}{wxSTD_FRAME      ICON icon1.ico
}
See also \hy-13{2449}{wxIcon}.


\hy-10{2451}{wxFrame::SetMenuBar}



\hy-8{2452}{void SetMenuBar(wxMenuBar * \hy-8{2453}{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{2454}{wxMenuBar}, \hy-13{2455}{wxMenu}.


\hy-10{2457}{wxFrame::SetStatusText}



\hy-8{2458}{void SetStatusText(char * \hy-8{2459}{ text}, int \hy-8{2460}{ 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{2461}{number} to specify a
field in the status line, starting from zero and consistent with the number
of fields specified in \hy-13{2462}{wxFrame::CreateStatusLine}.


\hy-10{2464}{wxFrame::SetTitle}



\hy-8{2465}{void SetTitle(char * \hy-8{2466}{ title})}

Sets the frame title. See \hy-13{2467}{wxFrame::GetTitle}.


\hy-10{2469}{wxFrame::StatusLineExists}



\hy-8{2470}{Bool StatusLineExists(void)}

Returns TRUE if the status line has previously been created.
See \hy-13{2471}{wxFrame::CreateStatusLine}, \hy-13{2472}{wxFrame::SetStatusText}.


\hy-10{2476}{wxFunction}



\hy-8{2477}{typedef void (*wxFunction)(wxObject& \hy-8{2478}{}, wxCommandEvent& \hy-8{2479}{})}

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{2480}{wxItem}, \hy-13{2481}{wxCommandEvent}.


\hy-10{2489}{wxIcon::wxIcon}



\hy-8{2490}{void wxIcon(void)}

\hy-8{2491}{void wxIcon(char \hy-8{2492}{ bits[]}, int \hy-8{2493}{ width}, int \hy-8{2494}{ height})}

\hy-8{2495}{void wxIcon(char * \hy-8{2496}{ icon_name})}

Constructor. An icon can be created by passing an array of bits (X only)
or by passing a string name. \hy-7{2497}{icon_name} refers to a filename in X,
a resource name in Windows 3.  


\hy-10{2499}{wxIcon::~wxIcon}



\hy-8{2500}{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{2506}{wxHashTable::wxHashTable}



\hy-8{2507}{void wxHashTable(unsigned int \hy-8{2508}{ key_type}, int \hy-8{2509}{ size = 1000})}

Constructor. \hy-7{2510}{key_type} is one of wxKEY_INTEGER, or wxKEY_STRING,
and indicates what sort of keying is required. \hy-7{2511}{size} is optional.


\hy-10{2513}{wxHashTable::~wxHashTable}



\hy-8{2514}{void ~wxHashTable(void)}

Destroys the hash table.


\hy-10{2516}{wxHashTable::BeginFind}



\hy-8{2517}{void BeginFind(void)}

The counterpart of \hy-7{2518}{Next}.  If the application wishes to iterate
through all the data in the hash table, it can call \hy-7{2519}{BeginFind} and
then loop on \hy-7{2520}{Next}.


\hy-10{2522}{wxHashTable::Clear}



\hy-8{2523}{void Clear(void)}

Clears the hash table of all nodes (but as usual, doesn't delete user data).


\hy-10{2525}{wxHashTable::Delete}



\hy-8{2526}{wxObject * Delete(long \hy-8{2527}{ key})}

\hy-8{2528}{wxObject * Delete(char * \hy-8{2529}{ key})}

Deletes entry in hash table and returns the user's data (if found).


\hy-10{2531}{wxHashTable::Get}



\hy-8{2532}{wxObject * Get(long \hy-8{2533}{ key})}

\hy-8{2534}{wxObject * Get(char * \hy-8{2535}{ key})}

Gets data from the hash table, using an integer or string key (depending on which
has table constructor was used).


\hy-10{2537}{wxHashTable::MakeKey}



\hy-8{2538}{long MakeKey(char * \hy-8{2539}{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{2541}{wxHashTable::Next}



\hy-8{2542}{wxNode * Next(void)}

If the application wishes to iterate through all the data in the hash
table, it can call \hy-7{2543}{BeginFind} and then loop on \hy-7{2544}{Next}. This function
returns a \hy-8{2545}{wxNode} pointer (or NULL if there are no more nodes).  See the
description for \hy-13{2546}{wxNode}. The user will probably only wish to use the
\hy-8{2547}{wxNode::Data} function to retrieve the data; the node may also be deleted.


\hy-10{2549}{wxHashTable::Put}



\hy-8{2550}{void Put(long \hy-8{2551}{ key}, wxObject * \hy-8{2552}{object})}

\hy-8{2553}{void Put(char * \hy-8{2554}{ key}, wxObject * \hy-8{2555}{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{2566}{wxHelpInstance::wxHelpInstance}



\hy-8{2567}{void wxHelpInstance(Bool \hy-8{2568}{ native})}

Constructs a help instance object, but does not invoke wxHelp.
If \hy-7{2569}{native} is TRUE, tries to use the native help system where
possible (Windows Help under Windows 3.1, wxHelp on other platforms).


\hy-10{2571}{wxHelpInstance::~wxHelpInstance}



Destroys the help instance, closing down wxHelp for this application
if it is running.


\hy-10{2573}{wxHelpInstance::Initialize}



\hy-8{2574}{void Initialize(char * \hy-8{2575}{file}, int \hy-8{2576}{ 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{2578}{wxHelpInstance::DisplayBlock}



\hy-8{2579}{Bool DisplayBlock(long \hy-8{2580}{ 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{2582}{wxHelpInstance::DisplayContents}



\hy-8{2583}{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{2585}{wxHelpInstance::DisplaySection}



\hy-8{2586}{Bool DisplaySection(int \hy-8{2587}{ 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{2589}{wxHelpInstance::KeywordSearch}



\hy-8{2590}{Bool KeywordSearch(char * \hy-8{2591}{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{2593}{wxHelpInstance::LoadFile}



\hy-8{2594}{Bool LoadFile(char * \hy-8{2595}{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{2596}{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{2598}{wxHelpInstance::OnQuit}



\hy-8{2599}{Bool OnQuit(void)}

Overridable member called when this application's wxHelp is quit
(no effect if Windows Help is being used instead).


\hy-10{2601}{wxHelpInstance::Quit}



\hy-8{2602}{Bool Quit(void)}

If wxHelp is running, quits wxHelp by disconnecting (no effect for Windows
Help).


\hy-10{2610}{wxIntPoint::wxIntPoint}



\hy-8{2611}{void wxIntPoint(void)}

\hy-8{2612}{void wxIntPoint(int \hy-8{2613}{ x}, int \hy-8{2614}{ y})}

Create a point.

\hy-8{2615}{int  x}

\hy-8{2616}{int  y}

Members of the \hy-8{2617}{wxIntPoint} object.


\hy-10{2621}{wxItem::Centre}



\hy-8{2622}{void Centre(int \hy-8{2623}{ direction = wxHORIZONTAL})}

Centres the frame on the panel or dialog box. The parameter may be \hy-14{2624}{
wxHORIZONTAL}, \hy-14{2625}{wxVERTICAL} or \hy-14{2626}{wxBOTH}.

You may still use \hy-8{2627}{Fit} in conjunction with this call, but call \hy-8{2628}{Fit}
first before centring items.


\hy-10{2630}{wxItem::Command}



\hy-8{2631}{void Command(wxCommandEvent \hy-8{2632}{ event})}

Simulate the effect of the user issuing a command to the item. See \hy-13{2633}{wxCommandEvent}.


\hy-10{2635}{wxItem::GetBackgroundColour}



\hy-8{2636}{wxColour * GetBackgroundColour(void)}

Gets the item background colour (Motif only).


\hy-10{2638}{wxItem::GetButtonColour}



\hy-8{2639}{wxColour * GetButtonColour(void)}

Gets the item button colour (Motif only).


\hy-10{2641}{wxItem::GetLabelColour}



\hy-8{2642}{wxColour * GetLabelColour(void)}

Gets the item label colour (Motif only).


\hy-10{2644}{wxItem::GetLabel}



\hy-8{2645}{char * GetLabel(void)}

Gets a temporary pointer to the item's label.


\hy-10{2647}{wxItem::SetBackgroundColour}



\hy-8{2648}{void SetBackgroundColour(wxColour * \hy-8{2649}{colour})}

Sets the item background colour (Motif only).


\hy-10{2651}{wxItem::SetButtonColour}



\hy-8{2652}{void SetButtonColour(wxColour * \hy-8{2653}{colour})}

Sets the item button's colour (Motif only).


\hy-10{2655}{wxItem::SetLabel}



\hy-8{2656}{void SetLabel(char * \hy-8{2657}{label})}

Sets the item's label. A copy of the label is taken.


\hy-10{2659}{wxItem::SetLabelColour}



\hy-8{2660}{void SetLabelColour(wxColour * \hy-8{2661}{colour})}

Sets the item label's colour (Motif only).


\hy-10{2666}{wxKeyEvent::controlDown}



\hy-8{2667}{Bool  controlDown}

TRUE if control is pressed down.


\hy-10{2669}{wxKeyEvent::keyCode}



\hy-8{2670}{long  keyCode}

Virtual keycode.


\hy-10{2672}{wxKeyEvent::shiftDown}



\hy-8{2673}{Bool  shiftDown}

TRUE if shift is pressed down.


\hy-10{2675}{wxKeyEvent::wxKeyEvent}



\hy-8{2676}{void wxKeyEvent(WXTYPE \hy-8{2677}{ keyEventType})}

Constructor. Currently, the only valid event type is wxEVENT_TYPE_CHAR.


\hy-10{2679}{wxKeyEvent::ControlDown}



\hy-8{2680}{Bool ControlDown(void)}

Returns TRUE if the control key was down at the time of the key event.


\hy-10{2682}{wxKeyEvent::KeyCode}



\hy-8{2683}{long KeyCode(void)}

Returns the virtual key code. ASCII events return normal ASCII values,
while non-ASCII events return values such as \hy-8{2684}{WXK_LEFT} for the
left cursor key. See \hy-14{2685}{common.h} for a full list of the virtual key codes.


\hy-10{2687}{wxKeyEvent::Position}



\hy-8{2688}{void Position(float * \hy-8{2689}{x}, float * \hy-8{2690}{y})}

Obtains the position at which the key was pressed.


\hy-10{2692}{wxKeyEvent::ShiftDown}



\hy-8{2693}{Bool ShiftDown(void)}

Returns TRUE if the shift key was down at the time of the key event.


\hy-10{2703}{wxList::wxList}



\hy-8{2704}{void wxList(void)}

\hy-8{2705}{void wxList(unsigned int \hy-8{2706}{ key_type})}

\hy-8{2707}{void wxList(int \hy-8{2708}{ n}, wxObject * \hy-8{2709}{objects[]})}

\hy-8{2710}{void wxList(wxObject * \hy-8{2711}{object}, ...)}

Constructors. \hy-7{2712}{key_type} is one of wxKEY_NONE, wxKEY_INTEGER, or wxKEY_STRING,
and indicates what sort of keying is required (if any).

\hy-7{2713}{objects} is an array of \hy-7{2714}{n} objects with which to initialize the list.

The variable-length argument list constructor must be supplied with a
terminating NULL.


\hy-10{2716}{wxList::~wxList}



\hy-8{2717}{void ~wxList(void)}

Destroys list.  Also destroys any remaining nodes, but does not destroy
client data held in the nodes.


\hy-10{2719}{wxList::Append}



\hy-8{2720}{wxNode * Append(wxObject * \hy-8{2721}{object})}

\hy-8{2722}{wxNode * Append(long \hy-8{2723}{ key}, wxObject * \hy-8{2724}{object})}

\hy-8{2725}{wxNode * Append(char * \hy-8{2726}{key}, wxObject * \hy-8{2727}{object})}

Appends a new \hy-8{2728}{wxNode} to the end of the list and puts a pointer to the
\hy-7{2729}{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{2731}{wxList::Clear}



\hy-8{2732}{void Clear(void)}

Clears the list (but does not delete the client data stored with each node).


\hy-10{2734}{wxList::DeleteContents}



\hy-8{2735}{void DeleteContents(Bool \hy-8{2736}{ destroy})}

If \hy-7{2737}{destroy} is TRUE, instructs the list to call \hy-7{2738}{delete} on the client contents of
a node whenever the node is destroyed. The default is FALSE.


\hy-10{2740}{wxList::DeleteNode}



\hy-8{2741}{Bool DeleteNode(wxNode * \hy-8{2742}{node})}

Deletes the given node from the list, returning TRUE if successful.


\hy-10{2744}{wxList::DeleteObject}



\hy-8{2745}{Bool DeleteObject(wxObject * \hy-8{2746}{object})}

Finds the given client \hy-7{2747}{object} and deletes the appropriate node from the list, returning
TRUE if successful. The application must delete the actual object separately.


\hy-10{2749}{wxList::Find}



\hy-8{2750}{wxNode * Find(long \hy-8{2751}{ key})}

\hy-8{2752}{wxNode * Find(char * \hy-8{2753}{key})}

Returns the node whose stored key matches \hy-7{2754}{key}. Use on a keyed list only.


\hy-10{2756}{wxList::First}



\hy-8{2757}{wxNode * First(void)}

Returns the first node in the list (NULL if the list is empty).


\hy-10{2759}{wxList::Insert}



\hy-8{2760}{wxNode * Insert(wxObject * \hy-8{2761}{object})}

Insert object at front of list.

\hy-8{2762}{wxNode * Insert(wxNode * \hy-8{2763}{position}, wxObject * \hy-8{2764}{object})}

Insert object before \hy-7{2765}{position}.



\hy-10{2767}{wxList::Last}



\hy-8{2768}{wxNode * Last(void)}

Returns the last node in the list (NULL if the list is empty).


\hy-10{2770}{wxList::Member}



\hy-8{2771}{wxNode * Member(wxObject * \hy-8{2772}{object})}

Returns the node associated with \hy-7{2773}{object} if it is in the list, NULL otherwise.


\hy-10{2775}{wxList::Nth}



\hy-8{2776}{wxNode * Nth(int \hy-8{2777}{ n})}

Returns the \hy-7{2778}{nth} node in the list, indexing from zero (NULL if the list is empty
or the nth node could not be found).


\hy-10{2780}{wxList::Number}



\hy-8{2781}{int Number(void)}

Returns the number of elements in the list.


\hy-10{2788}{wxListBox::wxListBox}



\hy-8{2789}{void wxListBox(void)}

Constructor, for deriving classes.

\hy-8{2790}{void wxListBox(wxPanel * \hy-8{2791}{parent}, wxFunction \hy-8{2792}{ func}, char * \hy-8{2793}{label},

  Bool \hy-8{2794}{ multiple_selection = wxSINGLE}, int \hy-8{2795}{ x = -1}, int \hy-8{2796}{ y = -1},

  int \hy-8{2797}{ width = -1}, int \hy-8{2798}{ height = -1}, int \hy-8{2799}{ n}, char * \hy-8{2800}{choices[]},

  long \hy-8{2801}{ style = 0}, char * \hy-8{2802}{name = ``listBox"})}

Constructor, creating and showing a list box.

\hy-7{2803}{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{2804}{label} is non-NULL, it will be used as the listbox label.

The parameters \hy-7{2805}{x} and \hy-7{2806}{y} are used to specify an absolute
position, or a position after the previous panel item if omitted or
default.

If \hy-7{2807}{width} or \hy-7{2808}{height} are omitted (or are less than zero), an
appropriate size will be used for the list box.

\hy-7{2809}{n} is the number of possible choices, and \hy-7{2810}{choices} is an array of strings
of size \hy-7{2811}{n}. wxWindows allocates its own memory for these strings so the
calling program must deallocate the array itself.

\hy-7{2812}{multiple_selection} is a bit list of some of the following:


wxSINGLE
    Single-selection list.

wxMULTIPLE
    Multiple-selection list.

wxEXTENDED
    Extended-selection list (Motif only).

wxNEEDED_SB
    Create scrollbars if needed.

wxALWAYS_SB
    Create scrollbars immediately.



\hy-7{2813}{style} is a bit list of some of the following:


wxNEEDED_SB
    Create scrollbars if needed.

wxALWAYS_SB
    Create scrollbars immediately.

wxHSCROLL
    Create horizontal scrollbar if contents are two wide (Windows only).



The \hy-7{2814}{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{2816}{wxListBox::~wxListBox}



\hy-8{2817}{void ~wxListBox(void)}

Destructor, destroying the list box.


\hy-10{2819}{wxListBox::Append}



\hy-8{2820}{void Append(char * \hy-8{2821}{ item})}

Adds the item to the end of the list box. \hy-7{2822}{item} must be deallocated by the calling
program, i.e. wxWindows makes its own copy.

\hy-8{2823}{void Append(char * \hy-8{2824}{ item}, char * \hy-8{2825}{client_data})}

Adds the item to the end of the list box, associating the given data
with the item. \hy-7{2826}{item} must be deallocated by the calling program.


\hy-10{2828}{wxListBox::Clear}



\hy-8{2829}{void Clear(void)}

Clears all strings from the list box.


\hy-10{2831}{wxListBox::Create}



\hy-8{2832}{Bool Create(wxPanel * \hy-8{2833}{parent}, wxFunction \hy-8{2834}{ func}, char * \hy-8{2835}{label},

  Bool \hy-8{2836}{ multiple_selection = FALSE}, int \hy-8{2837}{ x = -1}, int \hy-8{2838}{ y = -1},

  int \hy-8{2839}{ width = -1}, int \hy-8{2840}{ height = -1}, int \hy-8{2841}{ n}, char * \hy-8{2842}{choices[]},

  long \hy-8{2843}{ style = 0}, char * \hy-8{2844}{name = ``listBox"})}

Creates the listbox for two-step construction. Derived classes
should call or replace this function. See \hy-13{2845}{wxListBox::wxListBox}
for further details.


\hy-10{2847}{wxListBox::Delete}



\hy-8{2848}{void Delete(int \hy-8{2849}{ n})}

Delete the nth element in the list box.


\hy-10{2851}{wxListBox::Deselect}



\hy-8{2852}{void Deselect(int \hy-8{2853}{ n})}

Deselects the given item in the list box.


\hy-10{2855}{wxListBox::FindString}



\hy-8{2856}{int FindString(int \hy-8{2857}{ char *s})}

Finds a choice matching the given string, returning the position if found, or
-1 if not found.


\hy-10{2859}{wxListBox::GetClientData}



\hy-8{2860}{char * GetClientData(int \hy-8{2861}{ n})}

Returns a pointer to the client data associated with the given item (if any).


\hy-10{2863}{wxListBox::GetSelection}



\hy-8{2864}{int GetSelection(void)}

Gets the id (position) of the selected string - for single selection list boxes only.


\hy-10{2866}{wxListBox::GetSelections}



\hy-8{2867}{int GetSelections(int ** \hy-8{2868}{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{2870}{wxListBox::GetStringSelection}



\hy-8{2871}{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{2873}{wxListBox::Selected}



\hy-8{2874}{Bool Selected(int \hy-8{2875}{ n})}

Returns TRUE if the given item is selected, FALSE otherwise.


\hy-10{2877}{wxListBox::Set}



\hy-8{2878}{void Set(int \hy-8{2879}{ n}, char * \hy-8{2880}{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{2882}{wxListBox::SetFirstItem}



\hy-8{2883}{void SetFirstItem(int \hy-8{2884}{ n})}
\hy-8{2885}{void SetFirstItem(char * \hy-8{2886}{item})}

Set the specified item to be the first visible item (not XView).


\hy-10{2888}{wxListBox::SetSelection}



\hy-8{2889}{void SetSelection(int \hy-8{2890}{ n}, Bool \hy-8{2891}{select = TRUE})}

Selects or deselects the given item.


\hy-10{2893}{wxListBox::SetStringSelection}



\hy-8{2894}{void SetStringSelection(char * \hy-8{2895}{ s})}

Sets the choice by passing the desired string.


\hy-10{2897}{wxListBox::GetString}



\hy-8{2898}{char * GetString(int \hy-8{2899}{ n})}

Returns a temporary pointer to the string at position \hy-7{2900}{n}.


\hy-10{2909}{wxMemoryDC::wxMemoryDC}



\hy-8{2910}{void wxMemoryDC(void)}

Constructs a new memory device context.

\hy-8{2911}{void wxMemoryDC(wxCanvasDC * \hy-8{2912}{oldDC})}

Constructs a new memory device context with similar attributes to the
given canvas device context.

Use the \hy-7{2913}{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{2915}{wxMemoryDC::SelectObject}



\hy-8{2916}{void SelectObject(wxBitmap * \hy-8{2917}{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{2918}{Blit} to copy
the bitmap to a canvas. For this purpose, you may find \hy-13{2919}{wxDC::DrawIcon}
easier to use instead.

If the argument is NULL, the current bitmap is selected out of the device
context, and the original bitmap restored, allowing the current bitmap to
be destroyed safely.


\hy-10{2925}{wxMenu::wxMenu}



\hy-8{2926}{void wxMenu(char * \hy-8{2927}{title = NULL}, wxFunction \hy-8{2928}{ 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{2929}{wxWindow::PopupMenu}.


\hy-10{2931}{wxMenu::~wxMenu}



\hy-8{2932}{void ~wxMenu(void)}

Destructor, destroying the menu.


\hy-10{2934}{wxMenu::Append}



\hy-8{2935}{void Append(int \hy-8{2936}{ id}, char * \hy-8{2937}{ item}, char * \hy-8{2938}{helpString = NULL})}

\hy-8{2939}{void Append(int \hy-8{2940}{ id}, char * \hy-8{2941}{ item}, wxMenu * \hy-8{2942}{submenu},
  char * \hy-8{2943}{helpString = NULL})}

Adds the item to the end of the menu. \hy-7{2944}{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). From version 1.50k, this can be used dynamically, i.e. after initial
creation of a menu or menubar.

Each form can take an optional help string, which can be accessed using
\hy-8{2945}{wxMenu::GetHelpString}. The default \hy-8{2946}{wxFrame::OnMenuSelect} member
uses this help string to give help on the menu item currently under the
cursor.

See the \hy-14{2947}{hello.cc} demo for an example of using \hy-8{2948}{Append} dynamically
to implement a file history facility. See also \hy-13{2949}{wxMenu::SetLabel}.


\hy-10{2951}{wxMenu::AppendSeparator}



\hy-8{2952}{void AppendSeparator(void)}

Adds a separator to the end of the menu. Under XView, this appears as
a space.


\hy-10{2954}{wxMenu::Check}



\hy-8{2955}{void Check(int \hy-8{2956}{ id}, Bool \hy-8{2957}{ flag})}

If \hy-7{2958}{flag} is TRUE, checks the given menu item, else unchecks it.
Windows 3, Motif.


\hy-10{2960}{wxMenu::Enable}



\hy-8{2961}{void Enable(int \hy-8{2962}{ id}, Bool \hy-8{2963}{ flag})}

If \hy-7{2964}{flag} is TRUE, enables the given menu item, else disables it
(greys it). Windows 3, Motif, XView.


\hy-10{2966}{wxMenu::FindItem}



\hy-8{2967}{int FindItem(char * \hy-8{2968}{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{2970}{wxMenu::FindItemForId}



\hy-8{2971}{wxMenuItem * FindItemForId(int \hy-8{2972}{ itemId})}

Finds the menu item object associated with the given menu item identifier,
returning NULL if not found.


\hy-10{2974}{wxMenu::GetHelpString}



\hy-8{2975}{char * GetHelpString(int \hy-8{2976}{ 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{2978}{wxMenu::GetLabel}



\hy-8{2979}{char * GetLabel(int \hy-8{2980}{ id})}

Gets a temporary pointer to the label of the given menu item; copy this for
long-term use. \hy-7{2981}{id} is the identifier given to \hy-13{2982}{wxMenu::Append}.


\hy-10{2984}{wxMenu::GetTitle}



\hy-8{2985}{char * GetTitle(void)}

Gets a temporary pointer to the title of the menu.


\hy-10{2987}{wxMenu::SetHelpString}



\hy-8{2988}{void SetHelpString(int \hy-8{2989}{ itemId}, char * \hy-8{2990}{helpString})}

Sets the help string associated with the menu item identifer.


\hy-10{2992}{wxMenu::SetLabel}



\hy-8{2993}{void SetLabel(int \hy-8{2994}{ id}, char * \hy-8{2995}{label})}

Sets the label of the given menu item (using the identifier used to
append the item to the menu).

See the \hy-14{2996}{hello.cc} demo for an example of using this command to
implement a file history facility. See also \hy-13{2997}{wxMenu::Append}.



\hy-10{2999}{wxMenu::SetTitle}



\hy-8{3000}{void SetTitle(char * \hy-8{3001}{title})}

Sets the title of the menu.



\hy-10{3006}{wxMenuBar::wxMenuBar}



\hy-8{3007}{void wxMenuBar(void)}

\hy-8{3008}{void wxMenuBar(int \hy-8{3009}{ n}, wxMenu * \hy-8{3010}{menus[]}, char * \hy-8{3011}{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{3013}{wxMenuBar::~wxMenuBar}



\hy-8{3014}{void ~wxMenuBar(void)}

Destructor, destroying the menu bar and removing it from the parent frame (if any).


\hy-10{3016}{wxMenuBar::Append}



\hy-8{3017}{void Append(wxMenu * \hy-8{3018}{menu}, char * \hy-8{3019}{title})}

Adds the item to the end of the menu bar. Do not use \hy-7{3020}{menu} after
this call: it will be deallocated by wxWindows.


\hy-10{3022}{wxMenuBar::Check}



\hy-8{3023}{void Check(int \hy-8{3024}{ id}, Bool \hy-8{3025}{ flag})}

If \hy-7{3026}{flag} is TRUE, checks the given menu item, else unchecks it.
Windows 3, Motif. Only use this when the menu bar has been associated
with a frame; otherwise, use the wxMenu equivalent call.


\hy-10{3028}{wxMenuBar::Enable}



\hy-8{3029}{void Enable(int \hy-8{3030}{ id}, Bool \hy-8{3031}{ flag})}

If \hy-7{3032}{flag} is TRUE, enables the given menu item, else disables it
(greys it). Windows 3, Motif. Only use this when the menu bar has been
associated with a frame; otherwise, use the wxMenu equivalent call.


\hy-10{3034}{wxMenuBar::EnableTop}



\hy-8{3035}{void EnableTop(int \hy-8{3036}{ pos}, Bool \hy-8{3037}{ flag})}

If \hy-7{3038}{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{3040}{wxMenuBar::FindMenuItem}



\hy-8{3041}{int FindMenuItem(char * \hy-8{3042}{menuString}, char * \hy-8{3043}{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{3045}{wxMenuBar::FindItemById}



\hy-8{3046}{wxMenuItem * FindItemById(int \hy-8{3047}{ itemId})}

Finds the menu item object associated with the given menu item identifier,
returning NULL if not found.


\hy-10{3049}{wxMenuBar::GetHelpString}



\hy-8{3050}{char * GetHelpString(int \hy-8{3051}{ 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{3053}{wxMenuBar::GetLabel}



\hy-8{3054}{char * GetLabel(int \hy-8{3055}{ 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{3056}{
wxFrame::SetMenuBar}.


\hy-10{3058}{wxMenuBar::GetLabelTop}



\hy-8{3059}{char * GetLabelTop(int \hy-8{3060}{ pos})}

Returns a temporary pointer to the label of the given top-level menu. \hy-7{3061}{
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{3062}{wxFrame::SetMenuBar}.


\hy-10{3064}{wxMenuBar::SetHelpString}



\hy-8{3065}{void SetHelpString(int \hy-8{3066}{ itemId}, char * \hy-8{3067}{helpString})}

Sets the help string associated with the menu item identifer.


\hy-10{3069}{wxMenuBar::SetLabel}



\hy-8{3070}{void SetLabel(int \hy-8{3071}{ itemId}, char * \hy-8{3072}{label})}

Sets the label of the given menu item. Use only after the menubar
has been associated with a frame with \hy-8{3073}{wxFrame::SetMenuBar}.


\hy-10{3075}{wxMenuBar::SetLabelTop}



\hy-8{3076}{void SetLabelTop(int \hy-8{3077}{ pos}, char * \hy-8{3078}{label})}

Sets the label of the given top-level menu. \hy-7{3079}{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{3080}{wxFrame::SetMenuBar}.


\hy-10{3084}{wxMessage::wxMessage}



\hy-8{3085}{void wxMessage(void)}

Constructor, used for deriving classes.

\hy-8{3086}{void wxMessage(wxPanel * \hy-8{3087}{panel}, char * \hy-8{3088}{message}, int  \hy-8{3089}{x = -1}, int  \hy-8{3090}{y = -1},

  long \hy-8{3091}{ style = 0}, char * \hy-8{3092}{name = ``message"})}

Creates and displays a simple text message. \hy-7{3093}{message} is the initial
value of the message.

The parameters \hy-7{3094}{x} and \hy-7{3095}{y} are used to specify an absolute
position, or a position after the previous panel item if omitted or
default.

The \hy-7{3096}{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{3098}{wxMessage::~wxMessage}



\hy-8{3099}{void ~wxMessage(void)}

Destroys the message.


\hy-10{3101}{wxMessage::Create}



\hy-8{3102}{Bool Create(wxPanel * \hy-8{3103}{panel}, char * \hy-8{3104}{message}, int  \hy-8{3105}{x = -1}, int  \hy-8{3106}{y = -1},

  long \hy-8{3107}{ style = 0}, char * \hy-8{3108}{name = ``message"})}

Creates the listbox for two-step construction. Derived classes
should call or replace this function. See \hy-13{3109}{wxMessage::wxMessage}
for further details.


\hy-10{3114}{wxMetaFile::wxMetaFile}



\hy-8{3115}{void wxMetaFile(char * \hy-8{3116}{filename = NULL})}

Constructor. If a filename is given, the Windows disk metafile is
read in. Check whether this was performed successfully by
using the \hy-13{3117}{wxMetaFile::Ok} member.


\hy-10{3119}{wxMetaFile::~wxMetaFile}



\hy-8{3120}{void ~wxMetaFile(void)}

Destructor.


\hy-10{3122}{wxMetaFile::Ok}



\hy-8{3123}{Bool Ok(void)}

Returns TRUE if the metafile is valid.


\hy-10{3125}{wxMetaFile::Play}



\hy-8{3126}{Bool Play(wxDC * \hy-8{3127}{dc})}

Plays the metafile into the given device context, returning
TRUE if successful.


\hy-10{3129}{wxMetaFile::SetClipboard}



\hy-8{3130}{Bool SetClipboard(int \hy-8{3131}{ width = 0}, int \hy-8{3132}{ 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{3133}{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{3134}{  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{3142}{wxMetaFileDC::wxMetaFileDC}



\hy-8{3143}{void wxMetaFileDC(char * \hy-8{3144}{filename = NULL})}

Constructor. If no filename is passed, the metafile is created
in memory.


\hy-10{3146}{wxMetaFileDC::~wxMetaFileDC}



\hy-8{3147}{void ~wxMetaFileDC(void)}

Destructor.


\hy-10{3149}{wxMetaFileDC::Close}



\hy-8{3150}{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{3155}{wxMouseEvent::controlDown}



\hy-8{3156}{Bool  controlDown}

TRUE if control key is pressed down.


\hy-10{3158}{wxMouseEvent::leftDown}



\hy-8{3159}{Bool  leftDown}

TRUE if the left mouse button is currently pressed down.


\hy-10{3161}{wxMouseEvent::middleDown}



\hy-8{3162}{Bool  middleDown}

TRUE if the middle mouse button is currently pressed down.


\hy-10{3164}{wxMouseEvent::rightDown}



\hy-8{3165}{Bool  rightDown}

TRUE if the right mouse button is currently pressed down.


\hy-10{3167}{wxMouseEvent::leftDown}



\hy-8{3168}{Bool  leftDown}

TRUE if the left mouse button is currently pressed down.


\hy-10{3170}{wxMouseEvent::shiftDown}



\hy-8{3171}{Bool  shiftDown}

TRUE if shift is pressed down.


\hy-10{3173}{wxMouseEvent::x}



\hy-8{3174}{float  x}

X-coordinate of the event.


\hy-10{3176}{wxMouseEvent::y}



\hy-8{3177}{float  y}

Y-coordinate of the event.


\hy-10{3179}{wxMouseEvent::wxMouseEvent}



\hy-8{3180}{void wxMouseEvent(WXTYPE \hy-8{3181}{ mouseEventType})}

Constructor. Valid event types are:


\hy-8{3182}{o}  \hy-8{3183}{wxEVENT_TYPE_ENTER_WINDOW}
\hy-8{3184}{o}  \hy-8{3185}{wxEVENT_TYPE_LEAVE_WINDOW}
\hy-8{3186}{o}  \hy-8{3187}{wxEVENT_TYPE_LEFT_DOWN}
\hy-8{3188}{o}  \hy-8{3189}{wxEVENT_TYPE_LEFT_UP}
\hy-8{3190}{o}  \hy-8{3191}{wxEVENT_TYPE_LEFT_DCLICK}
\hy-8{3192}{o}  \hy-8{3193}{wxEVENT_TYPE_MIDDLE_DOWN}
\hy-8{3194}{o}  \hy-8{3195}{wxEVENT_TYPE_MIDDLE_UP}
\hy-8{3196}{o}  \hy-8{3197}{wxEVENT_TYPE_MIDDLE_DCLICK}
\hy-8{3198}{o}  \hy-8{3199}{wxEVENT_TYPE_RIGHT_DOWN}
\hy-8{3200}{o}  \hy-8{3201}{wxEVENT_TYPE_RIGHT_UP}
\hy-8{3202}{o}  \hy-8{3203}{wxEVENT_TYPE_RIGHT_DCLICK}
\hy-8{3204}{o}  \hy-8{3205}{wxEVENT_TYPE_MOTION}



\hy-10{3207}{wxMouseEvent::Button}



\hy-8{3208}{Bool Button(int \hy-8{3209}{ button})}

Returns TRUE if the identified mouse button is changing state. Valid
values of \hy-7{3210}{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{3212}{wxMouseEvent::ButtonDClick}



\hy-8{3213}{Bool ButtonDClick(int \hy-8{3214}{ but = -1})}

If the argument is omitted, this returns TRUE if the event was a mouse
double click event. Otherwise the argument specifies which double click event
was generated (1, 2 or 3 for left, middle and right buttons respectively).

Under Windows 3.1, a double click always follows a down-up sequence. On
the other supported platforms (WIN32, Motif, but not XView) the double click
event occurs on its own. See also \hy-13{3215}{wxCanvas::AllowDoubleClick}.


\hy-10{3217}{wxMouseEvent::ButtonDown}



\hy-8{3218}{Bool ButtonDown(int \hy-8{3219}{ 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{3221}{wxMouseEvent::ButtonUp}



\hy-8{3222}{Bool ButtonUp(int \hy-8{3223}{ but = -1})}

If the argument is omitted, this returns TRUE if the event was a mouse
button up event. Otherwise the argument specifies which button-up event
was generated (1, 2 or 3 for left, middle and right buttons respectively).


\hy-10{3225}{wxMouseEvent::ControlDown}



\hy-8{3226}{Bool ControlDown(void)}

Returns TRUE if the control key was down at the time of the event.


\hy-10{3228}{wxMouseEvent::Dragging}



\hy-8{3229}{Bool Dragging(void)}

Returns TRUE if this was a dragging event (motion while a button is depressed).


\hy-10{3231}{wxMouseEvent::Entering}



\hy-8{3232}{Bool Entering(void)}

Returns TRUE if the mouse was entering the canvas (Windows 3.1, WIN32 and Motif).

See also \hy-13{3233}{wxMouseEvent::Leaving}.


\hy-10{3235}{wxMouseEvent::IsButton}



\hy-8{3236}{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{3237}{ButtonDown}).


\hy-10{3239}{wxMouseEvent::Leaving}



\hy-8{3240}{Bool Leaving(void)}

Returns TRUE if the mouse was leaving the canvas (Windows 3.1, WIN32 and Motif).

See also \hy-13{3241}{wxMouseEvent::Entering}.


\hy-10{3243}{wxMouseEvent::LeftDown}



\hy-8{3244}{Bool LeftDown(void)}

Returns TRUE if the left mouse button changed to down.


\hy-10{3246}{wxMouseEvent::LeftIsDown}



\hy-8{3247}{Bool LeftIsDown(void)}

Returns TRUE if the left mouse button is currently down, independent
of the current event type.


\hy-10{3249}{wxMouseEvent::LeftUp}



\hy-8{3250}{Bool LeftUp(void)}

Returns TRUE if the left mouse button changed to up.


\hy-10{3252}{wxMouseEvent::MiddleDown}



\hy-8{3253}{Bool MiddleDown(void)}

Returns TRUE if the middle mouse button changed to down.


\hy-10{3255}{wxMouseEvent::MiddleIsDown}



\hy-8{3256}{Bool MiddleIsDown(void)}

Returns TRUE if the middle mouse button is currently down, independent
of the current event type.


\hy-10{3258}{wxMouseEvent::MiddleUp}



\hy-8{3259}{Bool MiddleUp(void)}

Returns TRUE if the middle mouse button changed to up.


\hy-10{3261}{wxMouseEvent::Moving}



\hy-8{3262}{Bool Moving(void)}

Returns TRUE if this was a motion event (no buttons depressed).


\hy-10{3264}{wxMouseEvent::Position}



\hy-8{3265}{void Position(float * \hy-8{3266}{x}, float * \hy-8{3267}{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{3268}{wxDC::LogicalToDeviceX} and \hy-8{3269}{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{3270}{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{3272}{wxMouseEvent::RightDown}



\hy-8{3273}{Bool RightDown(void)}

Returns TRUE if the right mouse button changed to down.


\hy-10{3275}{wxMouseEvent::RightIsDown}



\hy-8{3276}{Bool RightIsDown(void)}

Returns TRUE if the right mouse button is currently down, independent
of the current event type.


\hy-10{3278}{wxMouseEvent::RightUp}



\hy-8{3279}{Bool RightUp(void)}

Returns TRUE if the right mouse button changed to up.



\hy-10{3281}{wxMouseEvent::ShiftDown}



\hy-8{3282}{Bool ShiftDown(void)}

Returns TRUE if the shift key was down at the time of the event.


\hy-10{3288}{wxMultiText::GetValue}



\hy-8{3289}{char * GetValue(void)}

\hy-8{3290}{void GetValue(char * \hy-8{3291}{buffer}, int \hy-8{3292}{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{3297}{wxNode::Data}



\hy-8{3298}{wxObject * Data(void)}

Retrieves the client data pointer associated with the node. This will
have to be cast to the correct type.


\hy-10{3300}{wxNode::Next}



\hy-8{3301}{wxNode * Next(void)}

Retrieves the next node (NULL if at end of list).


\hy-10{3303}{wxNode::Previous}



\hy-8{3304}{wxNode * Previous(void)}

Retrieves the previous node (NULL if at start of list).


\hy-10{3306}{wxNode::SetData}



\hy-8{3307}{void SetData(void)}

Sets the data associated with the node (usually the pointer will have been
set when the node was created).


\hy-10{3311}{wxObject::__type}



\hy-8{3312}{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{3313}{::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{3314}{wxTypeTree}.


\hy-10{3320}{wxPanel::wxPanel}



\hy-8{3321}{void wxPanel(void)}

Constructor, for deriving classes.

\hy-8{3322}{void wxPanel(wxFrame * \hy-8{3323}{parent}, int \hy-8{3324}{ x = -1}, int \hy-8{3325}{ y = -1}, int \hy-8{3326}{ width = -1}, int \hy-8{3327}{ height = -1},

  long \hy-8{3328}{ style = 0}, char * \hy-8{3329}{name = ``panel"})}

\hy-8{3330}{void wxPanel(wxPanel * \hy-8{3331}{parent}, int \hy-8{3332}{ x = -1}, int \hy-8{3333}{ y = -1}, int \hy-8{3334}{ width = -1}, int \hy-8{3335}{ height = -1},

  long \hy-8{3336}{ style = 0}, char * \hy-8{3337}{name = ``panel"})}

Constructor.

The parameters \hy-7{3338}{x}, \hy-7{3339}{y}, \hy-7{3340}{width} and \hy-7{3341}{height} can be
omitted on construction if the position and size will later be set (for
example by a application frame's \hy-8{3342}{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.


wxABSOLUTE_POSITIONING
    A hint to the windowing system not to try native
Windowing system layout (Motif only). \hy-7{3343}{This is now obsolete.}

wxBORDER
    Draws a thin border around the panel.

wxVSCROLL
    Gives the dialog box a vertical scrollbar (XView only).



The \hy-7{3344}{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{3346}{wxPanel::~wxPanel}



\hy-8{3347}{void ~wxPanel(void)}

Destructor.  Deletes any panel items before deleting the physical window.


\hy-10{3349}{wxPanel::Create}



\hy-8{3350}{void Create(wxFrame * \hy-8{3351}{parent}, int \hy-8{3352}{ x = -1}, int \hy-8{3353}{ y = -1}, int \hy-8{3354}{ width = -1}, int \hy-8{3355}{ height = -1},

  long \hy-8{3356}{ style = 0}, char * \hy-8{3357}{name = ``panel"})}

Used in two-step panel construction. See \hy-13{3358}{wxPanel::wxPanel}
for further details.


\hy-10{3360}{wxPanel::Fit}



\hy-8{3361}{void Fit(void)}

Resize the panel to just fit around the panel items. Also works for dialog boxes.


\hy-10{3363}{wxPanel::GetButtonFont}



\hy-8{3364}{wxFont * GetButtonFont(void)}

Get the current font for drawing panel item values.


\hy-10{3366}{wxPanel::GetCursor}



\hy-8{3367}{void GetCursor(int * \hy-8{3368}{x}, int * \hy-8{3369}{y})}

Gets the current panel `cursor' position, i.e. where the next panel item
will be placed.


\hy-10{3371}{wxPanel::GetDefaultItem}



\hy-8{3372}{wxButton * GetDefaultItem(void)}

Retrieves the default button, previously set with \hy-13{3373}{wxButton::SetDefault}.


\hy-10{3375}{wxPanel::GetHorizontalSpacing}



\hy-8{3376}{int GetHorizontalSpacing(void)}

Gets the horizontal spacing for placing items on a panel.


\hy-10{3378}{wxPanel::GetLabelFont}



\hy-8{3379}{wxFont * GetLabelFont(void)}

Get the current font for drawing panel item labels.


\hy-10{3381}{wxPanel::GetVerticalSpacing}



\hy-8{3382}{int GetVerticalSpacing(void)}

Gets the vertical spacing for placing items on a panel.


\hy-10{3384}{wxPanel::NewLine}



\hy-8{3385}{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{3387}{wxPanel::OnDefaultAction}



\hy-8{3388}{void OnDefaultAction(wxItem * \hy-8{3389}{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{3390}{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{3391}{void wxbPanel::OnDefaultAction(wxItem *initiatingItem)
{
  wxButton *but = GetDefaultItem();
  if (but)
  {
    wxCommandEvent event(wxEVENT_TYPE_BUTTON_COMMAND);
    but->Command(event);
  }
}
}

\hy-10{3393}{wxPanel::SetHorizontalSpacing}



\hy-8{3394}{void SetHorizontalSpacing(int \hy-8{3395}{ sp})}

Sets the horizontal spacing for placing items on a panel.


\hy-10{3397}{wxPanel::SetLabelPosition}



\hy-8{3398}{void SetLabelPosition(int \hy-8{3399}{ position})}

Determines the current method of placing labels on panel items: if \hy-7{3400}{
position} is \hy-14{3401}{wxHORIZONTAL}, labels are placed to the left of the
item value. If \hy-7{3402}{position} is \hy-14{3403}{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{3404}{wxText}, \hy-8{3405}{wxChoice}
and \hy-8{3406}{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{3408}{wxPanel::SetButtonFont}



\hy-8{3409}{void SetButtonFont(wxFont * \hy-8{3410}{font})}

Specify the font for drawing panel item values (not XView).


\hy-10{3412}{wxPanel::SetLabelFont}



\hy-8{3413}{void SetLabelFont(wxFont * \hy-8{3414}{font})}

Specify the font for drawing panel item labels (not XView).


\hy-10{3416}{wxPanel::SetVerticalSpacing}



\hy-8{3417}{void SetVerticalSpacing(int \hy-8{3418}{ sp})}

Sets the vertical spacing for placing items on a panel.


\hy-10{3420}{wxPanel::Tab}



\hy-8{3421}{void Tab(int \hy-8{3422}{ pixels})}

Tabs by the given number of pixels.


\hy-10{3427}{wxPathList::wxPathList}



\hy-8{3428}{void wxPathList(void)}

Constructor.


\hy-10{3430}{wxPathList::AddEnvList}



\hy-8{3431}{void AddEnvList(char * \hy-8{3432}{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{3434}{wxPathList::AddPath}



\hy-8{3435}{void AddPath(char * \hy-8{3436}{path})}

Adds the given directory to the path list.


\hy-10{3438}{wxPathList::FindValidPath}



\hy-8{3439}{char * FindValidPath(char * \hy-8{3440}{file})}

Searches for a full path for an existing file by appending \hy-7{3441}{file} to
successive members of the path list.  If the file exists, a temporary
pointer to the full path is returned.


\hy-10{3443}{wxPathList::Member}



\hy-8{3444}{Bool Member(char * \hy-8{3445}{file})}

TRUE if the path is in the path list (ignoring case).


\hy-10{3454}{wxPen::wxPen}



\hy-8{3455}{void wxPen(void)}

\hy-8{3456}{void wxPen(wxColour & \hy-8{3457}{colour}, int \hy-8{3458}{ width}, int \hy-8{3459}{ style})}

\hy-8{3460}{void wxPen(char * \hy-8{3461}{colour_name}, int \hy-8{3462}{ width}, int \hy-8{3463}{ 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{3464}{
wxColour} structure is found in the colour database.


\hy-10{3466}{wxPen::~wxPen}



\hy-8{3467}{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.

If you have to delete the pen (for example, you are creating a lot of
them), then call \hy-13{3468}{wxDC::SetPen} with a NULL argument
to ensure that the old pen is restored, and the current pen is selected
out of the device context.


\hy-10{3470}{wxPen::GetCap}



\hy-8{3471}{int GetCap(void)}

Returns the pen cap style, which may be one of \hy-8{3472}{wxCAP_ROUND}, \hy-8{3473}{wxCAP_PROJECTING} and
\hy-8{3474}{wxCAP_BUTT}. The default is \hy-8{3475}{wxCAP_ROUND}.


\hy-10{3477}{wxPen::GetColour}



\hy-8{3478}{wxColour& GetColour(void)}

Returns a reference to the pen colour.


\hy-10{3480}{wxPen::GetJoin}



\hy-8{3481}{int GetJoin(void)}

Returns the pen join style, which may be one of \hy-8{3482}{wxJOIN_BEVEL}, \hy-8{3483}{wxJOIN_ROUND} and
\hy-8{3484}{wxJOIN_MITER}. The default is \hy-8{3485}{wxJOIN_ROUND}.


\hy-10{3487}{wxPen::GetStipple}



\hy-8{3488}{wxBitmap * GetStipple(void)}

Gets the stipple bitmap.


\hy-10{3490}{wxPen::GetStyle}



\hy-8{3491}{int GetStyle(void)}

Returns the pen style.


\hy-10{3493}{wxPen::GetWidth}



\hy-8{3494}{int GetWidth(void)}

Returns the pen width.


\hy-10{3496}{wxPen::SetCap}



\hy-8{3497}{void SetCap(int \hy-8{3498}{cap_style})}

Sets the pen cap style, which may be one of \hy-8{3499}{wxCAP_ROUND}, \hy-8{3500}{wxCAP_PROJECTING} and
\hy-8{3501}{wxCAP_BUTT}. The default is \hy-8{3502}{wxCAP_ROUND}.


\hy-10{3504}{wxPen::SetColour}



\hy-8{3505}{void SetColour(wxColour & \hy-8{3506}{colour})}

\hy-8{3507}{void SetColour(char * \hy-8{3508}{colour_name})}

\hy-8{3509}{void SetColour(int \hy-8{3510}{ red}, int \hy-8{3511}{ green}, int \hy-8{3512}{ blue})}

The pen's colour is changed to the given colour.


\hy-10{3514}{wxPen::SetJoin}



\hy-8{3515}{void SetJoin(int \hy-8{3516}{join_style})}

Sets the pen join style, which may be one of \hy-8{3517}{wxJOIN_BEVEL}, \hy-8{3518}{wxJOIN_ROUND} and
\hy-8{3519}{wxJOIN_MITER}. The default is \hy-8{3520}{wxJOIN_ROUND}.


\hy-10{3522}{wxPen::SetStipple}



\hy-8{3523}{void SetStipple(wxBitmap * \hy-8{3524}{ stipple})}

Sets the bitmap for stippling.


\hy-10{3526}{wxPen::SetStyle}



\hy-8{3527}{void SetStyle(int \hy-8{3528}{ style})}

Set the pen style (wxSOLID or wxTRANSPARENT).


\hy-10{3530}{wxPen::SetWidth}



\hy-8{3531}{void SetWidth(int \hy-8{3532}{ width})}

Set the pen width.

\hy-10{3537}{wxPenList::wxPenList}



\hy-8{3538}{void wxPenList(void)}

Constructor.  The application should not construct its own pen list:
use the object pointer \hy-8{3539}{wxThePenList}.


\hy-10{3541}{wxPenList::AddPen}



\hy-8{3542}{void AddPen(wxPen * \hy-8{3543}{pen})}

Used by wxWindows to add a pen to the list, called in the pen constructor.


\hy-10{3545}{wxPenList::FindOrCreatePen}



\hy-8{3546}{wxPen * FindOrCreatePen(wxColour * \hy-8{3547}{colour}, int \hy-8{3548}{ width}, int \hy-8{3549}{ style})}

\hy-8{3550}{wxPen * FindOrCreatePen(char * \hy-8{3551}{colour_name}, int \hy-8{3552}{ width}, int \hy-8{3553}{ style})}

Finds a pen of the given specification, or creates one and adds it to the list.


\hy-10{3555}{wxPenList::RemovePen}



\hy-8{3556}{void RemovePen(wxPen * \hy-8{3557}{pen})}

Used by wxWindows to remove a pen from the list.


\hy-10{3565}{wxPoint::wxPoint}



\hy-8{3566}{void wxPoint(void)}

\hy-8{3567}{void wxPoint(float \hy-8{3568}{ x}, float \hy-8{3569}{ y})}

Create a point.

\hy-8{3570}{float  x}

\hy-8{3571}{float  y}

Members of the \hy-8{3572}{wxPoint} object.


\hy-10{3577}{wxPostScriptDC::wxPostScriptDC}



\hy-8{3578}{void wxPostScriptDC(char * \hy-8{3579}{output}, Bool  \hy-8{3580}{interactive = TRUE})}

Constructor. \hy-7{3581}{output} is an optional file for printing to, and if
\hy-7{3582}{interactive} is TRUE a dialog box will be displayed for adjusting
various parameters.

Use the \hy-7{3583}{Ok} member to test whether the constructor was successful
in creating a useable device context.

See \hy-13{3584}{Printer settings} for functions to set and
get PostScript printing settings.


\hy-10{3590}{wxPrinterDC::wxPrinterDC}



\hy-8{3591}{void wxPrinterDC(char * \hy-8{3592}{driver}, char * \hy-8{3593}{device}, char * \hy-8{3594}{output}, Bool  \hy-8{3595}{interactive = TRUE})}

Constructor.  With three NULLs, the default printer dialog is
displayed. \hy-7{3596}{device} indicates the type of printer and \hy-7{3597}{output}
is an optional file for printing to. The \hy-7{3598}{driver} parameter is
currently unused.  Use the \hy-7{3599}{Ok} member to test whether the
constructor was successful in creating a useable device context.


\hy-10{3603}{wxRadioBox::wxRadioBox}



\hy-8{3604}{void wxRadioBox(void)}

Constructor, for use by derived classes.

\hy-8{3605}{void wxRadioBox(wxPanel * \hy-8{3606}{parent}, wxFunction \hy-8{3607}{ func}, char * \hy-8{3608}{label},

  int \hy-8{3609}{ x = -1}, int \hy-8{3610}{ y = -1}, int \hy-8{3611}{ width = -1}, int \hy-8{3612}{ height = -1},

  int \hy-8{3613}{ n}, char * \hy-8{3614}{choices[]}, int \hy-8{3615}{ majorDim = 0}, long \hy-8{3616}{ style = 0}, char * \hy-8{3617}{name = ``radioBox"})}

\hy-8{3618}{void wxRadioBox(wxPanel * \hy-8{3619}{parent}, wxFunction \hy-8{3620}{ func}, char * \hy-8{3621}{label},

  int \hy-8{3622}{ x = -1}, int \hy-8{3623}{ y = -1}, int \hy-8{3624}{ width = -1}, int \hy-8{3625}{ height = -1},

  int \hy-8{3626}{ n}, wxBitmap * \hy-8{3627}{choices[]}, int \hy-8{3628}{ majorDim = 0}, long \hy-8{3629}{ style = 0}, char * \hy-8{3630}{name = ``radioBox"})}

Constructor, creating and showing a radiobox.

\hy-7{3631}{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{3632}{label} is non-NULL, it will be used to label the radiobox.

The parameters \hy-7{3633}{x} and \hy-7{3634}{y} are used to specify an absolute
position, or a position after the previous panel item if omitted or
default.

If \hy-7{3635}{width} or \hy-7{3636}{height} are omitted (or are less than zero), an
appropriate size will be used for the radiobox.

\hy-7{3637}{n} is the number of possible choices, and \hy-7{3638}{choices} is an
array of strings or bitmaps of size \hy-7{3639}{n}. wxWindows allocates its own memory
for these strings so the calling program must deallocate the array
itself.

\hy-7{3640}{majorDim} specifies the number of rows for a two-dimensional
radiobox.

\hy-7{3641}{style} specifies a bitwise-or list of styles (none so far).

The \hy-7{3642}{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{3644}{wxRadioBox::~wxRadioBox}



\hy-8{3645}{void ~wxRadioBox(void)}

Destructor, destroying the radiobox item.


\hy-10{3647}{wxRadioBox::Create}



\hy-8{3648}{Bool Create(wxPanel * \hy-8{3649}{parent}, wxFunction \hy-8{3650}{ func}, char * \hy-8{3651}{label}, 

  int \hy-8{3652}{ x = -1}, int \hy-8{3653}{ y = -1}, int \hy-8{3654}{ width = -1}, int \hy-8{3655}{ height = -1},

  int \hy-8{3656}{ n}, char * \hy-8{3657}{choices[]}, int \hy-8{3658}{ majorDim = 0}, long \hy-8{3659}{ style = 0}, char * \hy-8{3660}{name = ``radioBox"})}

\hy-8{3661}{Bool Create(wxPanel * \hy-8{3662}{parent}, wxFunction \hy-8{3663}{ func}, char * \hy-8{3664}{label}, 

  int \hy-8{3665}{ x = -1}, int \hy-8{3666}{ y = -1}, int \hy-8{3667}{ width = -1}, int \hy-8{3668}{ height = -1},

  int \hy-8{3669}{ n}, wxBitmap * \hy-8{3670}{choices[]}, int \hy-8{3671}{ majorDim = 0}, long \hy-8{3672}{ style = 0}, char * \hy-8{3673}{name = ``radioBox"})}

Creates the choice for two-step construction. Derived classes
should call or replace this function. See \hy-13{3674}{wxRadioBox::wxRadioBox}
for further details.


\hy-10{3676}{wxRadioBox::Enable}



\hy-8{3677}{void Enable(Bool \hy-8{3678}{ enable})}

Enables or disables the entire radiobox.

\hy-8{3679}{void Enable(int \hy-8{3680}{ n}, Bool \hy-8{3681}{ enable})}

Enables or disables an individual button in the radiobox (does nothing
in XView).


\hy-10{3683}{wxRadioBox::FindString}



\hy-8{3684}{int FindString(char * \hy-8{3685}{s})}

Finds a choice matching the given string, returning the position if found, or
-1 if not found.


\hy-10{3687}{wxRadioBox::GetSelection}



\hy-8{3688}{int GetSelection(void)}

Gets the id (position) of the selected string.


\hy-10{3690}{wxRadioBox::GetStringSelection}



\hy-8{3691}{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{3693}{wxRadioBox::Number}



\hy-8{3694}{int Number(void)}

Returns the number of choices in the radiobox.


\hy-10{3696}{wxRadioBox::SetSelection}



\hy-8{3697}{void SetSelection(int \hy-8{3698}{ n})}

Sets the choice by passing the desired string position.


\hy-10{3700}{wxRadioBox::SetStringSelection}



\hy-8{3701}{void SetStringSelection(char * \hy-8{3702}{ s})}

Sets the choice by passing the desired string.


\hy-10{3704}{wxRadioBox::Show}



\hy-8{3705}{void Show(int  \hy-8{3706}{item}, Bool \hy-8{3707}{ show})}

Shows or hides individual radio box controls.


\hy-10{3709}{wxRadioBox::GetString}



\hy-8{3710}{char * GetString(int \hy-8{3711}{ n})}

Returns a temporary pointer to the string at position \hy-7{3712}{n}.


\hy-10{3717}{wxServer::wxServer}



\hy-8{3718}{void wxServer(void)}

Constructs a server object.


\hy-10{3720}{wxServer::Create}



\hy-8{3721}{Bool Create(char * \hy-8{3722}{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{3724}{wxServer::OnAcceptConnection}



\hy-8{3725}{wxConnection * OnAcceptConnection(char * \hy-8{3726}{topic})}

When a client calls \hy-8{3727}{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{3731}{wxSlider::wxSlider}



\hy-8{3732}{void wxSlider(wxPanel * \hy-8{3733}{parent}, wxFunction \hy-8{3734}{ func}, char * \hy-8{3735}{label},

  int \hy-8{3736}{ value}, int \hy-8{3737}{ min_value}, int \hy-8{3738}{ max_value}, int \hy-8{3739}{ width},

  int \hy-8{3740}{ x = -1}, int \hy-8{3741}{ y = -1}, long \hy-8{3742}{ style = 0}, char * \hy-8{3743}{name = ``slider"})}

Constructor, creating and showing a horizontal slider.

\hy-7{3744}{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{3745}{label} is non-NULL, it will be used to label the slider.

The parameters \hy-7{3746}{x} and \hy-7{3747}{y} are used to specify an absolute
position, or a position after the previous panel item if omitted or
default.

The \hy-7{3748}{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{3749}{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{3751}{wxSlider::~wxSlider}



\hy-8{3752}{void ~wxSlider(void)}

Destructor, destroying the slider.


\hy-10{3754}{wxSlider::Create}



\hy-8{3755}{void Create(wxPanel * \hy-8{3756}{parent}, wxFunction \hy-8{3757}{ func}, char * \hy-8{3758}{label},

  int \hy-8{3759}{ value}, int \hy-8{3760}{ min_value}, int \hy-8{3761}{ max_value}, int \hy-8{3762}{ width},

  int \hy-8{3763}{ x = -1}, int \hy-8{3764}{ y = -1}, long \hy-8{3765}{ style = 0}, char * \hy-8{3766}{name = ``slider"})}

Used for two-step slider construction. See \hy-13{3767}{wxSlider::wxSlider}
for further details.


\hy-10{3769}{wxSlider::GetValue}



\hy-8{3770}{int GetValue(void)}

Gets the current slider value.


\hy-10{3772}{wxSlider::SetValue}



\hy-8{3773}{void SetValue(int \hy-8{3774}{ value})}

Sets the value (and displayed position) of the slider).


\hy-10{3779}{wxStringList::wxStringList}



\hy-8{3780}{void wxStringList(void)}

Constructor.

\hy-8{3781}{void wxStringList(char * \hy-8{3782}{first}, ...)}

Constructor, taking NULL-terminated string argument list. wxStringList
allocates memory for the strings.


\hy-10{3784}{wxStringList::~wxStringList}



\hy-8{3785}{void ~wxStringList(void)}

Deletes string list, deallocating strings.


\hy-10{3787}{wxStringList::Add}



\hy-8{3788}{void Add(char * \hy-8{3789}{s})}

Adds string to list, allocating memory.


\hy-10{3791}{wxStringList::Delete}



\hy-8{3792}{void Delete(char * \hy-8{3793}{s})}

Searches for string and deletes from list, deallocating memory.


\hy-10{3795}{wxStringList::ListToArray}



\hy-8{3796}{char ** ListToArray(Bool \hy-8{3797}{ new_copies = FALSE})}

Converts the list to an array of strings, only allocating new memory if
\hy-8{3798}{new_copies} is TRUE.


\hy-10{3800}{wxStringList::Member}



\hy-8{3801}{Bool Member(char * \hy-8{3802}{s})}

Returns TRUE if \hy-8{3803}{s} is a member of the list (tested using \hy-8{3804}{strcmp}).


\hy-10{3806}{wxStringList::Sort}



\hy-8{3807}{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{3814}{wxText::wxText}



\hy-8{3815}{void wxText(void)}

Constructor, for deriving classes.

\hy-8{3816}{void wxText(wxPanel * \hy-8{3817}{parent}, wxFunction \hy-8{3818}{ func}, char * \hy-8{3819}{label},

  char * \hy-8{3820}{value = ``"}, int \hy-8{3821}{ x = -1}, int \hy-8{3822}{ y = -1}, int \hy-8{3823}{ width = -1}, int \hy-8{3824}{ height = -1},

  long \hy-8{3825}{ style = 0}, char * \hy-8{3826}{name = ``text"})}

Constructor, creating and showing a text item with the given string
value. 

\hy-7{3827}{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{3828}{label} is non-NULL, it will be used to label the text item.

The parameters \hy-7{3829}{x} and \hy-7{3830}{y} are used to specify an absolute
position, or a position after the previous panel item if omitted or
default.

If \hy-7{3831}{width} or \hy-7{3832}{height} are omitted (or are less than zero), an
appropriate size will be used for the item.

if \hy-7{3833}{style} is wxPROCESS_ENTER, the callback function will
receive the message wxEVENT_TYPE_TEXT_ENTER_COMMAND. Note
that this will break tab traversal for this panel item under
Windows.

The \hy-7{3834}{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{3836}{wxText::~wxText}



\hy-8{3837}{void ~wxText(void)}

Destructor, destroying the text item.


\hy-10{3839}{wxText::Create}



\hy-8{3840}{Bool Create(wxPanel * \hy-8{3841}{parent}, wxFunction \hy-8{3842}{ func}, char * \hy-8{3843}{label},

  char * \hy-8{3844}{value = ``"}, int \hy-8{3845}{ x = -1}, int \hy-8{3846}{ y = -1}, int \hy-8{3847}{ width = -1}, int \hy-8{3848}{ height = -1},

  long \hy-8{3849}{ style = 0}, char * \hy-8{3850}{name = ``text"})}

Creates the text item for two-step construction. Derived classes
should call or replace this function. See \hy-13{3851}{wxText::wxText}
for further details.


\hy-10{3853}{wxText::GetValue}



\hy-8{3854}{char * GetValue(void)}

Gets a pointer to the current value. Copy this for long-term use.


\hy-10{3856}{wxText::SetValue}



\hy-8{3857}{void SetValue(char * \hy-8{3858}{ value})}

Sets the text. \hy-7{3859}{value} must be deallocated by the calling program.


\hy-10{3864}{wxTextWindow::wxTextWindow}



\hy-8{3865}{void wxTextWindow(void)}

Constructor, for deriving classes.

\hy-8{3866}{void wxTextWindow(wxFrame * \hy-8{3867}{parent}, int \hy-8{3868}{ x = -1}, int \hy-8{3869}{ y = -1},

  int \hy-8{3870}{ width = -1}, int \hy-8{3871}{ height = -1}, long \hy-8{3872}{ style = 0}, char * \hy-8{3873}{name = ``textWindow"})}

Constructor.

The parameters \hy-7{3874}{x}, \hy-7{3875}{y}, \hy-7{3876}{width} and \hy-7{3877}{height} can be
omitted on construction if the position and size will later be set (for
example by a application frame's \hy-8{3878}{OnSize} callback, or if there is
only one subwindow for the frame, in which case the subwindow fills the
frame).

\hy-7{3879}{style} is a bit list of some of the following:


wxBORDER
    Use this style to draw a thin border in Windows 3 (non-native
implementation only).

wxNATIVE_IMPL
    Use this style to allow editing under Windows 3.1, albeit
with a 64K limitation.

wxREADONLY
    Use this style to disable editing.



The \hy-7{3880}{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{3882}{wxTextWindow::~wxTextWindow}



\hy-8{3883}{void ~wxTextWindow(void)}

Destructor.  Deletes any stored text before deleting the physical window.


\hy-10{3885}{wxTextWindow::Clear}



\hy-8{3886}{void Clear(void)}

Clears the window and deletes the stored text.


\hy-10{3888}{wxTextWindow::Create}



\hy-8{3889}{Bool Create(wxFrame * \hy-8{3890}{parent}, int \hy-8{3891}{ x = -1}, int \hy-8{3892}{ y = -1},

  int \hy-8{3893}{ width = -1}, int \hy-8{3894}{ height = -1}, long \hy-8{3895}{ style = 0}, char * \hy-8{3896}{name = ``textWindow"})}

Creates the text item for two-step construction. Derived classes
should call or replace this function. See \hy-13{3897}{wxTextWindow::wxTextWindow}
for further details.


\hy-10{3899}{wxTextWindow::Copy}



\hy-8{3900}{Bool Copy(void)}

Copies the selected text onto the clipboard.

Motif and Windows only.


\hy-10{3902}{wxTextWindow::Cut}



\hy-8{3903}{Bool Cut(void)}

Copies the selected text onto the clipboard, and then
deletes the text from the window.

Motif and Windows only.


\hy-10{3905}{wxTextWindow::DiscardEdits}



\hy-8{3906}{void DiscardEdits(void)}

Clears the window and deletes the stored text (same as \hy-8{3907}{Clear}).


\hy-10{3909}{wxTextWindow::GetContents}



\hy-8{3910}{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{3912}{wxTextWindow::GetInsertionPoint}



\hy-8{3913}{long GetInsertionPoint(void)}

Gets the current insertion point.

Motif and XView only.


\hy-10{3915}{wxTextWindow::GetLastPosition}



\hy-8{3916}{long GetLastPosition(void)}

Gets the position representing the end of the text window contents.

Motif and XView only.


\hy-10{3918}{wxTextWindow::GetLineLength}



\hy-8{3919}{int GetLineLength(long \hy-8{3920}{ lineNo})}

Gets the length of the specified line (starting from zero).


\hy-10{3922}{wxTextWindow::GetLineText}



\hy-8{3923}{int GetLineText(long \hy-8{3924}{ lineNo}, char * \hy-8{3925}{buffer})}

Puts the contents of the specified line (starting from zero) into
the given buffer, returning the number of characters copied.


\hy-10{3927}{wxTextWindow::GetNumberOfLines}



\hy-8{3928}{int GetNumberOfLines(void)}

Gets the number of lines in the text window buffer.


\hy-10{3930}{wxTextWindow::SetSelection}



\hy-8{3931}{void Highlight(long  \hy-8{3932}{from}, long  \hy-8{3933}{to})}

Selects the text between \hy-7{3934}{from} and \hy-7{3935}{to}.


\hy-10{3937}{wxTextWindow::LoadFile}



\hy-8{3938}{Bool LoadFile(char * \hy-8{3939}{ file})}

Loads and displays the named file, if it exists. Success is indicated by a return
value of TRUE.


\hy-10{3941}{wxTextWindow::Modified}



\hy-8{3942}{Bool Modified(void)}

Returns TRUE if the text has been modified.


\hy-10{3944}{wxTextWindow::Paste}



\hy-8{3945}{Bool Paste(void)}

Pastes text from the clipboard into the text window.

Motif and Windows only.


\hy-10{3947}{wxTextWindow::PositionToXY}



\hy-8{3948}{long PositionToXY(long  \hy-8{3949}{pos}, long * \hy-8{3950}{x}, long * \hy-8{3951}{y})}

Converts given character and line position to a position.

Motif and Windows only.


\hy-10{3953}{wxTextWindow::Remove}



\hy-8{3954}{void Remove(long  \hy-8{3955}{from}, long  \hy-8{3956}{to})}

Removes the text between \hy-7{3957}{from} and \hy-7{3958}{to}.


\hy-10{3960}{wxTextWindow::Replace}



\hy-8{3961}{void Replace(long  \hy-8{3962}{from}, long  \hy-8{3963}{to}, char * \hy-8{3964}{value})}

Replaces the text between \hy-7{3965}{from} and \hy-7{3966}{to} with \hy-7{3967}{value}.


\hy-10{3969}{wxTextWindow::SaveFile}



\hy-8{3970}{Bool SaveFile(char * \hy-8{3971}{ file})}

Saves the text in the named file. Success is indicated by a return
value of TRUE.


\hy-10{3973}{wxTextWindow::SetFont}



\hy-8{3974}{void SetFont(wxFont * \hy-8{3975}{font})}

Sets the font for the text window.

Windows and Motif only.


\hy-10{3977}{wxTextWindow::SetEditable}



\hy-8{3978}{void SetEditable(Bool \hy-8{3979}{ editable})}

Determines whether the text window is user-editable


\hy-10{3981}{wxTextWindow::SetInsertionPoint}



\hy-8{3982}{void SetInsertionPoint(long \hy-8{3983}{ pos})}

Sets the current insertion point to \hy-7{3984}{pos}.


\hy-10{3986}{wxTextWindow::SetInsertionPointEnd}



\hy-8{3987}{void SetInsertionPointEnd(void)}

Sets the current insertion point to the end of the text.

Motif and XView only.


\hy-10{3989}{wxTextWindow::ShowPosition}



\hy-8{3990}{void ShowPosition(long \hy-8{3991}{ pos})}

Makes the line containing the given position visible.

Motif and XView only.


\hy-10{3993}{wxTextWindow::WriteText}



\hy-8{3994}{void WriteText(char * \hy-8{3995}{ 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{3996}{<<} for more convenient ways of writing to the
window.


\hy-10{3998}{wxTextWindow::XYToPosition}



\hy-8{3999}{long XYToPosition(long \hy-8{4000}{ x}, long \hy-8{4001}{ y})}

Converts given character and line position to a position.


\hy-10{4003}{wxTextWindow::<<}



\hy-8{4004}{wxTextWindow& <<(char * \hy-8{4005}{s})}

\hy-8{4006}{wxTextWindow& <<(int \hy-8{4007}{ i})}

\hy-8{4008}{wxTextWindow& <<(long \hy-8{4009}{ i})}

\hy-8{4010}{wxTextWindow& <<(float \hy-8{4011}{ f})}

\hy-8{4012}{wxTextWindow& <<(double \hy-8{4013}{ d})}

\hy-8{4014}{wxTextWindow& <<(char \hy-8{4015}{ c})}

Operator definitions for writing to a text window, for example:

\hy-14{4016}{  wxTextWindow *wnd = new wxTextWindow(my_frame);

  (*wnd) << "Welcome to text window number " << 1 << ".\n";
}

\hy-10{4025}{wxTimer::wxTimer}



\hy-8{4026}{void wxTimer(void)}

Constructor.


\hy-10{4028}{wxTimer::~wxTimer}



\hy-8{4029}{void ~wxTimer(void)}

Destructor. Stops the timer if activated.


\hy-10{4031}{wxTimer::Interval}



\hy-8{4032}{int Interval(void)}

Returns the current interval for the timer.


\hy-10{4034}{wxTimer::Notify}



\hy-8{4035}{void Notify(void)}

This member should be overridden by the user. It is called on timeout.


\hy-10{4037}{wxTimer::Start}



\hy-8{4038}{Bool Start(int \hy-8{4039}{ milliseconds = -1})}

(Re)starts the timer. If \hy-7{4040}{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{4042}{wxTimer::Stop}



\hy-8{4043}{void Stop(void)}

Stops the timer.


\hy-10{4100}{wxTypeTree::wxTypeTree}



\hy-8{4101}{void wxTypeTree(void)}

Constructor. Used by wxWindows only, since there only one instance of this
class.


\hy-10{4103}{wxTypeTree::AddType}



\hy-8{4104}{void AddType(WXTYPE \hy-8{4105}{ newType}, WXTYPE \hy-8{4106}{ parentType}, char * \hy-8{4107}{name})}

Adds a type to the hierarchy. \hy-7{4108}{newType} is the type being registered,
\hy-7{4109}{parentType} is the parent type, and \hy-7{4110}{name} is an identifier
(which can used in error messages). The top (root) type is wxTYPE_ANY.

Example:

\hy-14{4111}{wxAllTypes.AddType(wxTYPE_WINDOW, wxTYPE_ANY,     "window");
wxAllTypes.AddType(wxTYPE_PANEL,  wxTYPE_WINDOW,  "panel");
wxAllTypes.AddType(wxTYPE_CANVAS, wxTYPE_WINDOW,  "canvas");
}

\hy-10{4113}{wxTypeTree::GetName}



\hy-8{4114}{char * GetName(WXTYPE  \hy-8{4115}{typ})}

Gets a temporary pointer to the name of the given type, or NULL if the type
is not found.


\hy-10{4119}{wxWindow::wxWindow}



\hy-8{4120}{void wxWindow(void)}

Constructor.


\hy-10{4122}{wxWindow::~wxWindow}



\hy-8{4123}{void ~wxWindow(void)}

Destructor. Deletes all subwindows, then deletes itself.


\hy-10{4125}{wxWindow::AddChild}



\hy-8{4126}{void AddChild(wxWindow * \hy-8{4127}{child})}

Adds a child window.  This is called automatically by window creation
functions so should not be required by the application programmer.


\hy-10{4129}{wxWindow::CaptureMouse}



\hy-8{4130}{void CaptureMouse(void)}

Directs all mouse input to this window. Call \hy-8{4131}{ReleaseMouse} to
release the capture.


\hy-10{4133}{wxWindow::Center}



\hy-8{4134}{void Center(int \hy-8{4135}{ direction})}

See \hy-13{4136}{Centre}.


\hy-10{4138}{wxWindow::Centre}



\hy-8{4139}{void Centre(int \hy-8{4140}{ direction})}

Centres the window. The parameter may be \hy-14{4141}{wxHORIZONTAL}, \hy-14{4142}{wxVERTICAL}
or \hy-14{4143}{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{4145}{wxWindow::ClientToScreen}



\hy-8{4146}{void ClientToScreen(int * \hy-8{4147}{x}, int * \hy-8{4148}{y})}

Converts the values pointed to by \hy-7{4149}{x} and \hy-7{4150}{y} to screen
coordinates from coordinates relative to this window.


\hy-10{4152}{wxWindow::DestroyChildren}



\hy-8{4153}{void DestroyChildren(void)}

Destroys all children of a window.  Called automatically by the destructor.


\hy-10{4155}{wxWindow::DragAcceptFiles}



\hy-8{4156}{void DragAcceptFiles(void)}

Under Windows, makes the window eligible for a \hy-8{4157}{OnDropFiles} event.


\hy-10{4159}{wxWindow::Enable}



\hy-8{4160}{void Enable(Bool \hy-8{4161}{ enable})}

Enable or disable the window, so input has no effect.


\hy-10{4163}{wxWindow::GetCharHeight}



\hy-8{4164}{float GetCharHeight(void)}

Get the character height for this window.


\hy-10{4166}{wxWindow::GetCharWidth}



\hy-8{4167}{float GetCharWidth(void)}

Get the average character width for this window.


\hy-10{4169}{wxWindow::GetChildren}



\hy-8{4170}{wxList * GetChildren(void)}

Returns a temporary pointer to a list of the window's children.


\hy-10{4172}{wxWindow::GetClientData}



\hy-8{4173}{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{4175}{wxWindow::GetClientSize}



\hy-8{4176}{void GetClientSize(int * \hy-8{4177}{width}, int * \hy-8{4178}{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{4180}{wxWindow::GetGrandParent}



\hy-8{4181}{wxWindow * GetGrandParent(void)}

Returns the grandparent of a window, if any.


\hy-10{4183}{wxWindow::GetHandle}



\hy-8{4184}{char * GetHandle(void)}

Gets the platform-specific handle of the physical window.


\hy-10{4186}{wxWindow::GetPosition}



\hy-8{4187}{void GetPosition(int * \hy-8{4188}{x}, int * \hy-8{4189}{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{4191}{wxWindow::GetLabel}



\hy-8{4192}{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{4194}{wxWindow::GetParent}



\hy-8{4195}{wxWindow * GetParent(void)}

Returns the parent of a window, if any.


\hy-10{4197}{wxWindow::GetSize}



\hy-8{4198}{void GetSize(int * \hy-8{4199}{width}, int * \hy-8{4200}{height})}

This gets the size of the entire window in pixels.


\hy-10{4202}{wxWindow::GetTextExtent}



\hy-8{4203}{void GetTextExtent(char * \hy-8{4204}{string}, int * \hy-8{4205}{x}, int * \hy-8{4206}{y})}

Gets the width and height of the string as it would be drawn on the window with the
currently selected font.


\hy-10{4208}{wxWindow::OnActivate}



\hy-8{4209}{void OnActivate(Bool \hy-8{4210}{ active})}

Called when a window is activated or deactivated (Windows 3
only). If the window is being activated, \hy-7{4211}{active} is TRUE, else it
is FALSE.


\hy-10{4213}{wxWindow::OnChar}



\hy-8{4214}{void OnChar(wxKeyEvent& \hy-8{4215}{ ch})}

Sent to the window when the user has pressed a key. See \hy-13{4216}{wxKeyEvent} for
details.

For a list of the wxWindows virtual key codes, see the include file \hy-14{4217}{base/common.h}.
Note that the ASCII values do not have explicit key codes: they are passed as ASCII
values.

See also \hy-13{4218}{wxWindow::OnEvent} for mouse event notification. \hy-8{4219}{OnChar} is
currently applicable to canvas subwindows only.


\hy-10{4221}{wxWindow::OnDropFiles}



\hy-8{4222}{void OnDropFiles(int \hy-8{4223}{ n}, char * \hy-8{4224}{files[]}, int \hy-8{4225}{ x}, int \hy-8{4226}{ y})}

Under Windows, called when files have been dragged from the file manager to the window.
\hy-7{4227}{files} is an array of \hy-7{4228}{n} strings, and \hy-7{4229}{x} and \hy-7{4230}{y} give the mouse position
where the drop occurred. The window must have previously been enabled for dropping by calling
\hy-13{4231}{wxWindow::DragAcceptFiles}.


\hy-10{4233}{wxWindow::OnEvent}



\hy-8{4234}{void OnEvent(wxMouseEvent& \hy-8{4235}{ 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{4236}{wxWindow::OnChar} for character
events, and also \hy-13{4237}{wxMouseEvent} for how to access event information.


\hy-10{4239}{wxWindow::OnKillFocus}



\hy-8{4240}{void OnKillFocus(void)}

Called when a window's focus is being killed.


\hy-10{4242}{wxWindow::OnPaint}



\hy-8{4243}{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{4245}{wxWindow::PopupMenu}



\hy-8{4246}{Bool PopupMenu(wxMenu * \hy-8{4247}{menu}, float  \hy-8{4248}{x}, float  \hy-8{4249}{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{4250}{wxMenu}.

\hy-8{4251}{IMPORTANT NOTE:} under Motif, there is sometimes
a problem with popping up a menu for second and subsequent
times. It is not yet known what causes this problem and
under what circumstances. If it happens in your application,
please use the function \hy-7{4252}{FakePopupMenu} under Motif. For
example:

\hy-14{4253}{#ifdef wx_motif
  FakePopupMenu(menu, x, y);
#else
  PopupMenu(menu, x, y);
#endif
}
\hy-7{4254}{FakePopupMenu} will show a choice dialog instead
of a popup menu; note that it only works with single-level
menus, and ignores submenus.


\hy-10{4256}{wxWindow::OnSetFocus}



\hy-8{4257}{void OnSetFocus(void)}

Called when a window's focus is being set.


\hy-10{4259}{wxWindow::OnSize}



\hy-8{4260}{void OnSize(int \hy-8{4261}{ x}, int \hy-8{4262}{ 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{4263}{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{4265}{wxWindow::Refresh}



\hy-8{4266}{void Refresh(void)}

Repaint the window (Motif and XView only).


\hy-10{4268}{wxWindow::ReleaseMouse}



\hy-8{4269}{void ReleaseMouse(void)}

Releases mouse input captured with \hy-8{4270}{CaptureMouse}.


\hy-10{4272}{wxWindow::ScreenToClient}



\hy-8{4273}{void ScreenToClient(int * \hy-8{4274}{x}, int * \hy-8{4275}{y})}

Converts the values pointed to by \hy-7{4276}{x} and \hy-7{4277}{y} to window
coordinates from screen coordinates.


\hy-10{4279}{wxWindow::SetFocus}



\hy-8{4280}{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{4281}{wxText} item and derived items.


\hy-10{4283}{wxWindow::SetSize}



\hy-8{4284}{void SetSize(int \hy-8{4285}{ x}, int \hy-8{4286}{ y}, int \hy-8{4287}{ width}, int \hy-8{4288}{ height})}

This sets the size of the entire window in pixels.


\hy-10{4290}{wxWindow::SetClientData}



\hy-8{4291}{void SetClientData(char * \hy-8{4292}{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{4294}{wxWindow::SetClientSize}



\hy-8{4295}{void SetClientSize(int \hy-8{4296}{ x}, int \hy-8{4297}{ y}, int \hy-8{4298}{ width}, int \hy-8{4299}{ 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{4300}{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{4302}{wxWindow::SetColourMap}



\hy-8{4303}{void SetColourMap(wxColourMap * \hy-8{4304}{colourMap})}

Assigns the given colourmap to the window.

See \hy-13{4305}{wxColourMap} for further details.


\hy-10{4307}{wxWindow::SetCursor}



\hy-8{4308}{wxCursor * SetCursor(wxCursor * \hy-8{4309}{cursor})}

Sets the window's cursor, returning the previous cursor (if any). This
function applies to all subwindows.

See also \hy-13{4310}{::wxSetCursor}, \hy-13{4311}{wxCursor}.


\hy-10{4313}{wxWindow::SetTitle}



\hy-8{4314}{void SetTitle(char * \hy-8{4315}{title})}

Sets the window's title, allocating its own string storage. Currently
applicable only to frames.


\hy-10{4317}{wxWindow::Show}



\hy-8{4318}{void Show(Bool \hy-8{4319}{ show})}

If \hy-7{4320}{show} is TRUE, displays the window and brings it to the front.  Otherwise,
hides the window.




\hy-10{4325}{::DirExists}



\hy-8{4326}{Bool DirExists(char * \hy-8{4327}{dirname})}

Returns TRUE if the directory exists.


\hy-10{4329}{::Dos2UnixFilename}



\hy-8{4330}{void Dos2UnixFilename(char * \hy-8{4331}{s})}

Converts a DOS to a UNIX filename by replacing backslashes with forward
slashes.


\hy-10{4333}{::FileExists}



\hy-8{4334}{Bool FileExists(char * \hy-8{4335}{filename})}

Returns TRUE if the file exists.


\hy-10{4337}{::FileNameFromPath}



\hy-8{4338}{char * FileNameFromPath(char * \hy-8{4339}{path})}

Returns a temporary pointer to the filename for a full path.
Copy this pointer for long-term use.


\hy-10{4341}{::IsAbsolutePath}



\hy-8{4342}{Bool IsAbsolutePath(char * \hy-8{4343}{filename})}

Returns TRUE if the argument is an absolute filename, i.e. with a slash
or drive name at the beginning.


\hy-10{4345}{::PathOnly}



\hy-8{4346}{char * PathOnly(char * \hy-8{4347}{path})}

Returns a temporary pointer to the directory part of the filename. Copy this
pointer for long-term use.


\hy-10{4349}{::Unix2DosFilename}



\hy-8{4350}{void Unix2DosFilename(char * \hy-8{4351}{s})}

Converts a UNIX to a DOS filename by replacing forward
slashes with backslashes.


\hy-10{4353}{::wxConcatFiles}



\hy-8{4354}{Bool wxConcatFiles(char * \hy-8{4355}{file1}, char * \hy-8{4356}{file2},
char * \hy-8{4357}{file3})}

Concatenates \hy-7{4358}{file1} and \hy-7{4359}{file2} to \hy-7{4360}{file3}, returning
TRUE if successful.


\hy-10{4362}{::wxCopyFile}



\hy-8{4363}{Bool wxCopyFile(char * \hy-8{4364}{file1}, char * \hy-8{4365}{file2})}

Copies \hy-7{4366}{file1} to \hy-7{4367}{file2}, returning TRUE if successful.


\hy-10{4369}{::wxGetHostName}



\hy-8{4370}{Bool wxGetHostName(char * \hy-8{4371}{buf}, int  \hy-8{4372}{sz})}

Copies the current host machine's name into the supplied buffer.

Under Windows or NT, this function first looks in the environment
variable SYSTEM_NAME; if this is not found, the entry \hy-8{4373}{HostName}
in the \hy-8{4374}{wxWindows} section of the WIN.INI file is tried.

Returns TRUE if successful, FALSE otherwise.


\hy-10{4376}{::wxGetEmailAddress}



\hy-8{4377}{Bool wxGetEmailAddress(char * \hy-8{4378}{buf}, int  \hy-8{4379}{sz})}

Copies the user's email address into the supplied buffer, by
concatenating the values returned by \hy-13{4380}{wxGetHostName}
and \hy-13{4381}{wxGetUserId}.

Returns TRUE if successful, FALSE otherwise.


\hy-10{4383}{::wxGetUserId}



\hy-8{4384}{Bool wxGetUserId(char * \hy-8{4385}{buf}, int  \hy-8{4386}{sz})}

Copies the current user id into the supplied buffer.

Under Windows or NT, this function first looks in the environment
variables USER and LOGNAME; if neither of these is found, the entry \hy-8{4387}{UserId}
in the \hy-8{4388}{wxWindows} section of the WIN.INI file is tried.

Returns TRUE if successful, FALSE otherwise.


\hy-10{4390}{::wxGetUserName}



\hy-8{4391}{Bool wxGetUserName(char * \hy-8{4392}{buf}, int  \hy-8{4393}{sz})}

Copies the current user name into the supplied buffer.

Under Windows or NT, this function looks for the entry \hy-8{4394}{UserName}
in the \hy-8{4395}{wxWindows} section of the WIN.INI file. If PenWindows
is running, the entry \hy-8{4396}{Current} in the section \hy-8{4397}{User} of
the PENWIN.INI file is used.

Returns TRUE if successful, FALSE otherwise.


\hy-10{4399}{::wxGetWorkingDirectory}



\hy-8{4400}{char * wxGetWorkingDirectory(char * \hy-8{4401}{buf=NULL}, int  \hy-8{4402}{sz=1000})}

Copies the current working directory into the buffer if supplied, or
copies the working directory into new storage if the buffer is NULL.

\hy-7{4403}{sz} is the size of the buffer if supplied.


\hy-10{4405}{::wxGetTempFileName}



\hy-8{4406}{char * wxGetTempFileName(char * \hy-8{4407}{prefix}, char * \hy-8{4408}{buf=NULL})}

Makes a temporary filename based on \hy-7{4409}{prefix}, opens and closes the file,
and places the name in \hy-7{4410}{buf}. If \hy-7{4411}{buf} is NULL, new store
is allocated for the temporary filename using \hy-7{4412}{new}.

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{4413}{/tmp} directory is used.

It is the application's responsibility to create and delete the file.


\hy-10{4415}{::wxIsWild}



\hy-8{4416}{Bool wxIsWild(char * \hy-8{4417}{pattern})}

Returns TRUE if the pattern contains wildcards. See \hy-13{4418}{wxMatchWild}.


\hy-10{4420}{::wxMatchWild}



\hy-8{4421}{Bool wxMatchWild(char * \hy-8{4422}{pattern}, char * \hy-8{4423}{text}, Bool \hy-8{4424}{ dot_special})}

Returns TRUE if the \hy-7{4425}{pattern} matches the \hy-7{4426}{text}; if \hy-7{4427}{
dot_special} is TRUE, filenames beginning with a dot are not matched
with wildcard characters. See \hy-13{4428}{wxIsWild}.


\hy-10{4430}{::wxMkdir}



\hy-8{4431}{Bool wxMkdir(char * \hy-8{4432}{dir})}

Makes the directory \hy-7{4433}{dir}, returning TRUE if successful.


\hy-10{4435}{::wxRemoveFile}



\hy-8{4436}{Bool wxRemoveFile(char * \hy-8{4437}{file})}

Removes \hy-7{4438}{file}, returning TRUE if successful.


\hy-10{4440}{::wxRenameFile}



\hy-8{4441}{Bool wxRenameFile(char * \hy-8{4442}{file1}, char * \hy-8{4443}{file2})}

Renames \hy-7{4444}{file1} to \hy-7{4445}{file2}, returning TRUE if successful.


\hy-10{4447}{::wxRmdir}



\hy-8{4448}{Bool wxRmdir(char * \hy-8{4449}{dir})}

Removes the directory \hy-7{4450}{dir}, returning TRUE if successful.


\hy-10{4454}{::copystring}



\hy-8{4455}{char * copystring(char * \hy-8{4456}{s})}

Makes a copy of the string \hy-7{4457}{s} using the C++ new operator, so it can be
deleted with the \hy-7{4458}{delete} operator.


\hy-10{4460}{::StringMatch}



\hy-8{4461}{Bool StringMatch(char * \hy-8{4462}{s1}, char * \hy-8{4463}{s2},

  Bool \hy-8{4464}{ subString = TRUE}, Bool \hy-8{4465}{ exact = FALSE})}

Returns TRUE if the substring \hy-7{4466}{s1} is found within \hy-7{4467}{s2},
ignoring case if \hy-7{4468}{exact} is FALSE. If \hy-7{4469}{subString} is FALSE,
no substring matching is done.


\hy-10{4473}{::wxFileSelector}



\hy-8{4474}{char * wxFileSelector(char * \hy-8{4475}{message}, char * \hy-8{4476}{default_path = NULL},

  char * \hy-8{4477}{default_filename = NULL}, char * \hy-8{4478}{default_extension = NULL},

  char * \hy-8{4479}{wildcard = ``*.*''}, int  \hy-8{4480}{flags = 0}, wxWindow * \hy-8{4481}{parent = NULL},

  int \hy-8{4482}{ x = -1}, int \hy-8{4483}{ 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{4484}{char *s = wxFileSelector("Choose a file to open");
if (s)
{
  ...
}
}

\hy-10{4486}{::wxGetTextFromUser}



\hy-8{4487}{char * wxGetTextFromUser(char * \hy-8{4488}{message}, char * \hy-8{4489}{caption = ``Input text"},

  char * \hy-8{4490}{default_value = ``"}, wxWindow * \hy-8{4491}{parent = NULL},

  int \hy-8{4492}{ x = -1}, int \hy-8{4493}{ y = -1}, Bool \hy-8{4494}{ centre = TRUE})}

Pop up a dialog box with title set to \hy-7{4495}{caption}, message \hy-7{4496}{message}, and a
\hy-7{4497}{default_value}.  The user may type in text and press OK to return this text,
or press Cancel to return NULL.

If \hy-7{4498}{centre} is TRUE, the message text (which may include new line characters)
is centred; if FALSE, the message is left-justified.


\hy-10{4500}{::wxGetMultipleChoice}



\hy-8{4501}{int wxGetMultipleChoice(char * \hy-8{4502}{message}, char * \hy-8{4503}{caption}, int \hy-8{4504}{ n}, char * \hy-8{4505}{choices[]},

  int  \hy-8{4506}{nsel}, int * \hy-8{4507}{selection},
  wxWindow * \hy-8{4508}{parent = NULL}, int \hy-8{4509}{ x = -1}, int \hy-8{4510}{ y = -1},

  Bool \hy-8{4511}{ centre = TRUE}, int  \hy-8{4512}{width=150}, int  \hy-8{4513}{height=200})}

Pops up a dialog box containing a message, OK/Cancel buttons and a multiple-selection
listbox. The user may choose one or more item(s) and press OK or Cancel.

The number of initially selected choices, and array of the selected indices,
are passed in; this array will contain the user selections on exit, with
the function returning the number of selections. \hy-7{4514}{selection} must be
as big as the number of choices, in case all are selected.

If Cancel is pressed, -1 is returned.

\hy-7{4515}{choices} is an array of \hy-7{4516}{n} strings for the listbox.

If \hy-7{4517}{centre} is TRUE, the message text (which may include new line characters)
is centred; if FALSE, the message is left-justified.


\hy-10{4519}{::wxGetSingleChoice}



\hy-8{4520}{char * wxGetSingleChoice(char * \hy-8{4521}{message}, char * \hy-8{4522}{caption}, int \hy-8{4523}{ n}, char * \hy-8{4524}{choices[]},

  wxWindow * \hy-8{4525}{parent = NULL}, int \hy-8{4526}{ x = -1}, int \hy-8{4527}{ y = -1},

  Bool \hy-8{4528}{ centre = TRUE}, int  \hy-8{4529}{width=150}, int  \hy-8{4530}{height=200})}

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{4531}{choices} is an array of \hy-7{4532}{n} strings for the listbox.

If \hy-7{4533}{centre} is TRUE, the message text (which may include new line characters)
is centred; if FALSE, the message is left-justified.


\hy-10{4535}{::wxGetSingleChoiceIndex}



\hy-8{4536}{int wxGetSingleChoiceIndex(char * \hy-8{4537}{message}, char * \hy-8{4538}{caption}, int \hy-8{4539}{ n}, char * \hy-8{4540}{choices[]},

  wxWindow * \hy-8{4541}{parent = NULL}, int \hy-8{4542}{ x = -1}, int \hy-8{4543}{ y = -1},

  Bool \hy-8{4544}{ centre = TRUE}, int  \hy-8{4545}{width=150}, int  \hy-8{4546}{height=200})}

As \hy-8{4547}{wxGetSingleChoice} but returns the index representing the selected string.
If the user pressed cancel, -1 is returned.


\hy-10{4549}{::wxGetSingleChoiceData}



\hy-8{4550}{char * wxGetSingleChoiceData(char * \hy-8{4551}{message}, char * \hy-8{4552}{caption}, int \hy-8{4553}{ n}, char * \hy-8{4554}{choices[]},

  char * \hy-8{4555}{client_data[]}, wxWindow * \hy-8{4556}{parent = NULL}, int \hy-8{4557}{ x = -1},

  int \hy-8{4558}{ y = -1}, Bool \hy-8{4559}{ centre = TRUE}, int  \hy-8{4560}{width=150}, int  \hy-8{4561}{height=200})}

As \hy-8{4562}{wxGetSingleChoice} but takes an array of client data pointers
corresponding to the strings, and returns one of these pointers.


\hy-10{4564}{::wxMessageBox}



\hy-8{4565}{int wxMessageBox(char * \hy-8{4566}{message}, char * \hy-8{4567}{caption = ``Message"}, int \hy-8{4568}{ style = wxOK | wxCENTRE},

  wxWindow * \hy-8{4569}{parent = NULL}, int \hy-8{4570}{ x = -1}, int \hy-8{4571}{ y = -1})}

General purpose message dialog.  \hy-7{4572}{style} may be a bit list of the
following identifiers:


wxYES_NO
    Puts Yes and No buttons on the message box. May be combined with
wxCANCEL.

wxCANCEL
    Puts a Cancel button on the message box. May be combined with
wxYES_NO or wxOK.

wxOK
    Puts an Ok button on the message box. May be combined with wxCANCEL.

wxCENTRE
    Centres the text.

wxICON_EXCLAMATION
    Under Windows, displays an exclamation mark symbol.

wxICON_HAND
    Under Windows, displays a hand symbol.

wxICON_QUESTION
    Under Windows, displays a question mark symbol.

wxICON_INFORMATION
    Under Windows, displays an information symbol.



The return value is one of: wxYES, wxNO, wxCANCEL, wxOK.

For example:

\hy-14{4573}{  ...
  int answer = wxMessageBox("Quit program?", "Confirm",
                            wxYES_NO | wxCANCEL, main_frame);
  if (answer == wxYES)
    delete main_frame;
  ...
}
\hy-7{4574}{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{4578}{::wxColourDisplay}



\hy-8{4579}{Bool wxColourDisplay(void)}

Returns TRUE if the display is colour, FALSE otherwise.


\hy-10{4581}{::wxDisplayDepth}



\hy-8{4582}{int wxDisplayDepth(void)}

Returns the depth of the display (a value of 1 denotes a monochrome display).


\hy-10{4584}{::wxMakeMetaFilePlaceable}



\hy-8{4585}{Bool wxMakeMetaFilePlaceable(char * \hy-8{4586}{filename}, float  \hy-8{4587}{minX}, float  \hy-8{4588}{minY},
 float  \hy-8{4589}{maxX}, float  \hy-8{4590}{maxY}, float  \hy-8{4591}{scale=1.0})}

Given a filename for an existing, valid metafile (as constructed using \hy-13{4592}{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{4593}{ 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.

\hy-7{4594}{scale} allows the specification of scale for the metafile.

This function is only available under Windows.


\hy-10{4596}{::wxSetCursor}



\hy-8{4597}{void wxSetCursor(wxCursor * \hy-8{4598}{cursor})}

Globally sets the cursor; only has an effect in Windows 3.
See also \hy-13{4599}{wxCursor}, \hy-13{4600}{wxWindow::SetCursor}.


\hy-10{4608}{::wxAddPrimaryEventHandler}



\hy-8{4609}{Bool wxAddPrimaryEventHandler(wxEventHandler \hy-8{4610}{ 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{4612}{::wxAddSecondaryEventHandler}



\hy-8{4613}{Bool wxAddSecondaryEventHandler(wxEventHandler \hy-8{4614}{ handlerFunc}, Bool \hy-8{4615}{ pre},

  Bool \hy-8{4616}{ override}, Bool  \hy-8{4617}{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{4619}{::wxNotifyEvent}



\hy-8{4620}{Bool wxNotifyEvent(wxEvent& \hy-8{4621}{ event}, Bool \hy-8{4622}{ 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{4624}{::wxRegisterEventClass}



\hy-8{4625}{void wxRegisterEventClass(WXTYPE \hy-8{4626}{ eventClassId},WXTYPE \hy-8{4627}{ superClassId},

  wxEventConstructor \hy-8{4628}{ constructor}, char * \hy-8{4629}{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{4631}{::wxRegisterEventName}



\hy-8{4632}{void wxRegisterEventName(WXTYPE \hy-8{4633}{ eventTypeId},WXTYPE \hy-8{4634}{ eventClassId},

  char * \hy-8{4635}{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{4636}{eventClassId} to be created, with given
event type, and some arguments, allows an event to be dynamically
constructed and sent.


\hy-10{4638}{::wxRegisterExternalEventHandlers}



\hy-8{4639}{void wxRegisterExternalEventHandlers(void)}

Define this and link before wxWindows library to allow registering
events from `outside' the main application.


\hy-10{4641}{::wxRemoveSecondaryEventHandler}



\hy-8{4642}{Bool wxRemoveSecondaryEventHandler(wxEventHandler \hy-8{4643}{ handlerFunc}, Bool \hy-8{4644}{ pre})}

Remove a secondary event handler. Returns TRUE if it succeeds.


\hy-10{4646}{::wxSendEvent}



\hy-8{4647}{Bool wxSendEvent(wxEvent& \hy-8{4648}{ event}, Bool \hy-8{4649}{ 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{4653}{::wxGetPrinterCommand}



\hy-8{4654}{char * wxGetPrinterCommand(void)}

Gets the printer command used to print a file. The default is \hy-14{4655}{lpr}.


\hy-10{4657}{::wxGetPrinterFile}



\hy-8{4658}{char * wxGetPrinterFile(void)}

Gets the PostScript output filename.


\hy-10{4660}{::wxGetPrinterMode}



\hy-8{4661}{int wxGetPrinterMode(void)}

Gets the printing mode controlling where output is sent (PS_PREVIEW, PS_FILE or PS_PRINTER).
The default is PS_PREVIEW.


\hy-10{4663}{::wxGetPrinterOptions}



\hy-8{4664}{char * wxGetPrinterOptions(void)}

Gets the additional options for the print command (e.g. specific printer). The default is nothing.


\hy-10{4666}{::wxGetPrinterOrientation}



\hy-8{4667}{int wxGetPrinterOrientation(void)}

Gets the orientation (PS_PORTRAIT or PS_LANDSCAPE). The default is PS_PORTRAIT.


\hy-10{4669}{::wxGetPrinterPreviewCommand}



\hy-8{4670}{char * wxGetPrinterPreviewCommand(void)}

Gets the command used to view a PostScript file. The default depends on the platform.


\hy-10{4672}{::wxGetPrinterScaling}



\hy-8{4673}{void wxGetPrinterScaling(float * \hy-8{4674}{x}, float * \hy-8{4675}{y})}

Gets the scaling factor for PostScript output. The default is 1.0, 1.0.


\hy-10{4677}{::wxGetPrinterTranslation}



\hy-8{4678}{void wxGetPrinterTranslation(float * \hy-8{4679}{x}, float * \hy-8{4680}{y})}

Gets the translation (from the top left corner) for PostScript output. The default is 0.0, 0.0.


\hy-10{4682}{::wxSetPrinterCommand}



\hy-8{4683}{void wxSetPrinterCommand(char * \hy-8{4684}{command})}

Sets the printer command used to print a file. The default is \hy-14{4685}{lpr}.


\hy-10{4687}{::wxSetPrinterFile}



\hy-8{4688}{void wxSetPrinterFile(char * \hy-8{4689}{filename})}

Sets the PostScript output filename.


\hy-10{4691}{::wxSetPrinterMode}



\hy-8{4692}{void wxSetPrinterMode(int  \hy-8{4693}{mode})}

Sets the printing mode controlling where output is sent (PS_PREVIEW, PS_FILE or PS_PRINTER).
The default is PS_PREVIEW.


\hy-10{4695}{::wxSetPrinterOptions}



\hy-8{4696}{void wxSetPrinterOptions(char * \hy-8{4697}{options})}

Sets the additional options for the print command (e.g. specific printer). The default is nothing.


\hy-10{4699}{::wxSetPrinterOrientation}



\hy-8{4700}{void wxSetPrinterOrientation(int \hy-8{4701}{ orientation})}

Sets the orientation (PS_PORTRAIT or PS_LANDSCAPE). The default is PS_PORTRAIT.


\hy-10{4703}{::wxSetPrinterPreviewCommand}



\hy-8{4704}{void wxSetPrinterPreviewCommand(char * \hy-8{4705}{command})}

Sets the command used to view a PostScript file. The default depends on the platform.


\hy-10{4707}{::wxSetPrinterScaling}



\hy-8{4708}{void wxSetPrinterScaling(float  \hy-8{4709}{x}, float  \hy-8{4710}{y})}

Sets the scaling factor for PostScript output. The default is 1.0, 1.0.


\hy-10{4712}{::wxSetPrinterTranslation}



\hy-8{4713}{void wxSetPrinterTranslation(float  \hy-8{4714}{x}, float  \hy-8{4715}{y})}

Sets the translation (from the top left corner) for PostScript output. The default is 0.0, 0.0.


\hy-10{4719}{::NewId}



\hy-8{4720}{long NewId(void)}

Generates an integer identifier unique to this run of the program.


\hy-10{4722}{::RegisterId}



\hy-8{4723}{void RegisterId(long \hy-8{4724}{ id})}

Ensures that ids subsequently generated by \hy-8{4725}{NewId} do not clash with
the given \hy-8{4726}{id}.


\hy-10{4728}{::wxBeginBusyCursor}



\hy-8{4729}{void wxBeginBusyCursor(wxCursor * \hy-8{4730}{cursor = wxHOURGLASS_CURSOR})}

Changes the cursor to the given cursor for all windows in the application.
Use \hy-13{4731}{wxEndBusyCursor} to revert the cursor back
to its previous state. These two calls can be nested, and a counter
ensures that only the outer calls take effect.

See also \hy-13{4732}{wxIsBusy}.


\hy-10{4734}{::wxBell}



\hy-8{4735}{void wxBell(void)}

Ring the system bell.


\hy-10{4737}{::wxDebugMsg}



\hy-8{4738}{void wxDebugMsg(char * \hy-8{4739}{fmt}, ... \hy-8{4740}{})}

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{4741}{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++.


\hy-10{4743}{::wxDisplaySize}



\hy-8{4744}{void wxDisplaySize(int * \hy-8{4745}{width}, int * \hy-8{4746}{height})}

Gets the physical size of the display in pixels.


\hy-10{4748}{::wxError}



\hy-8{4749}{void wxError(char * \hy-8{4750}{msg}, char * \hy-8{4751}{title = "wxWindows Internal Error"})}

Displays \hy-7{4752}{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{4753}{wxFatalError}.


\hy-10{4755}{::wxEndBusyCursor}



\hy-8{4756}{void wxEndBusyCursor(void)}

Changes the cursor back to the original cursor, for all windows in the application.
Use with \hy-13{4757}{wxBeginBusyCursor}.

See also \hy-13{4758}{wxIsBusy}.


\hy-10{4760}{::wxExecute}



\hy-8{4761}{Bool wxExecute(char * \hy-8{4762}{command}, Bool  \hy-8{4763}{sync = FALSE})}

\hy-8{4764}{Bool wxExecute(char ** \hy-8{4765}{argv}, Bool  \hy-8{4766}{sync = FALSE})}

Executes another program in UNIX or Windows.

The first form takes a command string, such as \hy-14{4767}{"emacs file.txt"}.

The second form takes an array of values: a command, any number of
arguments, terminated by NULL.

If \hy-7{4768}{sync} is FALSE (the default), flow of control immediately returns.
If TRUE, the current application waits until the other program has terminated.

See also \hy-13{4769}{wxShell}.


\hy-10{4771}{::wxExit}



\hy-8{4772}{void wxExit(void)}

Exits application after calling \hy-13{4773}{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{4774}{wxFrame::OnClose} and \hy-13{4775}{wxApp}.


\hy-10{4777}{::wxFatalError}



\hy-8{4778}{void wxFatalError(char * \hy-8{4779}{msg}, char * \hy-8{4780}{title = "wxWindows Fatal Error"})}

Displays \hy-7{4781}{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{4782}{wxError}.


\hy-10{4784}{::wxFindFirstFile}



\hy-8{4785}{char * wxFindFirstFile(const char * \hy-8{4786}{spec}, int \hy-8{4787}{ flags = 0})}

This function does directory searching; returns the first file
that matches the path \hy-7{4788}{spec}, or NULL. Use \hy-13{4789}{wxFindNextFile} to
get the next matching file.

\hy-7{4790}{spec} may contain wildcards.

\hy-7{4791}{flags} is reserved for future use.

The returned filename is a pointer to static memory so should
not be freed.

\hy-7{4792}{Note:} this function is not implemented for Borland C++ or Windows NT.

For example:

\hy-14{4793}{  char *f = wxFindFirstFile("/home/project/*.*");
  while (f)
  {
    ...
    f = wxFindNextFile();
  }
}

\hy-10{4795}{::wxFindNextFile}



\hy-8{4796}{char * wxFindFirstFile(void)}

Returns the next file that matches the path passed to \hy-13{4797}{wxFindFirstFile}.

\hy-7{4798}{Note:} this function is not implemented for Borland C++ or Windows NT.


\hy-10{4800}{::wxFindMenuItemId}



\hy-8{4801}{int wxFindMenuItemId(wxFrame * \hy-8{4802}{frame}, char * \hy-8{4803}{menuString}, char * \hy-8{4804}{itemString})}

Find a menu item identifier associated with the given frame's menu bar.


\hy-10{4806}{::wxFindWindowByLabel}



\hy-8{4807}{wxWindow * wxFindWindowByLabel(wxWindow * \hy-8{4808}{parent}, char * \hy-8{4809}{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{4810}{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{4812}{::wxGetHomeDir}



\hy-8{4813}{char * wxGetHomeDir(char * \hy-8{4814}{buf})}

Fills the buffer with a string representing the user's home directory (UNIX only).


\hy-10{4816}{::wxGetHostName}



\hy-8{4817}{Bool wxGetHostName(char * \hy-8{4818}{buf}, int \hy-8{4819}{ bufSize})}

Copies the host name of the machine the program is running on into the
buffer \hy-7{4820}{buf}, of maximum size \hy-7{4821}{bufSize}, returning TRUE if
successful. Under UNIX, this will return a machine name. Under Windows,
this returns ``windows''.


\hy-10{4823}{::wxGetElapsedTime}



\hy-8{4824}{long wxGetElapsedTime(Bool \hy-8{4825}{ resetTimer = TRUE})}

Gets the time in milliseconds since the last \hy-13{4826}{::wxStartTimer}.

If \hy-7{4827}{resetTimer} is TRUE (the default), the timer is reset to zero
by this call.

See also \hy-13{4828}{wxTimer}.


\hy-10{4830}{::wxGetFreeMemory}



\hy-8{4831}{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{4833}{::wxGetOsVersion}



\hy-8{4834}{int wxGetOsVersion(int * \hy-8{4835}{major = NULL}, int * \hy-8{4836}{minor = NULL})}

Gets operating system version information.


Platform
    Return tyes

XView
    Return value is wxXVIEW_X, \hy-7{4837}{major} is X version, \hy-7{4838}{minor} is X revision.

Motif
    Return value is wxMOTIF_X, \hy-7{4839}{major} is X version, \hy-7{4840}{minor} is X revision.

Windows 3.1
    Return value is wxWINDOWS, \hy-7{4841}{major} is 3, \hy-7{4842}{minor} is 1.

Windows NT
    Return value is wxWINDOWS_NT, \hy-7{4843}{major} is 3, \hy-7{4844}{minor} is 1.

WIN32s
    Return value is wxWIN32S, \hy-7{4845}{major} is 3, \hy-7{4846}{minor} is 1.




\hy-10{4848}{::wxGetResource}



\hy-8{4849}{Bool wxGetResource(char * \hy-8{4850}{section}, char * \hy-8{4851}{entry},
 char ** \hy-8{4852}{value}, char * \hy-8{4853}{file = NULL})}

\hy-8{4854}{Bool wxGetResource(char * \hy-8{4855}{section}, char * \hy-8{4856}{entry},
 float * \hy-8{4857}{value}, char * \hy-8{4858}{file = NULL})}

\hy-8{4859}{Bool wxGetResource(char * \hy-8{4860}{section}, char * \hy-8{4861}{entry},
 long * \hy-8{4862}{value}, char * \hy-8{4863}{file = NULL})}

\hy-8{4864}{Bool wxGetResource(char * \hy-8{4865}{section}, char * \hy-8{4866}{entry},
 int * \hy-8{4867}{value}, char * \hy-8{4868}{file = NULL})}

Gets a resource value from the resource database (for example, WIN.INI, or
.Xdefaults). If \hy-7{4869}{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{4870}{wxWriteResource}.


\hy-10{4872}{::wxGetUserId}



\hy-8{4873}{Bool wxGetUserId(char * \hy-8{4874}{buf}, int \hy-8{4875}{ bufSize})}

Copies the user's login identity (such as ``jacs'') into the buffer \hy-7{4876}{
buf}, of maximum size \hy-7{4877}{bufSize}, returning TRUE if successful.
Under Windows, this returns ``user''.


\hy-10{4879}{::wxGetUserName}



\hy-8{4880}{Bool wxGetUserName(char * \hy-8{4881}{buf}, int \hy-8{4882}{ bufSize})}

Copies the user's name (such as ``Julian Smart'') into the buffer \hy-7{4883}{
buf}, of maximum size \hy-7{4884}{bufSize}, returning TRUE if successful.
Under Windows, this returns ``unknown''.


\hy-10{4886}{::wxIPCInitialize}



\hy-8{4887}{void wxIPCInitialize(void)}

Initializes for interprocess communication operation. May
be called multiple times without harm.

See also \hy-13{4888}{wxServer}, \hy-13{4889}{wxClient}, \hy-13{4890}{wxConnection}
and the relevant section of the user manual.


\hy-10{4892}{::wxIsBusy}



\hy-8{4893}{Bool wxIsBusy(void)}

Returns TRUE if between two \hy-13{4894}{wxBeginBusyCursor} and
\hy-13{4895}{wxEndBusyCursor} calls.


\hy-10{4897}{::wxShell}



\hy-8{4898}{Bool wxShell(const char * \hy-8{4899}{command = NULL})}

Executes a command in an interactive shell window. If no command is
specified, then just the shell is spawned.

See also \hy-13{4900}{wxExecute}.


\hy-10{4902}{::wxSleep}



\hy-8{4903}{void wxSleep(int \hy-8{4904}{ secs})}

Under X, sleeps for the specified number of seconds using the
technique specified in the XView manual, not UNIX \hy-8{4905}{sleep}.


\hy-10{4907}{::wxStripMenuCodes}



\hy-8{4908}{void wxStripMenuCodes(char * \hy-8{4909}{in}, char * \hy-8{4910}{out})}

Strips any menu codes from \hy-7{4911}{in} and places the result
in \hy-7{4912}{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{4914}{::wxStartTimer}



\hy-8{4915}{void wxStartTimer(void)}

Starts a stopwatch; use \hy-13{4916}{::wxGetElapsedTime} to get the elapsed time.

See also \hy-13{4917}{wxTimer}.


\hy-10{4919}{::wxSubType}



\hy-8{4920}{Bool wxSubType(WXTYPE \hy-8{4921}{ type1}, WXTYPE \hy-8{4922}{ type2})}

TRUE if \hy-7{4923}{type1} is a subtype of, or the same type as, \hy-7{4924}{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{4925}{wxTypeTree} and \hy-13{4926}{wxObject::__type}.

Example:

\hy-14{4927}{  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{4929}{::wxToLower}



\hy-8{4930}{char wxToLower(char  \hy-8{4931}{ch})}

Converts the character to lower case. This is implemented as a macro for efficiency.


\hy-10{4933}{::wxToUpper}



\hy-8{4934}{char wxToUpper(char  \hy-8{4935}{ch})}

Converts the character to upper case. This is implemented as a macro for efficiency.


\hy-10{4937}{::wxWriteResource}



\hy-8{4938}{Bool wxWriteResource(char * \hy-8{4939}{section}, char * \hy-8{4940}{entry},
 char * \hy-8{4941}{value}, char * \hy-8{4942}{file = NULL})}

\hy-8{4943}{Bool wxWriteResource(char * \hy-8{4944}{section}, char * \hy-8{4945}{entry},
 float  \hy-8{4946}{value}, char * \hy-8{4947}{file = NULL})}

\hy-8{4948}{Bool wxWriteResource(char * \hy-8{4949}{section}, char * \hy-8{4950}{entry},
 long  \hy-8{4951}{value}, char * \hy-8{4952}{file = NULL})}

\hy-8{4953}{Bool wxWriteResource(char * \hy-8{4954}{section}, char * \hy-8{4955}{entry},
 int  \hy-8{4956}{value}, char * \hy-8{4957}{file = NULL})}

Writes a resource value into the resource database (for example, WIN.INI, or
.Xdefaults). If \hy-7{4958}{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{4959}{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{4960}{wxGetResource}.


\hy-10{4962}{::wxYield}



\hy-8{4963}{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
51 52
54 55
57 58
59 60
61 62
63 64
65 66
67 68
69 70
71 72
74 75
77 78
80 81
82 83
95 96
104 105
109 110
113 114
120 121
127 128
133 134
136 137
142 143
144 145
148 149
151 152
155 156
159 160
163 164
165 166
167 168
190 191
200 201
204 205
208 209
210 211
227 228
272 273
274 275
277 278
279 280
281 282
284 285
289 290
292 293
307 308
309 310
314 315
317 318
330 331
333 334
344 345
350 351
352 353
354 355
357 358
363 364
368 369
373 374
380 381
383 384
385 386
388 389
392 393
394 395
396 397
404 405
410 411
412 413
414 415
417 418
420 421
422 423
424 425
426 427
428 429
431 432
433 434
435 436
440 441
444 445
455 456
462 463
464 465
466 467
490 491
507 508
513 514
524 525
526 527
578 579
592 593
596 597
599 600
602 603
605 606
611 612
616 617
620 621
623 624
626 627
629 630
633 634
641 642
643 644
657 658
660 661
663 664
666 667
669 670
672 673
681 682
691 692
695 696
698 699
701 702
712 713
722 723
726 727
738 739
742 743
746 747
750 751
758 759
762 763
767 768
799 800
802 803
826 827
833 834
837 838
846 847
862 863
865 866
870 871
875 876
886 887
889 890
892 893
904 905
911 912
918 919
931 932
948 949
953 954
960 961
971 972
982 983
988 989
993 994
998 999
1003 1004
1009 1010
1016 1017
1023 1024
1032 1033
1035 1036
1040 1041
1046 1047
1049 1050
1055 1056
1060 1061
1068 1069
1073 1074
1079 1080
1085 1086
1090 1091
1107 1108
1113 1114
1119 1120
1128 1129
1133 1134
1137 1138
1141 1142
1143 1144
1174 1175
1177 1178
1200 1201
1203 1204
1207 1208
1211 1212
1214 1215
1240 1241
1243 1244
1248 1249
1251 1252
1266 1267
1270 1271
1273 1274
1276 1277
1280 1281
1284 1285
1289 1290
1304 1305
1307 1308
1314 1315
1321 1322
1324 1325
1333 1334
1337 1338
1343 1344
1346 1347
1352 1353
1357 1358
1360 1361
1364 1365
1368 1369
1371 1372
1374 1375
1377 1378
1381 1382
1389 1390
1393 1394
1396 1397
1399 1400
1402 1403
1405 1406
1434 1435
1437 1438
1440 1441
1443 1444
1446 1447
1449 1450
1456 1457
1464 1465
1472 1473
1480 1481
1486 1487
1494 1495
1497 1498
1504 1505
1512 1513
1521 1522
1526 1527
1531 1532
1539 1540
1546 1547
1551 1552
1556 1557
1562 1563
1598 1599
1601 1602
1615 1616
1618 1619
1621 1622
1626 1627
1639 1640
1642 1643
1646 1647
1650 1651
1654 1655
1666 1667
1673 1674
1679 1680
1686 1687
1699 1700
1716 1717
1721 1722
1728 1729
1739 1740
1750 1751
1757 1758
1760 1761
1765 1766
1768 1769
1772 1773
1776 1777
1780 1781
1784 1785
1789 1790
1797 1798
1801 1802
1805 1806
1820 1821
1824 1825
1831 1832
1840 1841
1844 1845
1848 1849
1851 1852
1854 1855
1857 1858
1860 1861
1863 1864
1867 1868
1872 1873
1880 1881
1885 1886
1890 1891
1895 1896
1901 1902
1908 1909
1912 1913
1917 1918
1922 1923
1927 1928
1931 1932
1934 1935
1943 1944
1962 1963
1965 1966
1972 1973
1985 1986
1988 1989
1994 1995
1997 1998
2001 2002
2007 2008
2014 2015
2029 2030
2032 2033
2035 2036
2039 2040
2050 2051
2055 2056
2059 2060
2067 2068
2070 2071
2075 2076
2078 2079
2081 2082
2084 2085
2087 2088
2090 2091
2093 2094
2097 2098
2101 2102
2109 2110
2123 2124
2127 2128
2131 2132
2134 2135
2138 2139
2141 2142
2145 2146
2148 2149
2152 2153
2156 2157
2164 2165
2168 2169
2170 2171
2172 2173
2174 2175
2177 2178
2183 2184
2198 2199
2201 2202
2206 2207
2210 2211
2214 2215
2218 2219
2222 2223
2226 2227
2229 2230
2232 2233
2235 2236
2240 2241
2243 2244
2326 2327
2332 2333
2337 2338
2343 2344
2359 2360
2362 2363
2369 2370
2374 2375
2386 2387
2391 2392
2395 2396
2399 2400
2403 2404
2406 2407
2414 2415
2419 2420
2427 2428
2432 2433
2437 2438
2443 2444
2450 2451
2456 2457
2463 2464
2468 2469
2473 2474
2475 2476
2482 2483
2488 2489
2498 2499
2501 2502
2505 2506
2512 2513
2515 2516
2521 2522
2524 2525
2530 2531
2536 2537
2540 2541
2548 2549
2556 2557
2565 2566
2570 2571
2572 2573
2577 2578
2581 2582
2584 2585
2588 2589
2592 2593
2597 2598
2600 2601
2603 2604
2609 2610
2618 2619
2620 2621
2629 2630
2634 2635
2637 2638
2640 2641
2643 2644
2646 2647
2650 2651
2654 2655
2658 2659
2662 2663
2665 2666
2668 2669
2671 2672
2674 2675
2678 2679
2681 2682
2686 2687
2691 2692
2694 2695
2702 2703
2715 2716
2718 2719
2730 2731
2733 2734
2739 2740
2743 2744
2748 2749
2755 2756
2758 2759
2766 2767
2769 2770
2774 2775
2779 2780
2782 2783
2787 2788
2815 2816
2818 2819
2827 2828
2830 2831
2846 2847
2850 2851
2854 2855
2858 2859
2862 2863
2865 2866
2869 2870
2872 2873
2876 2877
2881 2882
2887 2888
2892 2893
2896 2897
2901 2902
2908 2909
2914 2915
2920 2921
2924 2925
2930 2931
2933 2934
2950 2951
2953 2954
2959 2960
2965 2966
2969 2970
2973 2974
2977 2978
2983 2984
2986 2987
2991 2992
2998 2999
3002 3003
3005 3006
3012 3013
3015 3016
3021 3022
3027 3028
3033 3034
3039 3040
3044 3045
3048 3049
3052 3053
3057 3058
3063 3064
3068 3069
3074 3075
3081 3082
3083 3084
3097 3098
3100 3101
3110 3111
3113 3114
3118 3119
3121 3122
3124 3125
3128 3129
3135 3136
3141 3142
3145 3146
3148 3149
3151 3152
3154 3155
3157 3158
3160 3161
3163 3164
3166 3167
3169 3170
3172 3173
3175 3176
3178 3179
3206 3207
3211 3212
3216 3217
3220 3221
3224 3225
3227 3228
3230 3231
3234 3235
3238 3239
3242 3243
3245 3246
3248 3249
3251 3252
3254 3255
3257 3258
3260 3261
3263 3264
3271 3272
3274 3275
3277 3278
3280 3281
3283 3284
3287 3288
3293 3294
3296 3297
3299 3300
3302 3303
3305 3306
3308 3309
3310 3311
3315 3316
3319 3320
3345 3346
3348 3349
3359 3360
3362 3363
3365 3366
3370 3371
3374 3375
3377 3378
3380 3381
3383 3384
3386 3387
3392 3393
3396 3397
3407 3408
3411 3412
3415 3416
3419 3420
3423 3424
3426 3427
3429 3430
3433 3434
3437 3438
3442 3443
3446 3447
3453 3454
3465 3466
3469 3470
3476 3477
3479 3480
3486 3487
3489 3490
3492 3493
3495 3496
3503 3504
3513 3514
3521 3522
3525 3526
3529 3530
3533 3534
3536 3537
3540 3541
3544 3545
3554 3555
3558 3559
3564 3565
3573 3574
3576 3577
3585 3586
3589 3590
3600 3601
3602 3603
3643 3644
3646 3647
3675 3676
3682 3683
3686 3687
3689 3690
3692 3693
3695 3696
3699 3700
3703 3704
3708 3709
3713 3714
3716 3717
3719 3720
3723 3724
3728 3729
3730 3731
3750 3751
3753 3754
3768 3769
3771 3772
3775 3776
3778 3779
3783 3784
3786 3787
3790 3791
3794 3795
3799 3800
3805 3806
3808 3809
3813 3814
3835 3836
3838 3839
3852 3853
3855 3856
3860 3861
3863 3864
3881 3882
3884 3885
3887 3888
3898 3899
3901 3902
3904 3905
3908 3909
3911 3912
3914 3915
3917 3918
3921 3922
3926 3927
3929 3930
3936 3937
3940 3941
3943 3944
3946 3947
3952 3953
3959 3960
3968 3969
3972 3973
3976 3977
3980 3981
3985 3986
3988 3989
3992 3993
3997 3998
4002 4003
4017 4018
4024 4025
4027 4028
4030 4031
4033 4034
4036 4037
4041 4042
4044 4045
4099 4100
4102 4103
4112 4113
4116 4117
4118 4119
4121 4122
4124 4125
4128 4129
4132 4133
4137 4138
4144 4145
4151 4152
4154 4155
4158 4159
4162 4163
4165 4166
4168 4169
4171 4172
4174 4175
4179 4180
4182 4183
4185 4186
4190 4191
4193 4194
4196 4197
4201 4202
4207 4208
4212 4213
4220 4221
4232 4233
4238 4239
4241 4242
4244 4245
4255 4256
4258 4259
4264 4265
4267 4268
4271 4272
4278 4279
4282 4283
4289 4290
4293 4294
4301 4302
4306 4307
4312 4313
4316 4317
4321 4322
4324 4325
4328 4329
4332 4333
4336 4337
4340 4341
4344 4345
4348 4349
4352 4353
4361 4362
4368 4369
4375 4376
4382 4383
4389 4390
4398 4399
4404 4405
4414 4415
4419 4420
4429 4430
4434 4435
4439 4440
4446 4447
4451 4452
4453 4454
4459 4460
4470 4471
4472 4473
4485 4486
4499 4500
4518 4519
4534 4535
4548 4549
4563 4564
4575 4576
4577 4578
4580 4581
4583 4584
4595 4596
4601 4602
4607 4608
4611 4612
4618 4619
4623 4624
4630 4631
4637 4638
4640 4641
4645 4646
4650 4651
4652 4653
4656 4657
4659 4660
4662 4663
4665 4666
4668 4669
4671 4672
4676 4677
4681 4682
4686 4687
4690 4691
4694 4695
4698 4699
4702 4703
4706 4707
4711 4712
4716 4717
4718 4719
4721 4722
4727 4728
4733 4734
4736 4737
4742 4743
4747 4748
4754 4755
4759 4760
4770 4771
4776 4777
4783 4784
4794 4795
4799 4800
4805 4806
4811 4812
4815 4816
4822 4823
4829 4830
4832 4833
4847 4848
4871 4872
4878 4879
4885 4886
4891 4892
4896 4897
4901 4902
4906 4907
4913 4914
4918 4919
4928 4929
4932 4933
4936 4937
4961 4962
4964 4965
4966 4967
4968 4969
4971 4972
4973 4974
4975 4976
4977 4978
4979 4980
4981 4982
4983 4984
4985 4986
4987 4988
4989 4990
4991 4992
4993 4994
4996 4997
4998 4999
17 41
56 381
97 318
126 395
135 137
140 389
146 62
154 425
157 389
158 405
207 397
319 374
349 389
377 318
382 55
390 393
403 384
416 418
419 415
447 310
452 318
453 374
509 96
530 627
546 4471
547 4564
548 4473
560 1680
561 1751
564 3454
565 1036
566 1041
572 4322
574 4717
582 627
589 2420
590 4771
614 630
619 627
632 612
637 1627
674 1886
676 627
694 1886
790 2474
825 768
829 4279
830 3387
831 3371
843 999
869 3212
885 847
1008 1091
1014 1647
1015 1651
1039 4213
1044 1036
1054 1091
1067 890
1078 983
1083 1627
1089 3454
1104 989
1105 1004
1106 1010
1112 1114
1118 1108
1126 4175
1127 1091
1135 999
1199 1144
1265 1215
1292 1315
1295 1487
1296 4886
1297 1308
1313 1315
1318 1308
1320 1487
1373 1881
1380 1881
1391 2474
1392 4646
1462 3724
1463 1315
1471 1487
1478 1532
1479 1498
1483 1495
1519 1540
1538 1505
1545 1513
1550 1522
1555 1527
1560 4596
1611 999
1637 1896
1645 1873
1756 1806
1771 1864
1775 1886
1779 1891
1783 1896
1788 1902
1800 1909
1804 1913
1819 1891
1823 1918
1879 1643
1899 1627
1907 1923
1940 4471
1984 1944
2013 2068
2118 1891
2119 1751
2120 1806
2122 2157
2126 1891
2329 2202
2330 2333
2336 2207
2339 2420
2385 2344
2390 2457
2394 2438
2398 2464
2462 2387
2467 2396
2471 2387
2472 2457
2486 1674
2664 1036
2845 2788
2919 1674
2922 2428
2923 4245
2929 4245
2949 2992
2982 2934
2997 2934
3109 3084
3117 3122
3138 3149
3140 4584
3153 1041
3215 866
3233 3239
3241 3231
3313 4919
3358 3320
3373 827
3468 1909
3584 4651
3588 1790
3674 3603
3767 3731
3851 3814
3897 3864
3996 4003
4022 4914
4023 4823
4046 4919
4136 4138
4218 4233
4231 4155
4236 4213
4310 4596
4380 4369
4381 4383
4418 4420
4428 4415
4600 4307
4605 3387
4731 4755
4732 4892
4753 4777
4757 4728
4758 4892
4769 4897
4773 624
4774 2420
4782 4748
4789 4795
4797 4784
4826 4914
4870 4937
4894 4728
4895 4755
4900 4760
4916 4823
4960 4848
17 41
56 381
97 318
126 395
135 137
140 389
146 62
154 425
157 389
158 405
207 397
319 374
349 389
377 318
382 55
390 393
403 384
416 418
419 415
447 310
452 318
453 374
509 96
530 627
546 4471
547 4564
548 4473
560 1680
561 1751
564 3454
565 1036
566 1041
572 4322
574 4717
582 627
589 2420
590 4771
614 630
619 627
632 612
637 1627
674 1886
676 627
694 1886
790 2474
825 768
829 4279
830 3387
831 3371
843 999
869 3212
885 847
1008 1091
1014 1647
1015 1651
1039 4213
1044 1036
1054 1091
1067 890
1078 983
1083 1627
1089 3454
1104 989
1105 1004
1106 1010
1112 1114
1118 1108
1126 4175
1127 1091
1135 999
1199 1144
1265 1215
1292 1315
1295 1487
1296 4886
1297 1308
1313 1315
1318 1308
1320 1487
1373 1881
1380 1881
1391 2474
1392 4646
1462 3724
1463 1315
1471 1487
1478 1532
1479 1498
1483 1495
1519 1540
1538 1505
1545 1513
1550 1522
1555 1527
1560 4596
1611 999
1637 1896
1645 1873
1756 1806
1771 1864
1775 1886
1779 1891
1783 1896
1788 1902
1800 1909
1804 1913
1819 1891
1823 1918
1879 1643
1899 1627
1907 1923
1940 4471
1984 1944
2013 2068
2118 1891
2119 1751
2120 1806
2122 2157
2126 1891
2329 2202
2330 2333
2336 2207
2339 2420
2385 2344
2390 2457
2394 2438
2398 2464
2462 2387
2467 2396
2471 2387
2472 2457
2486 1674
2664 1036
2845 2788
2919 1674
2922 2428
2923 4245
2929 4245
2949 2992
2982 2934
2997 2934
3109 3084
3117 3122
3138 3149
3140 4584
3153 1041
3215 866
3233 3239
3241 3231
3313 4919
3358 3320
3373 827
3468 1909
3584 4651
3588 1790
3674 3603
3767 3731
3851 3814
3897 3864
3996 4003
4022 4914
4023 4823
4046 4919
4136 4138
4218 4233
4231 4155
4236 4213
4310 4596
4380 4369
4381 4383
4418 4420
4428 4415
4600 4307
4605 3387
4731 4755
4732 4892
4753 4777
4757 4728
4758 4892
4769 4897
4773 624
4774 2420
4782 4748
4789 4795
4797 4784
4826 4914
4870 4937
4894 4728
4895 4755
4900 4760
4916 4823
4960 4848
}
