\documentstyle[a4,makeidx,verbatim,texhelp,fancyhea,mysober,mytitle]{report}
% This is for dvi2tty only
%\setlength{\textwidth}{12 true cm}    % shorten line length
%\renewcommand{\baselinestretch}{.5}   % singlespacing
%
\input psbox.tex
\parskip=10pt
\parindent=0pt
\title{wxWindows Frequently Asked Questions Version 1.4}
\author{Julian Smart and others}
\date{March 1995}
\makeindex
\begin{document}
\maketitle
\pagestyle{fancyplain}
\bibliographystyle{plain}
\setheader{{\it CONTENTS}}{}{}{}{}{{\it CONTENTS}}
\setfooter{\thepage}{}{}{}{}{\thepage}%
\pagenumbering{roman}
\tableofcontents
%
\chapter{About this document}
\setheader{{\it FAQ}}{}{}{}{}{{\it FAQ}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%

This is the questions-and-answers document for wxWindows, the free multi-platform
GUI C++ library. Please feel free to comment on this FAQ and submit new entries.

\chapter{General questions}

\section{What are the licensing considerations for wxWindows?}

None. You may make any use of any part of wxWindows, and no payment is
necessary. While it's nice if you acknowledge the author(s) of wxWindows
in your own work, it's not necessary.

Correspondingly, there is no warranty with wxWindows, as you have probably
guessed by now.

\section{Why is wxWindows free, and will it ever be commercial or shareware?}

It's free because:

\begin{itemize}
\item it was never intended to compete as a commercial product, since
there are not sufficient resources at AIAI.
\item the feedback and bug fixes that AIAI get from the Internet community
are extremely valuable.
\item having used much free software in the past, it's only right
to put something back.
\item AIAI gains a small amount of publicity (well, so the story goes).
\item I got bored of writing code that never saw the light of day.
\end{itemize}

Neither I nor AIAI have any plans to produce a commercial or shareware version.

\section{Why the silly name?}

{\bf w} for MS Windows, {\bf x} for the X windowing system, Windows for those rectangular
things you see a lot of. Ok, so it's not exactly inspired.

\section{What bitmap loading facilities are available for wxWindows?}

There is Windows .BMP code that compiles under Windows distributed
with wxWindows 1.50k (utils/dib directory). wxWindows 1.60 will allow
proper colourmap setting with this code. DIB allows loading and saving
BMP files.

For X, the utils/image directory contains code to load GIFS, Windows
bitmaps and X bitmaps into a canvas (and optionally, into a wxBitmap).
The code has been taken from a pre-shareware version of the excellent
image viewer XV; it cannot be guaranteed that the code is free from
copyright issues.  See the file test.cc for a scanty explanation of how
to use it.

XPM (colour X Pixmap) files are supported by the wxXPM package
now bundled with wxWindows, from 1.61. The package is in contrib/wxxpm,
and includes a utility XPMShow which allows conversion between XPM
and BMP files under Windows (only, at present).

For the maximum bitmap facilities, wx\_setup.h should be edited
and the following settings made:

\begin{itemize}
\item Set USE\_IMAGE\_LOADING\_IN\_X to 1
\item Set USE\_IMAGE\_LOADING\_IN\_MSW to 1
\item Set USE\_XPM\_IN\_X to 1
\item Set USE\_XPM\_IN\_MSW to 1
\end{itemize}

Then recompile the wxWindows, image (X), DIB (Windows) and XPM (X and Windows)
libraries and link in with your application. You can now load and save
XPMs (X and Windows), load BMP files (X and Windows), save BMP
bitmaps (Windows), and load GIFs (X), all through the wxBitmap interface.

It is recommended that you use XPMs for colour bitmap buttons,
at least under X. Note that colour buttons will not display correctly
on X terminals whose display depth does not match the bitmap depth,
so checking will need to be done in the application.

\section{Can I put a canvas (or text subwindow) in a panel?}\label{nesting}

Before 1.61, this kind of nesting was not allowed, because XView
doesn't support it, and wxWindows was heavily influenced by XView.

From 1.61, such restrictions are being relaxed a bit for platforms
that support more flexibility. Under Motif and Windows, canvases and
text subwindows can be placed in panels as well as in frames.

Also, again from 1.61 on, wxPanel is a subclass of wxCanvas, under Windows
(only, at present). So drawing in panels is now possible (or placing panel items in
a canvas, whichever way you like to look at it). Hopefully this will soon be
extended to Motif; it is unlikely to be implemented for XView since
XView doesn't really support this way of working.

\section{Can I draw in a panel, or place panel items in a canvas?}

See \helpref{Nesting subwindows}{nesting}.

\section{How were the samples (and other code) created?}

The samples and other code were all created with a text editor, with nary
an Integrated Development Environment in sight. In future, as
wxBuilder and the wxWindows resource system matures, it is to be hoped
that some code will have been generated by wxBuilder.

See also \helpref{Can I use an IDE?}{ide}.

\chapter{Compilation issues}

\section{I need a drink. Why is compilation so difficult on some platforms?}

It's a good question; you may be lucky enough to sail through wxWindows
installation without a hitch, or you may exhaust your vocabulary of
expletives before you're done compiling the first sample application.

There are a number of possible reasons for things to go wrong:

\begin{itemize}
\item Makefiles need to be adjusted (especially make.env) to add include and
library paths, and library flags, specific to that OS or compiler.
\item I've messed up the distribution. Occasionally I edit a file at the last
minute without testing it properly... Normally these problems become apparent
quite quickly.
\item There's an honest-to-goodness bug in wxWindows. Sorry! but wxWindows is
quite complex, and bugs happen. Whether you can classify not coping with
a particular setup a bug, I don't know, but there will be occasions when
installation reveals a bug. Mostly, though, real bugs are only identified
when applications get complex.
\item Your compiler has not been installed properly. This is often signalled
by missing libraries such as iostream.
\item There's a compiler incompatibility. This is extremely rare, since
wxWindows uses a very limited subset of C++ syntax, and steers
clear of unportable constructs such as templates.
\item There's a bug in the compiler. This happens surprisingly often, particularly
with GNU C++ where the latest release might have a brand new bug. This can manifest
itself as a bizarre link error, or run-time problem such as the message "You must define an instance
of wxApp!" (globals haven't been initialized properly by the compiler).
\item There's a bug in the OS, such as a lack of certain include files (it happened
with some versions of SunOS).
\item You're using a compiler and/or OS that no-one's tested wxWindows out on before.
If you're really unlucky (and intrepid) you could find yourself doing a 'port'
to an environment never before encountered. In fact, the changes involved are
usually quite small, and are nearly always centred around wx\_utils.cc and wx\_ipc.cc
which make heavy demands on operating system-sensitive areas.
\end{itemize}

