\documentstyle[a4,makeidx,verbatim,texhelp,fancyhea,mysober,mytitle]{report}%
%\input psbox.tex
\parskip=10pt%
\parindent=0pt%
\winhelpignore{\title{Hardy Frequently Asked Questions Version 3.0}
\author{Julian Smart\\Artificial Intelligence Applications Institute\\
University of Edinburgh\\EH1 1HN}
\date{July 1994}
}
\winhelponly{\title{Hardy Frequently Asked Questions Version 3.0}
\author{by Julian Smart, Artificial Intelligence Applications Institute,
University of Edinburgh\\$$\image{0cm;0cm}{hlogo.bmp}$$}
}%
\makeindex%
\begin{document}%
\maketitle%

\pagestyle{fancyplain}
\bibliographystyle{plain}
\pagenumbering{roman}
\setheader{{\it CONTENTS}}{}{}{}{}{{\it CONTENTS}}
\setfooter{\thepage}{}{}{}{}{\thepage}
\tableofcontents%

\chapter{About this document and the SDK}%
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter}}{}{}{}{}{{\it CHAPTER \thechapter}}%
\setfooter{\thepage}{}{}{}{}{\thepage}

This document is a list of frequently asked questions, or questions that
might very well be asked, about developing custom Hardy applications,
with answers and pointers to further information. It accompanies the
Hardy Software Development Kit (SDK), which contains sample CLIPS
and C++ files.

The first port of call for the Hardy developer is of course the user manual,
which contains the Hardy and GUI CLIPS function reference, and a small
introduction to programming in Hardy.

Other documents available are the CLIPS 6.0 manual (written by NASA),
and a CLIPS 6.0 Windows Help file containing a terse syntax summary.

Note that some of the examples use function names that don't correspond
to the Hardy CLIPS function reference. This is because they use an
old naming scheme, which is still valid for backward compatibility.
Please refer to the document \helpref{old2new.txt}{old2new} which lists old and new
function names.

\section{Using the SDK samples}

Under Windows, you can partially automate the installation of CLIPS
samples into the Program Manager, by inserting similar lines to
the following into the \verb$[Extensions]$ section of WIN.INI:

\begin{verbatim}
clp=c:\hardy\hardy.exe -clips ^.clp
ind=c:\hardy\hardy.exe -f ^.ind
\end{verbatim}

Change this to reflect where Hardy is installed on your system.
Then, (re)start the File Manager, and drag .clp files (usually
with 'load' in the filename) from the File Manager to the
Program Manager.

If the sample includes an index file, you can add -f and a filename
to the Program Manager item, or load the index manually from Hardy.

If you create new Program Manager items manually, fill out the fields as
follows, changing the text to suit your setup:

\begin{verbatim}
Description:         Drag Test
Command line:        c:\hardy\hardy.exe -clips dragload.clp
Working directory:   c:\hardy\hardysdk\clips\drag
\end{verbatim}

Setting the working directory is important.

Under UNIX, change your working directory to the sample
directory, and invoke Hardy with appropriate command line
arguments (see above).

\section{Contents of the SDK}

\verbatiminput{readme.txt}
%
\section{old2new.txt}\label{old2new}

This file lists old and new function names.

\verbatiminput{old2new.txt}
%
\chapter{General questions and answers}%
\setheader{{\it CHAPTER \thechapter}}{}{}{}{}{{\it CHAPTER \thechapter}}%
\setfooter{\thepage}{}{}{}{}{\thepage}

\section{What are the hardware and software requirements for running Hardy?}

Under X:

\begin{itemize}\itemsep=0pt
\item About 10 MB of disk space (more if the static Motif executable is used).
\item A Sun workstation with 16MB or more of RAM.
\item Solaris 1.x or 2.x.
\item If the static version is not being used, then the versions of the Motif, X11 and Xt
libraries must agree with Hardy's expectations: can be hard to get right. Hint: symbolic linking
from what Hardy expects to what you have installed sometimes work, as does setting LD\_LIBRARY\_PATH.
\end{itemize}