In general, the reason why compiling wxWindows can be more troublesome than other packages
is that with conventional application building, you {\it gradually} use more and more
parts of the operating system or GUI toolkit. With wxWindows, because it covers
a large `surface area', you're encountering these possible troublespots all at once
when you compile the library.

The good side of all this is that once you {\it have} ironed out the initial compilation
and run-time problems, these particular headaches ought to be minimal from then on.
So don't be too discouraged if installation is initially difficult!

Borland C++ seems to generate the most traffic for installation problems. I'm
not exactly sure why this is, since although I don't have Borland C++, various
people have contributed tips and makefiles. I suspect that something about
the design of Borland C++ makes it difficult to compile a large project without a lot
of in-depth knowledge about the compiler options.

\section{Can I use an Integrated Development Environment?}\label{ide}

It is possible to use an existing IDE for writing code, but the
project file settings are tricky and often the IDEs do not allow
the flexibility that wxWindows requires, with its little libraries
tucked away in odd places. By adding enough switches, it should be
possible.

In particular, some IDEs (such as Microsoft's) do not like C++ source
files to have .cc extensions, so renaming of .cc files is necessary.

\section{What are ItsyBits, FAFA etc.? Which libraries do I really need to compile?}

From wxWindows 1.61, the makefiles have been altered so that several
`subordinate' libraries are compiled into wx.lib (or wx\_motif.a or
whatever). This means that configuration of wxWindows is much more
centralized, and it's not necessary to fiddle with many makefiles if you
decide to compile in a specific wxWindows feature.

These little libraries add optional functionality to wxWindows,
supported in the wxWindows class library but the bulk of the
functionality being implemented separately for modularity (and potential
copyright) reasons.

Unfortunately, you do have to edit {\it both} wx\_setup.h and the makefile
in src/x or src/msw in order to configure wxWindows. So it
may be easier to compile all libraries rather than try to configure
wxWindows, unless you're really having trouble compiling one of
the libraries.

Here's a list of the optional libraries (found in wx/contrib or wx/utils).
The relevant wx\_setup.h identifier is given in brackets.

\begin{description}
\item[CTL3D] Windows only: allows use of 3D style controls (CTL3D).
\item[FAFA] Windows only: allows use of bitmap buttons, messages and radiobuttons (FAFA\_LIB).
\item[ItsyBitsy] Windows only: supports tiny titlebars (USE\_ITSY\_BITSY).
\item[Gauge] Windows only: necessary for implementation of wxGauge class (USE\_GAUGE).
\item[xmGauge] Motif only: necessary for implementation of wxGauge class (USE\_GAUGE).
\item[wxXPM] All platforms: necessary for implementation of XPM pixmap functionality (USE\_XPM\_IN\_X, USE\_XPM\_IN\_MSW).
\item[DIB] Windows only: necessary for implementation of BMP loading/saving functionality (USE\_IMAGE\_LOADING\_IN\_MSW).
\item[wxImage] X only: necessary for implementation of BMP, GIF loading functionality (USE\_IMAGE\_LOADING\_IN\_X).
\item[PROLOGIO] All platforms: necessary for .WXR wxWindows resource-loading functionality (USE\_MSW\_RESOURCES).
\item[RCPARSER] Windows only: necessary for dynamic icon loading (USE\_RESOURCE\_LOADING\_IN\_MSW).
\end{description}

Note that if you don't compile in DIB, you could still use wxLoadBitmap in an application
and link with dib.lib separately in your application makefile. Similarly, you can use PROLOGIO and RCPARSER
independently without them being compiled into wx.lib.


\section{Linux issues}

\subsection{Why do the makefiles not work?}

You may be using `pmake': the wxWindows makefiles
require you to be using the default GNU make, which has
a slightly different syntax (for example, the include
statement syntax is different).

\subsection{My binaries are enormous! What can I do?}

wxWindows 1.60 improves on 1.50 by the use of GCC pragmas to
specify which files are interfaces and which are implementation.

Also, if you compile everything without debugging information,
GCC will use dynamic link libraries for X11, XView and some others;
this reduces the size of the binary substantially.

You can also create a dynamic version of wx\_ol.lib; see
the files in the /pub/wxwin/contrib area which help
create a dynamic library, and also the notes in /usr/doc/faq.

See also install.txt for a discussion of these issues.

\subsection{Why does the Xfree ATI Mach32 server hang when drawing
graphics?}

Harri Pasanen has discovered a bug in the Mach32 server.
It hangs if using pens with wxDOT linestyle, and width zero.

This has been reported to the Xfree developers.

\section{Solaris 2.x issues}

\subsection{I get some warnings and link errors. What gives?}

You need to:

\begin{itemize}
\item Compile with -DSVR4. Add this to OPTIONS line in each
makefile.unx.
\item Add the following to LDFLAGS: -lgen -ldl -lsocket -lnsl
\end{itemize}

Note that the libgen.a lives in /usr/ccs/lib, if you
have installed the programming tools option.

Version 4.0 of Sun C++ is apparently more pedantic than
older versions, and requires the use of CC -migration to
help with the necessary changes. You may need to include the file strings.h
where the file string.h is included, with CC, e.g. in wb\_utils.cc.

Someone reported that link errors on a SPARCStation were
cured by adding -lucb and -I/usr/ucbinclude/sys.

For dynamic linking under Solaris 2.3, the following
changes are required:

\begin{itemize}
\item In wxinstal, add:

\begin{verbatim}
export OPTIONS
OPTIONS=-fPIC
\end{verbatim}%
\item in src/x/makefile.unx, add:

\begin{verbatim}
WXLIB = $(WXDIR)/lib/libwx$(GUISUFFIX).so.0

$(WXLIB): $(OBJECTS) $(BASEOBJECTS)
      	ld -G -o $(WXLIB) $(OBJECTS) $(BASEOBJECTS)
\end{verbatim}

where the ld line replaces the ar+ranlib command.
\end{itemize}

Here are my (JACS) own experiences. As of 25th May 1995, I finally got a clean
compilation under Solaris (using XView), though I needed to change a lot
of files, e.g. in wxXPM and wxImage. The following is a script I wrote
to save editing make.env, for Solaris compilation. It shows the kinds of
settings required.

I think for some environments you may need to add -L/usr/ccs/lib -lgen
to the COMPLIBS line.

The changes required to compile under Solaris will be in version 1.62 beta (b).
New versions of Solaris and the SunPro compiler may break all this, of course.

\begin{verbatim}
#!/bin/sh
# makeunix
# Invokes makefile with specific XLIB and XINCLUDE settings,
# IFF your version of make can take the -e flag
# (environment variables take precedence.)
export XINCLUDE
export XLIB
export CC
export CCC
export CCLEX
export DEBUG
export WARN
export RANLIB
export COMPLIBS
export OPTIONS
CC=CC
CCC=cc
CCLEX=cc
OPTIONS=-DSVR4
COMPLIBS='-ldl -lsocket -lnsl'
XINCLUDE=-I/usr/openwin/include
XLIB='-L/usr/local/X11/lib -L/usr/openwin/lib'
DEBUG=
WARN=
RANLIB=echo
make -f makefile.unx -e $@
\end{verbatim}

\section{Compiling on OSF/1}

Here's how.

\begin{verbatim}
From: Asociacion Fisica Universidad <afu2@eucmos.sim.ucm.es>
Subject: Ported wxWin 1.60 to OSF1
To: J.Smart@ed.ac.uk

        Hi!

        I've been playing around with wxWin (great package!) and I've 
make it to compile under OSF/1 with motif. I send you the modified 
make.env, just in case.

        There is a minor change in a file I can't remember which is, but 
is in someplace in which it makes a wait and you say it's bad, that it 
has to be remade. There's a conditional compilation there, and where we 
can fidn #if !defined(SVR4) && .. etc, just include a !defined(OSF1). It 
shoudl work all right.

        Well, here's the make.env.osf1. If you have any comments, let me know!

# make.env

# slightly touched by Iniaky Perez Gonzalez (afu2@fis.ucm.es, 2:341/5.31) 
# to work fine under OSF/1

# Common makefile settings for wxWindows programs
# This file is included by all the other makefiles, thus changes 
# made here take effect everywhere (except where overriden).
#
# An alternative to editing this file is to create a shell script
# to export specific variables, and call make with the -e switch
# to override makefile variables. See wx/install/install.txt.
# And you can override specific variables on the make command line, e.g.
#
# make -f makefile.unix DEBUG=''
#

########################## Compiler ##################################

# C++ compiler
#CC = gcc-2.1
CC = cxx

# C compiler for pure C programs
# Typical: CC=g++ , CCC=gcc
#          CC=cl386 /Tp, CCC=cl386
#
# (Used only for XView, file sb_scrol.c)
#
CCC = cc

# Compiler used for LEX generated C
CCLEX=$(CCC)

########################## Compiler flags #############################

# Miscellaneous compiler options
# May need to add -D_HPUX_SOURCE_ for HPUX
# Solaris: add -DSVR4
OPTIONS= -Dosf1 -DOSF1 -D__OSF1

# Debugging information
#DEBUG = -g
DEBUG =

# Warnings
WARN = 

# Which GUI, -Dwx_xview or -Dwx_motif (don't change this)
GUI = -Dwx_motif

# Optimisation
# OPT = -O
OPT =

# Options for ar archiver
# AROPTIONS = crs # For IRIX. Also, comment out ranlib line.
AROPTIONS = sruv

# Compiler libraries: defaults to GCC libraries
# Sun with Sun CC: -lc
# Solaris: -lgen -ldl -lsocket -lnsl
#   and/or possibly -lucb, whatever that is...
# SGI:     -lPW
COMPLIBS=-lc -lm -lcxx

# Compiler or system-specific include paths
# E.g. some SPARCStations need
# -I/usr/ucbinclude/sys
COMPPATHS=-I/usr/include/cxx

# HP-specific compiler library: an AIAI convenience
HPCOMPLIBS=

# LDLIBS for specific GUIs
MOTIFLDLIBS = -lwx_motif -lXm -lXt -lX11 -lm $(COMPLIBS)
XVIEWLDLIBS = -lwx_ol -lxview -lolgx -lX11 -lm $(COMPLIBS)
HPLDLIBS=-lwx_hp -lXm -lXt -lX11 -lm

# Default LDLIBS for XView (don't change this)
LDLIBS = $(XVIEWLDLIBS) -lbsd

# _ol or _motif (don't need to change, the makefiles will take
# care of it if you use motif/hp/xview targets)
GUISUFFIX=_motif

########################## Directories ###############################

# Replace X include/lib directories with your own
INCLUDE=-I/usr/include -I/usr/include/X11 -I/usr/include/Xm
LIB=-L/usr/local/X11/lib -L/usr/lib/Xm
#XINCLUDE=-I/aiai/packages/motif1.2.1/motif/include -I/aiai/packages/X.V11R5/inc
lude
#XLIB=-L/aiai/packages/motif1.2.1/motif/sun4/lib -L/aiai/packages/X.V11R5/lib

# A convenience, for HP compilation
HPXINCLUDE=-I/usr/include/Motif1.2 -I/usr/include/X11R5
HPXLIB=-L/usr/lib/Motif1.2 -L/usr/lib/X11R5

# Shouldn't need to change these...
WXINC = $(WXDIR)/include/x
WXBASEINC = $(WXDIR)/include/base
WXLIB = $(WXDIR)/lib/libwx$(GUISUFFIX).a
INC = -I$(WXBASEINC) -I$(WXINC) $(COMPPATHS)

# Directory for object files (don't change)
OBJDIR = objects$(GUISUFFIX)

# You shouldn't need to change these...
CPPFLAGS = $(XINCLUDE) $(INC) $(OPTIONS) $(GUI) $(DEBUG) $(WARN) $(OPT)
CFLAGS = $(XINCLUDE) $(INC) $(OPTIONS) $(GUI) $(DEBUG) $(WARN) $(OPT)
LDFLAGS =  $(XLIB) -L$(WXDIR)/lib

# Extra patch link for XView
XVIEW_LINK = $(WXDIR)/src/x/objects_ol/sb_scrol.o
\end{verbatim}

\section{Compiling on HP kit}

Here's how.

\begin{verbatim}
Date: Fri, 21 Apr 1995 09:03:32 -0600
From: Bruce Lee <lee@abraham.et.byu.edu>
Apparently-To: J.Smart@ed.ac.uk
Status: REO

Julian,

Thank you for the suggestions concerning the wxEntry problem I was having.  I
changed main.c to a c++ file and commented out the extern C wxEntry in wx_main.c
c
and all was well.  If you or the wxWindows users are interested the following
are the changes I had to make to get wx161 to compile on an HP 7xx/8xx machine
using HP's C++ compiler:

        * Add the compiler flag +a1 to the options field in src/make.env
          This tells the compiler to be ASNI strict.

        * You _must_ use flex _and_ bison to compile y_tab.c in the prologio
          stuff.  Also I found gcc works best to build y_tab.o.

        * In contrib/xmgauge/gauge.c, change #ifdef 0 to #if 0

NOTE: The standard c compiler cc on the HP will warn you that +a1 is an invalid
      option when building non-C++ files.  Gcc will bomb if that option is used
      when building y_tab.c.  You can hack the makefile or create a new macro
      to provide the proper options.

Thank you,

Bruce
\end{verbatim}

\section{How can I use wxWindows with Borland C++?}

Here are some tips for using Borland C++ with wxWindows.

\subsection{To create new IDE project files}

\begin{enumerate}
\item The IDE must recognize .cc files to edit and compile wxWindows
source. You must add .cc to the extension lists in the
Options/Tools/CppCompile, Options/Tools/EditText and
Options/Environment/Syntax Highlighting menus.
\item Create a new project file with the following settings:
\begin{itemize}
\item Platform: Win16 or Win32 (always the same)
\item Standard libs: No OWL, no Class Lib (unportables)
\item Advanced Ops/No source node
\end{itemize}
\item If the source files already exist, just type Ins on the target name
(*.exe or *.lib) of the project window. The selector file dialog must
appear. Then select all the relevant *.cc files, and the *.rc and 
*.def files. 

If you are not sure about which files must be included, look into a
makefile, if it exists, for the sources. Don't worry about libraries,
BC4 has its own windows libraries.
\end{enumerate}

\subsection{To use old *.prj project files}

The IDE can read version 3.1 *.prj files, and then convert them to the
new format. You must repeat item 1 (above) each time you read
a *.prj file, and sometimes you'll have to select the .cc files in 
the project window, and drop them on the target file (.exe or .lib), 
in order to obtain little bullets in left of the project window 
(ie. to make the IDE recognize the files). If there are no many .cc 
files, I recomend to create a new *.ide file.

\subsection{To use makefiles}

Now the wxWindows distribution includes Borland makefiles.
The file "makefile.bcc" from \verb$samples\minimal$ directory could
be used as a template.

\subsection{To compile wxWindows projects}

Build \verb$wx.lib$ with the supplied makefiles. If you want to use the IDE
for your new applications:

\begin{enumerate}
\item Set the proper directories. In the menu Options/Project/Directories/Include,
add \verb$"(wxdir)\include\base;(wxdir)\include\msw"$, where (wxdir) must be
changed for the wxWindows base directory. Avoid absolute paths 
in your code, if you want it to be portable. 
\item In Options/Messages/Potential C++ errors menu, uncheck
"function f1 hides virtual function f2", to reduce
the amount of message warnings during compiling.
\item A typical Windows application (16bits mode) can't have a data segment
larger than 64k. To avoid 
\rtfsp\helpref{data segment overflow}{dataseg} and linking problems,
set in Options/Project/16-bit Compiler/Memory Model:
\begin{itemize}
\item Memory model: large
\item Asume SS = DS: never
\item Far virtual tables: on
\item Automatic far data: on
\item Far data threshold: 512
\end{itemize}
\end{enumerate}

Example files for minimal example:

\begin{verbatim}
 minimal[.exe]
     -minimal.cc
     -minimal.rc
     -minimal.def
     -wx.lib
\end{verbatim}

\subsection{Borland C++ complains about a missing 1.cpp file.}

Copy wx\_panel.cc, wx\_utils.cc, wx\_dialg.cc, wx\_timer.cc and
wx\_clipb.cc to corresponding .cpp files. You need not change the
names in the makefile. BCC will compile the .cpp modules.

Hopefully this workaround will be made redundant at some point
in the future.

\subsection{Miscellaneous tips}

If Borland crashes or runs out of memory during a compile, you
may need to configure your DPMI swap file: see P. 21 of the Borland 4.0
User Guide. This is particularly necessary if you only have 8MB of physical
memory.

For precompiled headers to work properly on the wxWindows library,
you will need to uncomment the first

\begin{verbatim}
// #include "wx.h"
\end{verbatim}

line in each file in src/base. Yes, this {\it does} look like some files will
be included three times: but they won't really. The line has to be before
any pragmas of ifdefs, or the precompilation doesn't work.

If you don't recompile wx.lib often, this editing is not necessary.

\hrule
{\it Contributed by Aguilar Sierra Alejandro-CCA \verb$<asierra@servidor.unam.mx>$, Oliver Niedung \verb$<niedung@cip.med-informatik.uni-hildesheim.de>$ and
Andrew Davison \verb$<adavison@ozemail.com.au>$}

\section{Why do I get "data segment overflow error" when linking using Borland compiler?}\label{dataseg}

You have a number of switches in compiler configuration that may need
adjusting. In order of my own preference:

\begin{enumerate}
\item Make sure that stack is located in a different segment from data.
     It saves you about 16k.

IDE:
\begin{itemize}
\item "Assume DS==SS" - Never, Never and Never! 
\item "Smart callbacks" -Off.
\end{itemize}

Command line:
\begin{itemize}
\item -WE -Fs-
\end{itemize}

DrawBacks: All functions that are exported to Windows must be 
explicitly declared so, and MakeProcInstance() call is neccessary.
(This is done in wxWin, just take care of your own callbacks).

For version 150k you have to uncomment one MakeProcInstance() in
src/msw/wx\_main.c (or wx\_win.c - don't remember exactly). 
The patch is sent to Julian.
   
\item Put virtual tables into code segment.
It saves you 4bytes*per\_virtual\_function\_per\_class. Inherited functions
also count. Result is more than you can expect. 

IDE:
\begin{itemize}
\item "Far virtual tables" - On.
\end{itemize}

Command line: 
\begin{itemize}
\item -Vf
\end{itemize}

Drawbacks: All C++ libraries and objects must be compiled with the
same settings of this switch or you'll get "undefined symbol" link
errors. Put this is in your default configuration file and 
recompile everything to save yourself from trouble later.
\item Turn on automatic far data.

IDE:
\begin{itemize}
\item "Automatic far data" - On,
\item "Far data threshold" - 4.
\end{itemize}

Command line:
\begin{itemize}
\item -Ff=4
\end{itemize}

Drawbacks: you can't run more than one instance of your program
anymore. This is architectural flaw in MS-Windows. If you need to,
make several copies of your .exe under different names and run 
one copy of each.
\item Put constant strings in code segments.

IDE:
\begin{itemize}
\item "Put constant strings in code segments"
\end{itemize}

Command line:
\begin{itemize}
\item -dc
\end{itemize}

Drawbacks: Not available with Borland 3.1. 
You probably wan't be able to modify any of these strings, since
they are in code segments. If windows does not prohibit write
access to code segments, then this will cause hard to find bugs.
(Code segments are marked as discardable and can be thrown away and
reloaded from .exe file at any moment).
(I did not tried it myself yet).
\end{enumerate}

\hrule
{\it Contributed by Alexei Vovenko \verb$<alv@au.edu.dstc>$}

\section{My Windows compiler doesn't contain all the required .lib files.}

Some compilers seem to be shipped without libraries such as ddeml.lib, shell.lib,
and commdlg.lib. Use implib to generate corresponding .lib files, e.g.

\begin{verbatim}
implib commdlg.lib c:\windows\system\commdlg.dll
\end{verbatim}

\section{Is it possible to use multithreaded library with wxWindows under MS-Windows?}

Yes, if you do it carefully. First of all make sure that your
compiler does not make any unreasonable assumptions about stack
segment, and better still it makes no assumptions about stack segment
at all. Make sure that both the library and your program are compiled 
this way. 

Do not expect wxWindows to be reentrant because MS-Windows is not.   
Most probably your thread implementation does not use preemptive scheduler,
so MS-Windows reentrancy is not a big problem.

Derive your member from "Bool wxApp::OnIdle(void)" 
and put a pthread\_yield() call there. If you use dialogs, take care about
yielding to threads while in a dialog.

\hrule
{\it Contributed by Alexei Vovenko \verb$<alv@au.edu.dstc>$}

\section{Can I use wxWindows with Watcom C++?}

People are working on Watcom support; watch this space. So far, however,
it seems that only 16-bit wxWindows programs will compile with Watcom
due to a bug in the compiler.

\section{How can I compile PROLOGIO with Borland C++?}

Borland users have been finding that it's impossible to compile
the LEX and YACC-generated parser files in PROLOGIO from wxWindows
1.50. PROLOGIO is required for compiling wxBuilder.

Peter Trattler and Edward Zimmermann have improved PROLOGIO to allow
FLEX to be optionally used instead of LEX; see the PROLOGIO manual for
more details. If you have FLEX (the default Linux lexical analyser
generator), you can generate a lex\_yy.c which compiles more cleanly.

LEX and FLEX-generated versions of lex\_yy.c are supplied, as
lexyy.c and flexyy.c respectively.

FLEX and YACC are freely available for DOS; most major DOS ftp
sites should have them.

\section{How can I compile PROLOGIO successfully under UNIX?}

Check that the CCLEX variable in make.env; set it to use a bog-standard
(or GNU) C compiler for compiling LEX-generated files.

Using FLEX instead of LEX sometimes helps, too.

Most of the warnings when compiling PROLOGIO are spurious; however,
there may be an error buried inside the warnings. If so, you may need
to change a prototype in a generated .c file to get it compiled.
Hopefully this type of error is getting much rarer now.

\section{I get a compilation error in wb\_item.cc using Borland C++.}

In release 1.50 k there's a bug: edit wb\_item.cc, go down
to the wxbRadioBox constructor and replace

\begin{verbatim}
#ifndef _turboc
\end{verbatim}

with 

\begin{verbatim}
#ifndef __BORLANDC__
\end{verbatim}

\section{Can I use DJGPP with wxWindows?}

Looking hopeful: there is now a Windows 3.1 version of RSXDK which
allows limited 32-bit Windows compilation under Windows using
DJGPP. This is being checked out by Arjen Duursma (arjen@capints.uucp)
and I'll be looking at it again too. The main problem at present
is the lack of common dialog functionality (commdlg.dll hasn't be
encapsulated using RSXDK). The user will then just need
windows.h and the Windows resource compiler, rc.exe, which
will need to be obtained legitimately. It's possible that
windows.h could somehow be reconstructed but there still be
a copyright problem.

Here is my reply to a recent enquiry on this subject before
I knew about the latest version of RSXDK.

\begin{verbatim}
Date: Mon, 3 Apr 95 11:30:55 BST
From: Julian Smart <jacs@aiai.ed.ac.uk>
Subject: Re: wxwindows and DJGPP
To: Ralf Kleineisel <kleineis@astro.uni-wuerzburg.d400.de>

> Dear Mr Smart,
> 
> I find the wxWindows software a very
> interesting item. In short: it is
> exactly what I was looking for.
> My problem is: I use the DJGPP port
> of GNU C++ to DOS as compiler and as
> far as I could make out from the FAQ
> it's not possible to make the two
> work together.
> This is really a pity, because a free
> windows library is what DJGPP lacks
> and a free C-compiler is what wxWindows
> lacks.

Hi,

I absolutely sympathize with this viewpoint, and I do wish that the
FSF (or somebody) would look at making a Windows-compatible version of
the compiler. The fact that it hasn't been done yet (or rather, was
partially done for Windows 3.0 but not done for Windows 3.1) might
suggest that the problem is not a simple one.

I did try out a kit which was a half-hearted attempt by someone to make
DJGPP work with Windows (3.0) but it just wouldn't work with Windows
3.1. Another problem with DJGPP is its lack of debugger.  Windows
debuggers are notoriously hard to write which is why there have been
very poor ones even in commercial compilers.

I think, unfortunately, that such a project would take a lot of
resources, and it might be hard to play catch-up with the facilities
that are required for new versions of Windows. It's certainly well
beyond my capabilities (let alone time constraints) to make DJGPP work
with Windows...

You could try badgering FSF about this but nothing's going
to change soon. A _real_ alternative is to use something like
wxPython, which is a rapidly emerging combination of
the object-oriented language Python, and most of the wxWindows
API. It's fast, and it's interactive (no compiler needed)
so you might find it more productive than C++. See our
WWW pages for more details.

I agree that the lack of a Windows compiler leaves a large gap in the
world of free software but I fear that gap will remain until someone
with a lot of expertise and a lot of time on their hands decides to do
something about it. Meanwhile, you might look at some of the cheaper
Windows compilers (you can get 'limited editions' at under 100 pounds).
My strongest recommendation would be the full MS VC++ 1.5; failing that,
the cut-down standard edition should do (but you'd have a small amount
of fiddling to do to use the IDE with wxWindows).

Regards,

Julian
\end{verbatim}

\section{Compiling Sun dynamic libraries}

\begin{verbatim}
From: Frank Brueggemann <fjb@newton.fb5.uni-siegen.de>
Date: Fri, 17 Mar 95 09:07:35 +0100
To: wxwin-users@aiai.ed.ac.uk
Subject: Re: Dynamic libraries on Sparc question from Keith

Yesterday my colleague Dominik and I succeded in compiling 
wxwin as a dynamic library with gnu 2.6.3 and libg++ 2.6.2 for
SunOS 4.1.3. and openwin 3.0.

The behaviour mentioned is a normal result of the dynamic library system,
but it not so obvious at the first moment. It took some time for us 
to figure out what to do. SUN distinguishes between funtional shared
libraries (so called .so files) 
and libraries that exports initialized data (so called .sa files).

If you wish using the wxwin library as a dynamic library you have to
create a libwx_??.sa file too. This is necessary because the files
    src/base/objects_ol/wb_main.o \
    src/base/objects_ol/wb_obj.o \
    src/base/objects_ol/wb_types.o \
    src/x/objects_ol/wx_main.o 
contain such global data. Thus you have to use a command like
ar rv libwx_ol.sa.0.0 \
    src/base/objects_ol/wb_main.o \
    src/base/objects_ol/wb_obj.o \
    src/base/objects_ol/wb_types.o \
    src/x/objects_ol/wx_main.o 

to build this library in addition to the libwx_ol.so.0.0.

I think the compilation is very similar on the SOLARIS OS.
If you need further details please reply.
\end{verbatim}

\section{I get a link error under SunOS: the symbol XtShellStrings is resolved.}

Tako Schotanus (sst@bouw.tno.nl) writes:

\begin{verbatim}
I was finally able to solve it by adding the following define
to "make.env" :

  -DXTSTRINGDEFINES

This has the effect that whenever there's a reference in the
sourcecode to XtN..... (XtNiconName for example) a #define with
the proper string will be used instead of a global array containing
the names.

System: SunOS 4.1.3
libXt:  4.10
gcc:    2.5.8
\end{verbatim}


\section{Under AIX, wxTheApp does not initialize properly and causes a wxWindows error message.}

After getting wxWindows 1.61 (b) to compiler under AIX, Dirk Eller writes

\begin{verbatim}
The major problem was the initialisation problem of the wxApp-object
also reported in install/install.txt.
The fix:
  #ifdef __aix
  extern wxApp *wxTheApp=1;
  #endif
doesnt work on my system. It looks also very bad ?

After a little testing I figured out that wxApp isnt initialized at the time
when main() (->wxEntry) is called.
The fix is to move the call of main() to the file where the global object
is supposed to be created. (e.g. hello.cc)

The reason is that (stroustroup) c++ compiler does not HAVE to create a global
object before main, but only before any functions are called in the file that
the object is in. (thanks Eugene)
The fix is not very elegant, but it works. 
\end{verbatim}

\chapter{C++ issues}

\section{How can I have class member functions as callbacks
for buttons?}

Here's some correspondence on the subject.

\verbatiminput{members.txt}
%
\section{How can I display debugging messages?}

If you use the function wxDebugMsg, messages will be displayed on either
the standard error stream (X) or the debugging stream (Windows). To read
these messages under Windows, you must either be running a debugger,
or (perhaps more convenient), using a program such as Microsoft's DBWIN
which displays these debugging messages in a text window.

Using DBWIN on a regular basis has the advantage of showing up some GDI
errors that you might otherwise miss, but that could cause severe
problems in future. DBWIN is available in the Windows SDK or
on the Developer's Network CD-ROM, and probably by ftp from Microsoft's
site.

\chapter{Platforms}

\section{Is there a Mac version of wxWindows under development?}

Bill Hale \verb$<hale@mailhost.tcs.tulane.edu>$ is working on this. Here's
his response to a recent email on the subject:

\begin{verbatim}
I have been working on the Macintosh version of wxWindows since June [1994].

The Macintosh version handles most of the methods for wxFrame, wxPanel,
wxCanvas. It also handles wxMenu, wxMenuBar, wxMenuItem, and wxCheckBox.
The wxCanvasDC can draw point, line, and rectangle.

For the first release version, I don't intend to do wxSlider, wxTimer,
wxPathList, wxClient, wxConnection, wxPostScriptDC, wxMetaFileDC,
wxForm, wxHelpInstance, wxMetaFile, wxServer. Some methods in other
classes may also not be implemented.

I'm trying to get a working version that does most of the standard
functions. Then, I will upload it so that we can discuss what changes
are necessary to make it conform with the guidelines for wxWindows.

I hope to have something ready by the beginning of September [1994], at least
for discussion purposes.
\end{verbatim}

{\bf Update, December 1994:} you can now pick up a partial Mac version of
the `hello' demo, plus Bill's work so far, from our ftp site in
/pub/wxwin/ports/mac.