Under Windows:

\begin{itemize}\itemsep=0pt
\item About 4MB of disk space.
\item 486 or better processor.
\item 8MB RAM minimum, preferably 16MB.
\item Windows 3.x, Windows 95, Windows NT or (at a pinch) OS/2 with Windows
emulation. Sun's WABI Windows emulator probably won't do.
\end{itemize}

Note that under Windows, there is a choice of executables: 16-bit, generic 32-bit (will work under
NT, Windows 95, WIN32s) and Windows 95 (only works under Windows 95).

A Mac port is in progress and is expected around July 1996. For UNIX platforms other than
Sun, please contact AIAI for a quote for porting Hardy.

\section{Why is a diagrams.def file needed?}

Hardy needs to know what diagram type definitions, hypertext type definitions,
and symbol libraries to load before any indexes or diagrams can be loaded
or created. This list of definition files enables you to switch between
`applications' by loading different sets of definition files.

\section{Why is there no Undo facility?}

Because it's very difficult! There have been many requests for such
a facility, and I am thinking about how I would implement it.

\section{How can I create new symbols for Hardy?}

There are two main methods for create new symbols: use the node symbol editor
and combine existing symbols using consraints; and converting Windows metafiles
to Hardy symbols.

A convenient (at present, only) way of creating suitable metafiles is to
use the shareware package TopDraw, available from our ftp site.
This generates suitably simple metafiles for Hardy to recognise. There are
heavy restrictions on the complexity of the metafile: no clipping areas are
allowed, no text, no bitmaps, no arcs (except for those made up of lines).

If people have success with other metafile-generating packages, I would be
interested to know about it.

\section{What languages can I use to develop Hardy applications?}\label{languages}

The main supported language is CLIPS, which is integrated with Hardy
and supports an interactive style of development. C++ is supported
inside AIAI, using the header file {\it hapi.h} and a library file.
Unfortunately we cannot distribute the library file or source code outside
AIAI. See \helpref{Using CLIPS}{using_clips}.

The \helpref{DDE}{interprocess} facility can be used to call Hardy functions from
other programs under Windows.

\section{What have wxWindows and wxCLIPS got to do with Hardy?}\label{wxwindowswxclips}

wxWindows is the portable, C++ GUI toolkit used to implement Hardy. Many of
the classes have been encapsulated in CLIPS functions (used in an object-oriented
manner, with integer identifiers replacing object pointers). This
package is known as wxCLIPS, and is both a stand-alone CLIPS development
environment, and a library that has been linked with Hardy to provide
the GUI functionality.

wxWindows and wxCLIPS were written at AIAI, and are both available
free of charge by anonymous ftp from:

\begin{verbatim}
ftp.aiai.ed.ac.uk
\end{verbatim}

in the directories /pub/packages/wxwin and /pub/packages/wxclips.

\section{How can I write a customized installation procedure under Windows?}

Use the wxWindows installation program, the latest version of which
may be found in :

\begin{verbatim}
ftp.aiai.ed.ac.uk:/pub/packages/wxwin/tools/install
\end{verbatim}

It can also be found in the SDK install directory, but may not be as up to date.

You edit a file called install.inf to specify destination directories, program
manager icons, compression method and so on.

\section{How can I customize the Hardy startup screen under Windows?}

Put the files hystart.bmp and hystart.txt in a directory
accessible by Hardy. hystart.bmp should be a 16-colour
Windows bitmap 255 pixels or less in width and height;
hystart.txt should contain a number of lines of text for
the dialog text. If these files are not found, the
Hardy defaults will be used.

Unfortunately, the Hardy icon cannot be customized at present.

\chapter{Using CLIPS}\label{using_clips}%
\setheader{{\it CHAPTER \thechapter}}{}{}{}{}{{\it CHAPTER \thechapter}}%
\setfooter{\thepage}{}{}{}{}{\thepage}

For the sake of brevity, the following discussion assumes that CLIPS
is being used to customize Hardy. If C++ is being used instead,
most of this applies, except... when it doesn't (which should be
fairly obvious).

\section{Is CLIPS free?}

This is a matter of continuing debate. It is free in the United States,
but there are some claims by the official distributor COSMIC that
outside the U.S., source code should be purchased for a nominal price.
In fact, CLIPS is distributed with many CD-ROMS and at least one book,
and is also available by anonymous ftp.

AIAI have written confirmation from COSMIC that there are no copyright
problems associated with the Hardy version of CLIPS.

\section{Is CLIPS any good? What about file-handling, and so on?}

Built-in macro languages are sometimes viewed with suspicion, since
they may not have all the flexibility of `doing it in C'. Fortunately,
CLIPS is a well-developed language with functions, objects, templates,
rules, facts, I/O facilities, and a large set of mathematical functions.
There are GUI extensions that allow fairly complex user interfaces and
graphics to be constructed, which will need little or no change on other
Hardy-supported platforms.