\section{Is there an X version of wxBuilder?}

Sort of... the XView version needs some work, particularly because there
are occasions when 2 levels of modal dialogs are used, which XView doesn't
like.

The Motif version is coming on well and will be released (a binary for Suns and HPs)
by the end of September.

\chapter{Run-time problems}

\section{Why does the XView file selector crash?}

\begin{verbatim}
> Hi, I compiled wxwin 1.61 beta with gcc 2.6.3 on a Sun sparc.  Everything work
s
> except in the hello demo when I try to open the file selector the program 
> crashes.  Any clue on this is appreciated. (The same problem does not
> occur using gcc 2.4.5. Also I use motif 1.2.)

I had the same problem.  I believe it is *not* the fault of wxWindows.
Instead, the problem appears to lie in the librx (regular expression)
code that is distributed with the most recent version of libg++
(2.6.2?) -- at least, that's where it's crashing.

What I did was to delete all the librx code and all references to it
in the libg++ makefiles, then recompile libg++.  (Just for safety's
sake, I recompiled the wx library as well; I wasn't sure whether it
would have picked up any of the librx code.)  When you relink your
application, the regular expression code in the system libraries will
be used instead.  File selectors now work fine for me.

You may be able to achieve the same effect by making sure that libg++
is the absolute *last* library searched by your compiler (after the
system libraries, in particular), but I haven't tried this.

-------------------------+----------------------------------------
   //  Scott Maxwell:    |  
\\//      maxwell@       | ``Unlike most of you, I am not a nut.''
 XX natasha.jpl.nasa.gov |     -- Homer Simpson
\end{verbatim}

\section{How do I install CTL3DV2.DLL correctly?}

A program that uses CTL3DV2.DLL must be installed so that
the DLL is in the windows/system directory, and NOT in
the application directory, or it will not run correctly.

It is tempting to copy CTL3DV2.DLL into as many directories
as possible to hedge your bets. Unfortunately this is exactly
the wrong thing to do: the DLL must be in windows/system, ONLY.

CTL3D.DLL is not required if you're linking with CTL3DV2.LIB:
it's the old version.

\section{Why does my program exit abnormally with 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
\rtfsp{\bf OnInit} is called, these objects may be created with impunity.

\section{After using memory DCs and bitmaps under Windows, I get system crashes.}

Here's some correspondence that helps explain this phenomenon and its
solution.

\begin{verbatim}
From: Markus Meisinger <Markus.Meisinger@at.ac.uni-linz.risc>
Message-Id: <199406241203.AA09143@melmac.risc.uni-linz.ac.at>
To: wxwin-users@ed.aiai
Subject: SOLUTION to strange problems of yesterday
Status: RO

hi wxWindows programers

i wrote yesterday:

>I have encountered some strange problems with the sample programs under
>MS-WINDOWS 3.11. (they work fine under UNIX/LINUX)
>
>The problems arise if i e.g quit the minimal sample program. During the run
>of the program no problems appear. But after it stops than the whole
>system crashes (not always, but quite often :)!
>
>If the system crashes, not only the sample program produces an
>UNRECOVERABLE APPLICATION ERROR, but also the most other programs running
>at the same time (PROGMAN, FILEMAN, WINMETER, ...) stop their work with
>a severe error. :(
>
>Any help would be greatly appreciated! Or is there a patch available, because
>a guess their is a bug in freeing the system resources ...

The actual problem causing the strange behaviour was a buggy wxWindows program
of mine running some minutes before and not the sample programs, CTL3D or
FAFALIB

Because i used a wxMemoryDC in which i selected a dynamicaly created bitmap.
During the quiting process i freed this bitmap which was selected in the
wxMemoryDC. But wxWindows also freed this bitmap during deleting the DC and
... the rest you know

SO, BE AWARE IF YOU DELETE BITMAPS! 

Never delete a bitmap which is selected into a DC if the DC will be deleted.
The bitmap will be deleted by the DC!
But i did it !!! :) and it resulted in a system wide crash of MS-WINDOWS
(in Motif it works fine (why?))
The funny thing with this crash is that the system doesn't immediately crash,
instead it works fine for a few minutes until ANY other program gets into
some memory conflict. After this application error each program still running
complains problems with the memory and stops. The last thing you see is
the standard windows background color (if you are lucky:)
I never saw such a system wide crash WOU :) in some sense it was funny :)