It's unlikely that CLIPS would prove too unwieldy or lack sufficient
functionality for your application. If it did, you could fall back on
C++, or with a little help from us, implement your own CLIPS functions
to do intensive or specialist work.

\section{But CLIPS is an A.I. language. How does that affect me?}

It needn't affect you in the slightest, in that CLIPS was originally
integrated with Hardy purely for the functions, as an extension
language. The fact that it is also a rule-based shell was deemed
irrelevant; after consideration of the alternatives, CLIPS was
found to be the most portable, easily-tailorable language
available.

The rule-based part of CLIPS is a bonus, and may be used solely or
sparingly as the need arises. It's worth considering as a useful pattern
matching facility.

Here is a rule-based example (see CLIPS/RULES on the SDK disk).

\subsection{Animal demo}

\verbatiminput{../clips/rules/animal.clp}
%
\section{How do Hardy and my CLIPS code communicate?}

Hardy and CLIPS are essentially two big chunks of code linked together,
in the same process space. In normal use, CLIPS code only executes in
two situations: when Hardy is started up, using the -clips command,
and when certain {\it events} call your code.

At startup, the CLIPS custom code is given a chance to load files,
and initialize before returning control back to Hardy.
The C++ equivalent of this is defining the function {\it gyInitializeCustomCode}\rtfsp
for Hardy to call at startup.

The user will also want to register {\it event handlers} (either CLIPS
or C++ functions) which will be called by Hardy when the specified
events happen. The CLIPS function {\it register-event-handler} is
used to specify a context (for example ``Toplevel'' or a user-defined card type),
an event name, and the function name (CLIPS) or address (C++).

For example, the following registers interest in the CustomMenu
event for diagrams of type ``bsdm'', so Hardy will call
the function {\it test-event-handler} when the user selects
an item on the custom menu.

\begin{verbatim}
; We are interested in CustomMenu events for BSDM demo diagram type
(register-event-handler CustomMenu "bsdm" test-event-handler)
\end{verbatim}

During a callback, custom code will probably call back into Hardy
by means of the Hardy CLIPS functions.

Apart from the simple developer's window, there is no other way in which
Hardy and CLIPS are related; no object-oriented association between
diagrams and chunks of code. Everything is essentially global, and code
must explicitly register interest in particular events in particular
contexts.

Here's an example of an application that intercepts menu and
left-click events to allow very quick construction of tree diagrams.

\subsection{Tree demo code}

\verbatiminput{../clips/tree/tree.clp}
%

\subsection{Tree demo loader}

\verbatiminput{../clips/tree/treeload.clp}
%
\section{Why does it take so long to load CLIPS code into Hardy?}

There are two ways of loading CLIPS code: {\it batch} and {\it load},
each with a entry on the developer window File menu, and a function
equivalent.

{\it batch} executes {\it all} possible CLIPS commands and construct definitions,
but doesn't do much checking of constructs. It is slow.

{\it load} only recognises CLIPS constructs such as {\it deffunction}, as
opposed to function calls. It is relatively fast.