Hope you don't make the same errors as i did!

Markus
\end{verbatim}

\section{Why do panel items not size or position correctly under Motif?}

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 {\bf wxABSOLUTE\_POSITIONING} to the panel constructor,
in which case a Motif bulletin board widget will be used instead of a form widget.

{\it NOTE:} from wxWindows 1.60, the wxABSOLUTE\_POSITIONING flag is
obsolete, because all Motif positioning is now done this way.

One reason for a widget not appearing can be that the widget
is sized just too big for the panel, and then Motif gets very
confused. Try reducing the size of the widget.

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

Widgets that are too close together may cause problems.

\subsection{Possible cure for some Motifs}

Some Motifs under some platforms appear to have very bad panel item
problems in dialogs. Once cure seems to be to change the resize policy
in src/x/wx\_dialg.cc: find where two lines are marked TROUBLE SPOT (from 1.61 beta 2),
in the 'else' clause of the 'invisibleResize' condition. One line has XmRESIZE\_ANY,
the second has XmRESIZE\_NONE.

Comment out or uncomment the first line, and uncomment or comment out
the second line (whichever is not already the case). However, doing this
seems to make a dialog box's size change dynamically when (for example)
a listbox next to the dialog box edge is updated; so only change this if
absolutely necessary.

\section{Under Motif, the status line does not appear.}

The fix seems to be to call Fit before calling CreateStatusLine,
or try calling SetSize after frame creation.

\section{Under Windows, dialog boxes refuse to appear. Why?}

You probably forgot to include the file wx.rc in your resource script
This is required for dialog boxes to work correctly.

\section{Under Motif, quitting windows from the File menu causes a crash.}

There is a bug in the X toolkit that manifests itself on some platforms.

Here's a bug fix from Jim Huggins:

\begin{verbatim}
I've been investigating this problem for the last few
weeks.  (where the problem is:  closing child window
in motif causes core dump.)

The core dump stack is usually:

>0  0x3ff80c5f8e4 in InSharedMenupaneHierarchy() RowColumn.c:6759
#1  0x3ff80c5fc44 in SetCascadeField() RowColumn.c:6849
#2  0x3ff80c6d924 in MenuProcedureEntry() RowColumn.c:11685
#3  0x3ff80bd0a88 in Destroy() CascadeBG.c:2350
#4  0x3ff803c9d3c in Phase2Destroy() Destroy.c:113
#5  0x3ff803c9c04 in Recursive() Destroy.c:72
#6  0x3ff803c9b94 in Recursive() Destroy.c:60
#7  0x3ff803ca0b8 in XtPhase2Destroy() Destroy.c:205
#8  0x3ff803ca220 in _XtDoPhase2Destroy() Destroy.c:252
#9  0x3ff803d1a90 in XtDispatchEvent() Event.c:1127
#10 0x120026b7c in ((wxApp*)0x1400011b8)->MainLoop() wx_main.cc:177