Therefore, the recommended practise is {\it not} to batch all CLIPS code:
instead, have a small file contains several further {\it load} commands,
and a few function calls (such as {\it register-event-handler}). This
`loader' file can be batched or used as the command line with {\tt -clips},
so the minimum possible amount is subject to the slow batch reading.

Another reason for a slow-down is because tracing is on. See\rtfsp
\helpref{Slow execution}{slowexecution}.

Here's a demo loader file that should be {\it batched} but calls\rtfsp
{\it load} to load most of the program.

\subsection{Loader example}

\verbatiminput{../clips/reports/loader.clp}
%
\section{Is there an Integrated Development Environment for Hardy?}

No, but under Windows there's the next best thing: the ability
to execute some of the Developer Window functionality
from a DDE program. The program editor/ddesend.exe
allows the user to load and batch the current buffer, by defining a macro which
calls ddesend.exe with an appropriate command line.

The DDE client (of which ddesend.exe is an example) must connect to the
server using the service name HARDY, and establish a conversation on
the HARDY topic.

The file editor/macros.rc is a sample MicroEMACS for Windows macro
file, that implements commnds for loading files into Hardy, and executing CLIPS
commands, from within MicroEMACS, using ddesend.exe.

Here are some examples of Hardy DDE commands. They consist of a letter,
a space, and then some data.

\begin{verbatim}
L c:\example.clp
B c:\example.clp
E (app-on-init)
Q
C
\end{verbatim}

Here is a list of commands that Hardy recognizes:

\begin{itemize}
\itemsep=0pt
\item L: load the given file of constructs into CLIPS
\item B: batch the given file of constructs into CLIPS
\item E: execute the given command
\item C: clear the Hardy development window
\item Q: quit Hardy
\end{itemize}

%
\section{Why is execution sometimes slow?}\label{slowexecution}

It could be because tracing is enabled, and lots of text is being
output on the development window. Try calling

\begin{verbatim}
(unwatch all)
\end{verbatim}

\section{Sometimes CLIPS callbacks fail to execute. Why?}

There is a condition that can occur when a CLIPS command has failed;
subsequent attempts to run the code cause FALSE to be displayed,
then nothing further happens. You may have quit Hardy and rerun
occasionally during your development. {\it Note:} this has now
been cured (as of late 1995).

\section{How can I have a custom menu on the Hardy control window?}

There isn't a convenient user interface for doing it, but you can create such a menu by inserting
lines like these in the {\tt diagrams.def} definition list:

\begin{verbatim}
custom(custom_menu_name = "&Custom options",
  custom_menu_strings = ["&First item", "&Second item"]).
\end{verbatim}

Then use the ``CustomMenu'' event for the ``Toplevel'' context. See the
manual entry for {\it register-event-handler} for further details on events.

\section{What facilities are available for generating reports?}\label{reports}

The one-word answer to this is, `none'. A better answer is that the Hardy
allows total report-generating flexibility via CLIPS. There are no {\it
built-in} facilities that allow instant document generation from a
hypertext index or diagram hierarchy.

The reason for this is that it is unlikely that a generic facility would
be sufficient for all possible uses of Hardy. Instead, the Hardy
application programmer can write report generators using CLIPS or C++
code. There are several Hardy functions that help you in this task, such
as {\it diagram-card-save-metafile}.

The easiest approach is probably to generate a \LaTeX\ file. Why \LaTeX?
Because it is a relatively simple format to generate, and can be
converted into various other formats using \helpref{Tex2RTF}{tex2rtf} or similar utility.
Sample code is available in the Hardy SDK that generates a report
with mixed text and diagrams.

On the UNIX platform, the diagrams can be saved in PostScript, \LaTeX\ used
to convert to a .dvi file, and then {\tt dvips} can be used to produce
a PostScript file. The \LaTeX\ macro package {\bf PSBOX} may be used
for incorporating the PostScript files.