>From what I can tell, this is a bug in an older version
of Xt library version X11R5.  I think there was a patch
for it but I have no idea what number or when it was produced.

The bug has to do with recursive destruction of Menu widgets.
(I don't know too much detail...)

I tried posting a note to comp.windows.x.intrinsics and didn't
get any working fixes or explainations.  (My idea about a Xt bug
and possible patch comes from a note I found in an internal DEC
notes conference.)

I found a work around for this problem in wxWindows though:
in file srx/x/wx_item.cc

add the follow code to the bottom of function wxMenu::~wxMenu(void)
(I think around line 1070)

#ifdef wx_motif
  if (handle) {
      DestroyChildren();
      wxWidgetHashTable->Delete((long)handle);
      Widget w = (Widget)handle;
//     XtDestroyWidget(w);
      handle = NULL;
  }
#endif

This is basically doing what the ~wxWin function would have done
except the XtDestroyWidget(w) has been commented out to avoid
the Xt bug.  (i.e. if you uncomment that line above, the core dump
will occur.)

Jim
\end{verbatim}

\section{Under XView, I get a SERVER\_IMAGE\_BITMAP\_FILE warning mesage.}

{\tt 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 reference manual's {\bf wxIcon} class entry).

\section{Under Windows, 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 {\it 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 {\it 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 {\it Iconize(FALSE)} to restore the
window. This at least avoids seeing half-painted windows whilst
things get initialized.

\section{Functions that return string values cause strange behaviour
on some platforms.}

To resolve the question of who is responsible for allocating and
deallocating memory, wxWindows maintains a policy (unless
documented otherwise) of returning a {\it temporary} pointer
to a static string buffer from functions such as {\it wxText::GetValue}.

If you don't immediately take a copy of this value, it's possible that
subsequent wxWindows calls will use the same memory, causing
unpredictable results. This tends to be more the case under Windows than
other platforms, where pointers to internal XView or Motif widget
strings are often returned.

\chapter{What you {\it can't} do in wxWindows}

There are many exceptions and provisos in the wxWindows API, mostly
because the individual platforms don't support some functionality,
or it hasn't yet been implemented, or some other reason. These
exceptions are being eliminated where possible, but inevitably
some will remain.

This section will start to give an at-a-glance guide to what {\it not}
to try, and perhaps save some grief.  It is not a complete list though.

\begin{description}
\item[Fonts in panel items.] XView doesn't allow you to
set panel item fonts individually.
\item[wxTextWindow::OnChar.] XView doesn't allow interception
of character input in a text subwindow.
\item[OnSetFocus, OnKillFocus.] Not called for panel items (yet).
May not be called for other windows either; beware.
\item[Bitmaps and arcs in PostScript device context.] The PostScript device
context does not support drawing bitmaps, or arcs.
\item[Menu items cannot be deleted dynamically.] Dynamic menu item deletion
has not been implemented. It is not technically infeasible on any known
platform, though.
\item[Custom cursor creation.] Not yet implemented.
\item[Bitmap buttons.] Bitmaps loaded dynamically from .BMP or .GIF
files under UNIX, cannot be used for bitmap buttons yet. XBM and XPM
files should work fine meanwhile.
\item[OLE-2.] Not supported, although a document/view architecture
is being worked on that should be a step along the road towards supporting
OLE-2 and/or OpenDoc.
\end{description}

\begin{comment}
\begin{helpglossary}
\setheader{{\it GLOSSARY}}{}{}{}{}{{\it GLOSSARY}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%

\gloss{API}

Application Programmer's Interface - a set of calls and classes defining
how a library (in this case, wxWindows) can be used.

\gloss{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
{\it device context}\/ associated with it.

\gloss{DDE}

Dynamic Data Exchange - Microsoft's interprocess communication protocol.
wxWindows provides an abstraction of DDE under both Windows and UNIX.

\gloss{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.

\gloss{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.

\gloss{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.

\gloss{GNU C++}

A free, solid C++ compiler which may be used to compile the UNIX side of
wxWindows applications.

\gloss{GUI}

Graphical User Interface, such as Windows 3 or X.

\gloss{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.

\gloss{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.

\gloss{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.

\gloss{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.

\gloss{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).

\gloss{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
{\bf hello} demo). XView has a status line (or footer) capability, but
wxWindows implements the feature explicitly under Windows 3 and Motif.

\gloss{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.

\gloss{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.

\end{helpglossary}
\end{comment}
\newpage
\addcontentsline{toc}{chapter}{Index}
\printindex
\end{document}