Under Windows, Tex2RTF can be used to generate Rich Text Format
(RTF) files, which can be read by most popular word processors. Diagrams
are saved as metafiles by the report writer, as they can be scaled
in the word processor with no adverse effect.

The example CLIPS code demonstrates using DDE to automate the conversion
to RTF and loading into MS Word.

Under Windows there is the additional possibility of generating a
Windows Help file, to produce a read-only, browseable hypertext version
of the Hardy document. This requires the Windows Help compiler (hc.exe
or hc505.exe), available free from various anonymous ftp sites.

Under both Windows and UNIX, Tex2RTF can be used to produce HTML
files for viewing on the World Wide Web. However, at present the
conversion of graphics files to GIF must be done manually, although it
could be automated. Use {\it diagram-card-save-bitmap} to save a bitmap,
and try to find a command-line utility to convert from bitmap
to GIF format (but see \helpref{HTML generation}{htmlgen}).

\subsection{HTML generation}\label{htmlgen}

The HTML directory contains a Hardy application to generate HTML files
for a whole Hardy index (unlike the report generator mentioned above
which only works for diagram hierarchies).

Currently it works under Windows only, because only the Windows version can
save suitable colour bitmaps. To convert the saved BMP files to GIF, the
utility calls a shareware DOS program called {\bf ColorView} which must be in the PATH.
Any other suitable BMP to GIF conversion program could also be used with suitable
changes to the code.

\subsection{If you don't want to generate \LaTeX}

If you really want to generate a native format such as PostScript
and RTF, then that's fine, but be prepared to work long hours!
There are a couple of Hardy functions to help RTF writers:\rtfsp
{\it convert-bitmap-to-rtf}, and {\it convert-metafile-to-rtf}. These
functions convert image files into the hexadecimal RTF data required
by some RTF readers. Note that different RTF readers have different
requirements (Word for Windows can cope with an {\it INCLUDEPICTURE field} that simply
references a metafile on disk, whereas others may require the hexadecimal
data to be embedded in the file).

An RTF specification is available from the Microsoft ftp site, or
from the Microsoft Developer's Network CD-ROM. You can also look at
the source code of \helpref{Tex2RTF}{tex2rtf} for some hints.

\subsection{Where can I get Tex2RTF?}\label{tex2rtf}

The latest version of Tex2RTF can be accessed by anonymous ftp from:

\begin{verbatim}
ftp.aiai.ed.ac.uk/pub/packages/tex2rtf
\end{verbatim}

It is available in SPARC Open Look and Windows 3.1 versions.

Tex2RTF was developed using the free Open Look, Motif and Windows 3.1
C++ class library \popref{wxWindows}{wxwindows}, also available from the
above FTP site in the /pub/wxwin/beta directory.

\section{How can I build customized user interfaces in Hardy?}

For many applications, using simple functions such as {\it message-box},
\rtfsp{\it get-choice}, {\it file-selector} and {\it get-text-from-user} may
be adequate, combined with intercepting custom menu and mouse click events.
But you may find after a while that you need something a little
more complex.

This is where wxCLIPS comes in (see also \helpref{wxWindows and
wxCLIPS}{wxwindowswxclips}). It provides a range of building
blocks for building your own interfaces, including frames, panels,
buttons, list boxes, text windows, canvases, pens, brushes, and fonts.
The demo supplied with the SDK in {\tt CLIPS/GUI} shows off some of
these features.

Here's the simple GUI example.

\subsection{GUI example}

\verbatiminput{../clips/gui/hello.clp}
%
\section{My popup windows make the main window pop up.}\label{popupwin}

If you use frames, dialog boxes convenience dialog functions with no parent window,
Hardy will use the main window. This may then pop up (on some platforms)
and obscure other windows.

To avoid this, pass a valid frame or dialog identifier to the window
you're creating. If the window you want to be the parent is a card,
use {\bf card-get-frame} to retrieve a valid frame identifier. {\it Do not}\rtfsp
use the card identifier itself, this will most likely cause a crash.

\section{How can I keep my code portable between platforms?}

\begin{itemize}
\item When writing GUI code, use relative positioning where possible:
\begin{itemize}\itemsep=0pt
\item don't use absolute values for positions, use -1 for x and y values
\item use {\bf panel-new-line} to space items.
\item use {\bf window-fit} on a panel/dialog box, then on the frame if
there is one, to shrink a window around its contents
\end{itemize}
\item Use {\bf get-platform} to test what platform Hardy is running on, and
execute slightly different code where necessary.
\item When copying diagrams.def and index files between platforms, you may need
to edit the files to eliminate absolute pathnames. Alternatively, use
the {\bf -path} command line option to specify where files will be found;
Hardy will search such paths.
\item Pass valid parent windows to all frames and dialogs (see \helpref{Window problems}{popupwin}.
\item Use short, DOS-compatible filenames (8+3 characters).
\item Use end of line converters where necessary when copying between UNIX and
DOS platforms.
\end{itemize}

\section{What interprocess-communication facilities can I use?}\label{interprocess}

Hardy supports synchronous Dynamic Data Exchange (DDE) under Windows,
and a simulation of DDE using sockets under UNIX.

An external client program can use Hardy as a server, making a connection
and using the {\it execute} DDE command to call CLIPS code, followed
by a {\it request} DDE command to get a return value. Note that this kind
of connection is only available on the CLIPS-enabled version of Hardy, since
an interactive language interpreter is required.

In addition, CLIPS DDE functions are available within Hardy, so a CLIPS
program can make Hardy the client, requesting information from or
sending information to an external application, such as a spreadsheet or
word processor. The report-generating example in the Hardy SDK shows
DDE being used to invoke Tex2RTF and Word for Windows.

Under UNIX, there is an undocumented program called {\it DDEPIPE} that
sites between a normal pipe-aware UNIX application and Hardy. This offers
a simple command interface that translates messages sent to the pipe
into a subset of the simulated DDE protocol required by Hardy.

The DDE facilities available in CLIPS are documented in the Hardy User Guide.
They are a {\it functional} encapsulation of the {\it object-oriented}\rtfsp
equivalent in \helpref{wxWindows}{wxwindowswxclips}, and so further information
can be obtained from the wxWindows manual. Another place to look is Microsoft
documentation and technical notes, plus Charles Petzold's {\it Programming Windows 3.1}.

Here's an example of talking to the Windows Program Manager using DDE. As you
can see, DDE needn't be at all frightening: the example is only a page or so long.

\subsection{ProgMan example}\label{progman}

\verbatiminput{../clips/dde/ddetest.clp}
%
\chapter{Digging into Hardy diagrams}%
\setheader{{\it CHAPTER \thechapter}}{}{}{}{}{{\it CHAPTER \thechapter}}%
\setfooter{\thepage}{}{}{}{}{\thepage}

\section{Why the difference between node and arc {\it objects}, and {\it images}? I'm confused.}

Yes, it can seem bewildering. But there is a reason for this difference. Node and arc {\it objects} are
intended as an internal, not displayed, representation of a diagram: they contain {\it attributes},
and are typed. Node and arc {\it images}, on the other hand, merely reflect these objects visually:
there may even be two or more images for the same object, perhaps at different levels of a hierarchical
diagram. Images can be hyperlinked to other cards, objects can't be.

\section{What is the relationship between item and image?}

An {\it item} in Hardy-land is a generic concept for `something on a card'. Therefore an
image on a diagram card is an item, and so is a block of text on a hypertext card. You'd expect
to be able to do similar things with items of different kinds, and so you can -- any item
can form a hyperlink with any other item. In addition, there are non-visual items: the {\it special
item} that exists on each card, to form hyperlink relationships in the absence of a visual item
such as a text block or diagram image.

Fine, as far as the user is concerned. An item is an item is a block, or an image. {\it But} for
the programmer, things are a little different: items are separate entities, with different
identifiers. For any image or block, there is one item. It is {\it this} identifier you must use
to form or follow hyperlinks. There's a good reason for this separation, to do with being able
to examine items and links when card contents are not loaded. The distinction means
explicitly getting an image's item id, or an item's image id, using the appropriate Hardy functions.

\section{Can I access the diagram type definition from CLIPS?}

No, at present there aren't any functions for accessing or changing the type definitions. The only
way to create new ones programmatically would be to write them to file and have the user load them
in (or write to the diagrams.def list of definitions).

However, when examining diagram structures, you can query the type of
node and arc objects (using {\it diagram-object-get-string-attribute} with
a ``type'' as the attribute name) and the diagram type (using {\it card-get-string-attribute},
again with ``type'' as the attribute name).

\section{Can I have attributes of different types?}

No, only string attributes are allowed, but you can convert different CLIPS types to and from strings.

\chapter{Hardy bug list}

The following is a (probably incomplete) list of the known Hardy bugs and problems. Please contact us
if you find any more.

\section{All platforms}

\begin{description}\itemsep=0pt
\item[Duplicate images] Duplicate images can occasionally cause problems with crashes,
and when deleted can cause removal of arcs connected to images for which this is duplicate.
Please use this facility with caution.
\item[Crash when deleting cards] If you delete a card hierarchy, and have event handlers
that might (implicitly) expose a card whilst it was being deleted, a crash can result.
Try to disable as many event handlers as you can whilst a card is being deleted
(e.g. by setting a global variable from within a DeleteCard event handler).
A card can get exposed (a physical window created for it) by calling a function such as
diagram-card-clear-canvas when the card is not shown.
\end{description}

\section{X only}

\begin{description}
\item[Asynchonicity problems] Due probably to the asynchonous nature of X, it is dangerous
to do a lot of programmatic creation and deletion of windows in sequence. For example,
highlighting a window to load a diagram from disk, then immediately deleting the
window, seems to cause a crash (the canvas refresh occurs even though there's no
canvas any more). Try to split these actions up if you are getting a crash, such that
the user must initiate more actions manually (using a timer might help, also).
\end{description}

\section{Windows only}

\begin{description}
\item[Modal lockout] It has been reported that it is possible to push a dialog box
behind the Hardy window and not get it back again, so Hardy is stuck in a modal loop
until Windows is terminated. Using parent windows for all dialog boxes should alleviate
this problem.
\end{description}

\begin{comment}
\bibliography{refs}
\addcontentsline{toc}{chapter}{Bibliography}
\setheader{{\it REFERENCES}}{}{}{}{}{{\it REFERENCES}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
\end{comment}

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

\gloss{GUI}

Graphical User Interface, such as Windows 3 or X.

\gloss{HTML}\label{html}

Hypertext Markup Language; an SGML document type, used for providing
hypertext information on the World Wide Web, a distributed hypertext
system on the Internet.

\gloss{\LaTeX}\label{latexgloss}

A typesetting language implemented as a set of \TeX\ macros. It is
distinguished for allowing specification of the document structure,
whilst taking care of most layout concerns. It represents the opposite
end of the spectrum from WYSIWYG word processors.

\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. A placeable metafile
is a metafile with a 22-byte header which can be imported into several
Windows applications, and is a format used by the Microsoft help compiler.

\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{RTF}\label{rtf}

Rich Text Format: an interchange format for word processor files,
used for importing and exporting formatted documents, and as the
input to the Windows Help compiler.

\gloss{wxHelp}\label{wxhelp}

wxHelp is the hypertext help facility used to provide on-line
documentation for UNIX-based wxWindows applications. Under Windows 3.1,
Windows Help is used instead.

\gloss{wxWindows}\label{wxwindows}

wxWindows is a free C++ toolkit for writing applications that are
portable across several platforms. Currently these are Motif, Open Look,
Windows 3.1 and Windows NT.

\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}

\rtfonly{\printindex
\setheader{{\it INDEX}}{}{}{}{}{{\it INDEX}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
}

\end{document}
