I've now added the documentation files.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@11 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

docs/latex/porting/porting.hpj

@@ -0,0 +1,17 @@
+[OPTIONS]
+BMROOT=d:\wx2\docs/latex/porting ; Assume that bitmaps are where the source is
+TITLE=wxWindows Porting Guide
+CONTENTS=Contents
+COMPRESS=HIGH
+
+[FILES]
+porting.rtf
+
+[CONFIG]
+CreateButton("Up", "&Up", "JumpId(`porting.hlp', `Contents')")
+BrowseButtons()
+
+[MAP]
+
+[BITMAPS]
+

docs/latex/porting/porting.tex

@@ -0,0 +1,390 @@
+\documentstyle[a4,makeidx,verbatim,texhelp,fancyhea,mysober,mytitle]{report}
+\newcommand{\indexit}[1]{#1\index{#1}}%
+\newcommand{\pipe}[0]{$\|$\ }%
+\definecolour{black}{0}{0}{0}%
+\definecolour{cyan}{0}{255}{255}%
+\definecolour{green}{0}{255}{0}%
+\definecolour{magenta}{255}{0}{255}%
+\definecolour{red}{255}{0}{0}%
+\definecolour{blue}{0}{0}{200}%
+\definecolour{yellow}{255}{255}{0}%
+\definecolour{white}{255}{255}{255}%
+\input psbox.tex
+\parskip=10pt
+\parindent=0pt
+\title{Guide to porting applications from wxWindows 1.xx to 2.0}
+\author{Julian Smart}
+\date{October 1997}
+\makeindex
+\begin{document}
+\maketitle
+\pagestyle{fancyplain}
+\bibliographystyle{plain}
+\setheader{{\it CONTENTS}}{}{}{}{}{{\it CONTENTS}}
+\setfooter{\thepage}{}{}{}{}{\thepage}%
+\pagenumbering{roman}
+\tableofcontents
+%
+\chapter{About this document}\label{about}
+\pagenumbering{arabic}%
+\setheader{{\it Porting guide}}{}{}{}{}{{\it Porting guide}}%
+\setfooter{\thepage}{}{}{}{}{\thepage}%
+
+This document gives guidelines and tips for porting applications from
+version 1.xx of wxWindows to version 2.0.
+
+The first section offers tips for writing 1.xx applications in a way to
+minimize porting time. The following sections detail the changes and
+how you can modify your application to be 2.0-compliant.
+
+You may be worrying that porting to 2.0 will be a lot of work,
+particularly if you have only recently started using 1.xx. In fact,
+the wxWindows 2.0 API has far more in common with 1.xx than it has differences.
+With backward compatibility mode on, much of the conversion can be
+done gradually. The main challenges are doing without the default
+panel item layout, and the lack of automatic labels in some controls.
+However, if you already use resource files (.wxr), or application-specific positioning,
+or constraints, then even this will be quite painless.
+
+So please don't be freaked out by the jump to 2.0! For one thing, 1.xx is still available
+and will be supported by the user community for some time. And when you have
+changed to 2.0, we hope that you will appreciate the benefits in terms
+of greater flexibility, better user interface aesthetics, improved C++ conformance,
+improved compilation speed, and many other enhancements. The revised architecture
+of 2.0 will ensure that wxWindows can continue to evolve for the forseeable
+future.
+
+{\it Please note that this document is a work in progress.}
+
+\chapter{Preparing for version 2.0}\label{preparing}
+
+Even before compiling with version 2.0, there's also a lot you can do right now to make porting
+relatively simple. Here are a few tips.
+
+\begin{itemize}
+\item {\bf Use constraints or .wxr resources} for layout, rather than the default layout scheme.
+Constraints should be the same in 2.0, and resources will be translated.
+\item {\bf Use separate wxMessage items} instead of labels for wxText, wxMultiText,
+wxChoice, wxComboBox. These labels will disappear in 2.0. Use separate
+wxMessages whether you're creating controls programmatically or using
+the dialog editor. The future dialog editor will be able to translate
+from old to new more accurately if labels are separated out.
+\item {\bf Parameterise functions that use wxDC} or derivatives, i.e. make the wxDC
+an argument to all functions that do drawing. Minimise the use of
+wxWindow::GetDC and definitely don't store wxDCs long-term
+because in 2.0, you can't use GetDC() and wxDCs are not persistent.
+You will use wxClientDC, wxPaintDC stack objects instead. Minimising
+the use of GetDC() will ensure that there are very few places you
+have to change drawing code for 2.0.
+\item {\bf Don't set GDI objects} (wxPen, wxBrush etc.) in windows or wxCanvasDCs before they're
+needed (e.g. in constructors) - do so within your drawing routine instead. In
+2.0, these settings will only take effect between the construction and destruction
+of temporary wxClient/PaintDC objects.
+\item {\bf Don't rely} on arguments to wxDC functions being floating point - they will
+be 32-bit integers in 2.0.
+\item {\bf Don't use the wxCanvas member functions} that duplicate wxDC functions, such as SetPen and DrawLine, since
+they are going.
+\item {\bf Using member callbacks} called from global callback functions will make the transition
+easier - see the FAQ
+for some notes on using member functions for callbacks. wxWindows 2.0 will banish global
+callback functions (and OnMenuCommand), and nearly all event handling will be done by functions taking a single event argument.
+So in future you will have code like:
+
+{\small\begin{verbatim}
+void MyFrame::OnOK(wxCommandEvent& event)
+{
+        ...
+}
+\end{verbatim}
+}%
+
+You may find that writing the extra code to call a member function isn't worth it at this stage,
+but the option is there.
+\item {\bf Use wxString wherever possible.} 2.0 will replace char * with wxString
+in most cases, and if you use wxString to receive strings returned from
+wxWindows functions (except when you need to save the pointer if deallocation is required), there should
+be no conversion problems later on.
+\item Be aware that under Windows, {\bf font sizes will change} to match standard Windows
+font sizes (for example, a 12-point font will appear bigger than before). Write your application
+to be flexible where fonts are concerned.
+Don't rely on fonts being similarly-sized across platforms, as they were (by chance) between
+Windows and X under wxWindows 1.66. Yes, this is not easy... but I think it's better to conform to the
+standards of each platform, and currently the size difference makes it difficult to
+conform to Windows UI standards. You may eventually wish to build in a global 'fudge-factor' to compensate
+for size differences. The old font sizing will still be available via wx\_setup.h, so do not panic...
+\item {\bf Consider dropping wxForm usage}: an alternative is to be found in utils/wxprop.
+wxPropertyFormView can be used in a wxForm-like way, except that you specify a pre-constructed panel
+or dialog; or you can use a wxPropertyListView to show attributes in a scrolling list - you don't even need
+to lay panel items out.
+
+Because wxForm uses a number of features to be dropped in wxWindows 2.0, it cannot be
+supported in the future, at least in its present state.
+\item {\bf When creating a wxListBox}, put the wxLB\_SINGLE, wxLB\_MULTIPLE, wxLB\_EXTENDED styles in the window style parameter, and put
+zero in the {\it multiple} parameter. The {\it multiple} parameter will be removed in 2.0.
+\item {\bf For MDI applications}, don't reply on MDI being run-time-switchable in the way that the
+MDI sample is. In wxWindows 2.0, MDI functionality is separated into distinct classes.
+\end{itemize}
+
+\chapter{The new event system}\label{eventsystem}
+
+The way that events are handled has been radically changed in wxWindows 2.0. Please
+read the topic `Event handling overview' in the wxWindows 2.0 manual for background
+on this.
+
+\section{Callbacks}
+
+Instead of callbacks for panel items, menu command events, control commands and other events are directed to
+the originating window, or an ancestor, or an event handler that has been plugged into the window
+or its ancestor. Event handlers always have one argument, a derivative of wxEvent.
+
+For menubar commands, the {\bf OnMenuCommand} member function will be replaced by a series of separate member functions,
+each of which responds to a particular command. You need to add these (non-virtual) functions to your
+frame class, add a DECLARE\_EVENT\_TABLE entry to the class, and then add an event table to
+your implementation file, as a BEGIN\_EVENT\_TABLE and END\_EVENT\_TABLE block. The
+individual event mapping macros will be of the form:
+
+\begin{verbatim}
+BEGIN_EVENT_TABLE(MyFrame, wxFrame)
+    EVT_MENU(MYAPP_NEW, MyFrame::OnNew)
+    EVT_MENU(wxID_EXIT, MyFrame::OnExit)
+END_EVENT_TABLE()
+\end{verbatim}
+
+Control commands, such as button commands, can be routed to a derived button class,
+the parent window, or even the frame. Here, you use a function of the form EVT\_BUTTON(id, func).
+Similar macros exist for other control commands.
+
+\section{Other events}
+
+To intercept other events, you used to override virtual functions, such as OnSize. Now, while you can use
+the OnSize name for such event handlers (or any other name of your choice), it has only a single argument
+(wxSizeEvent) and must again be `mapped' using the EVT\_SIZE macro. The same goes for all other events,
+including OnClose (although in fact you can still use the old, virtual form of OnClose for the time being).
+
+\chapter{Class hierarchy}\label{classhierarchy}
+
+The class hierarchy has changed somewhat. wxToolBar and wxButtonBar
+classes have been split into several classes, and are derived from wxControl (which was
+called wxItem). wxPanel derives from wxWindow instead of from wxCanvas, which has
+disappeared in favour of wxScrolledWindow (since all windows are now effectively canvases
+which can be drawn into). The status bar has become a class in its own right, wxStatusBar.
+
+There are new MDI classes so that wxFrame does not have to be overloaded with this
+functionality.
+
+There are new device context classes, with wxPanelDC and wxCanvasDC disappearing.
+See \helpref{Device contexts and painting}{dc}.
+
+\chapter{GDI objects}\label{gdiobjects}
+
+These objects - instances of classes such as wxPen, wxBrush, wxBitmap (but not wxColour) -
+are now implemented with reference-counting. This makes assignment a very cheap operation,
+and also means that management of the resource is largely automatic. You now pass {\it references} to
+objects to functions such as wxDC::SetPen. The device context does not store a copy of the pen
+itself, but takes a copy of it (via reference counting), and the object's data gets freed up
+when the reference count goes to zero. The application does not have to worry so much about
+who the object belongs to: it can pass the reference, then destroy the object without
+leaving a dangling pointer inside the device context.
+
+For the purposes of code migration, you can use the old style of object management - maintaining
+pointers to GDI objects, and using the FindOrCreate... functions. However, it is preferable to
+keep this explicit management to a minimum, instead creating objects on the fly as needed, on the stack,
+unless this causes too much of an overhead in your application.
+
+At a minimum, you will have to make sure that calls to SetPen, SetBrush etc. work. Some compilers
+will do the conversion from pointer to reference automatically (via a constructor in the GDI
+class) but you cannot rely on this being true for all compilers. Also, where you pass NULL to these
+functions, you will need to either cast to the appropriate reference type, or instead
+use an identifier such as wxNullPen or wxNullBrush.
+
+\chapter{Dialogs and controls}\label{dialogscontrols}
+
+\wxheading{Labels}
+
+Most controls no longer have labels and values as they used to in 1.xx. Instead, labels
+should be created separately using wxStaticText (the new name for wxMessage). This will
+need some reworking of dialogs, unfortunately; programmatic dialog creation that doesn't
+use constraints will be especially hard-hit. Perhaps take this opportunity to make more
+use of dialog resources or constraints. Or consider using the wxPropertyListView class
+which can do away with dialog layout issues altogether by presenting a list of editable
+properties.
+
+\wxheading{Constructors}
+
+All window constructors have two main changes, apart from the label issue mentioned above.
+Windows now have integer identifiers; and position and size are now passed as wxPoint and
+wxSize objects. In addition, some windows have a wxValidator argument. wxWindows 2.0 may provide
+old-style constructors in WXWIN\_COMPATIBILITY mode for limited backward compatibility.
+
+\wxheading{Show versus ShowModal}
+
+If you have used or overridden the {\bf wxDialog::Show} function in the past, you may find
+that modal dialogs no longer work as expected. This is because the function for modal showing
+is now {\bf wxDialog:ShowModal}. This is part of a more fundamental change in which a
+control may tell the dialog that it caused the dismissal of a dialog, by
+calling {\bf wxDialog::EndModal} or {\bf wxWindow::SetReturnCode}. Using this
+information, {\bf ShowModal} now returns the id of the control that caused dismissal,
+giving greater feedback to the application than just TRUE or FALSE.
+
+If you overrode or called {\bf wxDialog::Show}, use {\bf ShowModal} and test for a returned identifier,
+commonly wxID\_OK or wxID\_CANCEL.
+
+\wxheading{wxItem}
+
+This is renamed wxControl.
+
+\wxheading{wxText, wxMultiText and wxTextWindow}
+
+These classes no longer exist and are replaced by the single class wxTextCtrl.
+Multi-line text items are created using the wxTE\_MULTILINE style.
+
+\wxheading{wxButton}
+
+Bitmap buttons are now a separate class, instead of being part of wxBitmap.
+
+\wxheading{wxMessage}
+
+Bitmap messages are now a separate class, wxStaticBitmap, and wxMessage
+is renamed wxStaticText.
+
+\wxheading{wxGroupBox}
+
+wxGroupBox is renamed wxStaticBox.
+
+\wxheading{wxForm}
+
+Note that wxForm is no longer supported in wxWindows 2.0. Consider using the wxPropertyForm class
+instead, which takes standard dialogs and panels and associates controls with property objects.
+You may also find that the new validation method, combined with dialog resources, is easier
+and more flexible than using wxForm.
+
+\chapter{Device contexts and painting}\label{dc}
+
+In wxWindows 2.0, device contexts are used for drawing into, as per 1.xx, but the way
+they are accessed and constructed is a bit different.
+
+You no longer use {\bf GetDC} to access device contexts for panels, dialogs and canvases.
+Instead, you create a temporary device context, which means that any window or control can be drawn
+into. The sort of device context you create depends on where your code is called from. If
+painting within an {\bf OnPaint} handler, you create a wxPaintDC. If not within an {\bf OnPaint} handler,
+you use a wxClientDC or wxWindowDC. You can still parameterise your drawing code so that it
+doesn't have to worry about what sort of device context to create - it uses the DC it is passed
+from other parts of the program.
+
+You {\bf must } create a wxPaintDC if you define an OnPaint handler, even if you do not
+actually use this device context, or painting will not work correctly under Windows.
+
+If you used device context functions with wxPoint or wxIntPoint before, please note
+that wxPoint now contains integer members, and there is a new class wxRealPoint. wxIntPoint
+no longer exists.
+
+\chapter{Miscellaneous}
+
+\section{Strings}
+
+wxString has replaced char* in the majority of cases. For passing strings into functions,
+this should not normally require you to change your code if the syntax is otherwise the
+same. This is because C++ will automatically convert a char* or const char* to a wxString by virtue
+of appropriate wxString constructors.
+
+However, when a wxString is returned from a function in wxWindows 2.0 where a char* was
+returned in wxWindows 1.xx, your application will need to be changed. Usually you can
+simplify your application's allocation and deallocation of memory for the returned string,
+and simply assign the result to a wxString object. For example, replace this:
+
+{\small\begin{verbatim}
+  char* s = wxFunctionThatReturnsString();
+  s = copystring(s); // Take a copy in case it's temporary
+  .... // Do something with it
+  delete[] s;
+\end{verbatim}
+}
+
+with this:
+
+{\small\begin{verbatim}
+  wxString s = wxFunctionThatReturnsString();
+  .... // Do something with it
+\end{verbatim}
+}
+
+To indicate an empty return value or a problem, a function may return either the
+empty string (``") or a null string. You can check for a null string with wxString::IsNull().
+
+\section{Use of const}
+
+The {\bf const} keyword is now used to denote constant functions that do not affect the
+object, and for function arguments to denote that the object passed cannot be changed.
+
+This should not affect your application except for where you are overriding virtual functions
+which now have a different signature. If functions are not being called which were previously,
+check whether there is a parameter mismatch (or function type mismatch) involving consts.
+
+Try to use the {\bf const} keyword in your own code where possible.
+
+\chapter{Backward compatibility}\label{compat}
+
+Some wxWindows 1.xx functionality has been left to ease the transition to 2.0. This functionality
+(usually) only works if you compile with WXWIN\_COMPATIBILITY set to 1.
+
+TODO
+
+OnMenuCommand, OnSize, OnActivate, OnPaint, others?? can all be prefixed with Old (e.g. OldOnMenuCommand)
+and will work as before. You are encouraged to convert your code to the new forms, but
+this will allow you to get your applications up and running a little more quickly.
+
+OnClose can be used as-is without an 'Old' prefix, but officially the OnCloseWindow event table handler should be
+used instead.
+
+\chapter{Quick reference}\label{quickreference}
+
+This section allows you to quickly find features that
+need to be converted.
+
+TODO
+
+\section{OnActivate}
+
+Rename to OldOnActivate, or replace arguments with one wxActivateEvent\& argument.
+
+\wxheading{See also}
+
+\helpref{Backward compatibility}{compat}
+
+\section{OnClose}
+
+This can either remain the same as before, or you can add an OnCloseWindow event
+handler using an EVT\_CLOSE event table entry.
+
+\wxheading{See also}
+
+\helpref{Backward compatibility}{compat}
+
+\section{OnMenuCommand}
+
+Rename to OldOnMenuCommand, or replace with a series of functions, one for
+each case of your old switch statement. Create an event table for your frame
+containing EVT\_MENU macros, and insert DECLARE\_EVENT\_TABLE() in your frame class.
+
+\wxheading{See also}
+
+\helpref{Backward compatibility}{compat}
+
+\section{OnSize}
+
+Rename to OldOnSize, or replace arguments with one wxSizeEvent\& argument.
+
+\wxheading{See also}
+
+\helpref{Backward compatibility}{compat}
+
+\section{wxDialog::Show}
+
+If you used {\bf Show} to show a modal dialog, or to override the standard
+modal dialog {\bf Show}, use {\bf ShowModal} instead.
+
+\wxheading{See also}
+
+\helpref{Dialogs and controls}{dialogscontrols}
+
+\end{document}

docs/latex/porting/tex2rtf.ini

@@ -0,0 +1,28 @@
+;;; Tex2RTF initialisation file for 16-bit Winhelp
+runTwice = yes
+titleFontSize = 12
+authorFontSize = 10
+authorFontSize = 10
+chapterFontSize = 12
+sectionFontSize = 12
+subsectionFontSize = 12
+contentsDepth = 2
+headerRule = yes
+footerRule = yes
+useHeadingStyles = yes
+listItemIndent=40
+generateHPJ = yes
+htmlBrowseButtons = bitmap
+winHelpContents = yes
+winHelpVersion = 3 ; 3 for Windows 3.x, 4 for Windows 95
+winHelpTitle = "wxWindows Porting Guide"
+truncateFilenames = yes
+combineSubSections = yes
+\overview [2] {\rtfonly{See also }\settransparency{on}\sethotspotcolour{off}\sethotspotunderline{on}\winhelponly{\image{}{books.bmp}\settransparency{off}}
+\htmlonly{\image{}{books.gif}}\helpref{#1}{#2}
+\sethotspotcolour{on}\sethotspotunderline{on}}
+\docparam [2]{\parskip{0}{\it #1}\par\parskip{10}\indented{1cm}{#2}}
+\wxheading [1]{{\bf \fcol{blue}{#1}}}
+\const [0] {{\bf const}}
+\constfunc [3] {{\bf #1} {\bf #2}(#3) {\bf const}\index{#2}}
+

docs/latex/porting/texhelp.sty

@@ -0,0 +1,289 @@
+% LaTeX style file
+% Name:   texhelp.sty
+% Author: Julian Smart
+%
+% Purpose
+% -------
+% Style file to enable the simultaneous preparation of printed LaTeX and on-line
+% hypertext manuals.
+% Use in conjunction with Tex2RTF (see Tex2RTF documentation).
+%
+% Note that if a non-ASCII character starts a newline and there should be a space
+% between the last word on the previous line and the first word on this line,
+% you need to use \rtfsp to generate a space in Windows Help. \rtfsp is ignored
+% in all other formats.
+%
+% Julian Smart
+% Artificial Intelligence Applications Institute
+%
+%
+% ============== C++/CLIPS Documentation Facilities ==============
+%
+% Each class definition should be typeset with e.g.
+%
+% \section{\class{Name}: Parent}
+%
+% followed by a description of the class.
+% Each member should follow:
+%
+% \membersection{wxName::Member}
+%
+% with a description of what this member does.
+% Then, one (or more if overloaded) member (function) in detail:
+%
+% \func{return type}{name}{args}
+% or
+% \member{type}{name}
+%
+% where args is a list of \param{type}{name}, ...
+
+% Function, e.g.
+% e.g. to typeset
+%
+% void DoIt(char *string);
+%
+% write:
+%
+% \func{void}{DoIt}{\param{char *}{string}}
+%
+
+\newcommand{\func}[3]{\hangafter=1\noindent\hangindent=10mm
+{{\it #1} {\bf #2}\index{#2}}(#3)}
+
+% For function/type definition where the name is a pointer,
+% e.g. to typeset
+%
+% typedef void (*wxFunction)(wxObject&)
+%
+% write:
+%
+% \pfunc{typedef void}{wxFunction}{param{wxObject&}}
+
+\newcommand{\pfunc}[3]{\hangafter=1\noindent\hangindent=10mm
+{{\it #1} ({\bf *#2})\index{#2}}(#3)}
+
+% Use an ordinary \section command for class name definitions.
+
+% This is used for a member, such as wxBitmap: GetDepth
+\newcommand{\membersection}[1]{\subsection*{#1}\index{#1}}
+
+% CLIPS function
+\newcommand{\clipsfunc}[3]{\hangafter=1\noindent\hangindent=10mm
+{{\bf #1} ({\bf #2}\index{#2}}#3)}
+
+\newcommand{\clipssection}[1]{\chapter{#1}}
+
+% This is used for a CLIPS function name
+\newcommand{\functionsection}[1]{\subsection*{#1}}
+
+% Member: a type and a name
+\newcommand{\member}[2]{{\bf #1 \it #2}}
+
+% C++ Parameter: a type and a name (no intervening space)
+\newcommand{\param}[2]{{\it #1}{\bf #2}}
+
+% CLIPS Parameter: a type and a name (one intervening space)
+\newcommand{\cparam}[2]{{\bf #1} {\it #2}}
+
+% Class: puts in index
+\newcommand{\class}[1]{#1\index{#1}}
+
+% Void type
+\newcommand{\void}{{\it void}}
+
+% Typeset destructor
+\newcommand{\destruct}[1]{{$\sim$}#1}
+
+% Typeset insert/extract operators
+\newcommand{\cinsert}{$<<$}
+\newcommand{\cextract}{$>>$}
+
+
+% =================== Hypertext facilities ===================
+%
+% To insert hyperlinks (or references, in Latex), \label the sections
+% or membersections \label{ref-label} immediately after the section, on the same line,
+% and use \helpref{text-to-show}{ref-label} to make a reference.
+%
+
+% Type text with section reference
+\newcommand{\helpref}[2]{{\it #1} (p.\ \pageref{#2}) }
+
+% Type text with URL in verbatim mode
+\newcommand{\urlref}[2]{#1 (\verb$#2$)}
+
+% Don't typeset section number in LaTeX
+\newcommand{\helprefn}[2]{{\it #1}}
+
+% Like helpref, but popup text in WinHelp instead of hyperlinked
+\newcommand{\popref}[2]{{\it #1}}
+
+% Like footnote, but popup text.
+\newcommand{\footnotepopup}[2]{{\it #1}\footnote{#2}}
+
+% =================== On-line help specific macros ===================
+%
+
+% Global document font size/family, help only.
+\newcommand{\helpfontsize}[1]{}
+\newcommand{\helpfontfamily}[1]{}
+
+% Ignore in all on-line help
+\newcommand{\helpignore}[1]{#1}
+% Only print in all on-line help
+\newcommand{\helponly}[1]{}
+
+% Ignore in LaTeX
+\newcommand{\latexignore}[1]{}
+% Only print in LaTeX
+\newcommand{\latexonly}[1]{#1}
+
+% Ignore in linear RTF
+\newcommand{\rtfignore}[1]{#1}
+% Only print in linear RTF
+\newcommand{\rtfonly}[1]{}
+
+% Ignore in WinHelp RTF
+\newcommand{\winhelpignore}[1]{#1}
+% Only print in WinHelp RTF
+\newcommand{\winhelponly}[1]{}
+
+% Ignore in wxHelp
+\newcommand{\xlpignore}[1]{#1}
+% Only print in wxHelp
+\newcommand{\xlponly}[1]{}
+
+% Ignore in HTML
+\newcommand{\htmlignore}[1]{#1}
+% Only print in HTML
+\newcommand{\htmlonly}[1]{}
+
+% Input a file only for help system (binder thickness is not a limitation
+% in help systems!)
+\newcommand{\helpinput}[1]{}
+
+\newcommand{\rtfsp}{ } % Force a space in RTF, ignore in Latex
+
+% =================== Miscellaneous macros ===================
+%
+% Headings consistent with generated ones
+\newcommand{\myheading}[1]{\vspace*{25pt}
+\begin{flushleft}
+{\LARGE \bf #1}
+\end{flushleft}
+\vskip 20pt
+}
+
+% Heading with entry in contents page.
+\newcommand{\chapterheading}[1]{\myheading{#1}
+\addcontentsline{toc}{chapter}{#1}}
+
+\newcommand{\sectionheading}[1]{\myheading{#1}
+\addcontentsline{toc}{section}{#1}}
+
+% Glossary environment
+\newenvironment{helpglossary}{\newpage\chapterheading{Glossary}\begin{description}}{\end{description}}
+
+% Glossary entry
+\newcommand{\gloss}[1]{\item[#1]\index{#1}}
+
+% Image: EPS in Latex, BMP or MF (whatever's available) in RTF. Requires psbox.
+\newcommand{\image}[2]{\psboxto(#1){#2}}
+
+% Image, left aligned (HTML)
+\newcommand{\imager}[2]{\psboxto(#1){#2}}
+
+% Image, right aligned (HTML)
+\newcommand{\imagel}[2]{\psboxto(#1){#2}}
+
+% Imagemap: principally for HTML only. In Latex,
+% acts like \image.
+\newcommand{\imagemap}[3]{\psboxto(#1){#2}}
+
+% Headers and footers
+% \setheader{EvenPageLeft}{EvenPageCentre}{EvenPageRight}
+% {OddPageLeft}{OddPageCentre}{OddPageRight}
+\newcommand{\setheader}[6]{
+\lhead[\fancyplain{}{#1}]{\fancyplain{}{#4}}
+\chead[\fancyplain{}{#2}]{\fancyplain{}{#5}}
+\rhead[\fancyplain{}{#3}]{\fancyplain{}{#6}}
+}
+
+% \setfooter{EvenPageLeft}{EvenPageCentre}{EvenPageRight}
+% {OddPageLeft}{OddPageCentre}{OddPageRight}
+\newcommand{\setfooter}[6]{
+\lfoot[\fancyplain{#1}{#1}]{\fancyplain{#4}{#4}}
+\cfoot[\fancyplain{#2}{#2}]{\fancyplain{#5}{#5}}
+\rfoot[\fancyplain{#3}{#3}]{\fancyplain{#6}{#6}}
+}
+
+% Needed for telling RTF where margin paragraph should go
+% in mirrored margins mode.
+\newcommand{\marginpareven}[1]{\hspace*{0pt}\marginpar{#1}}
+\newcommand{\marginparodd}[1]{\hspace*{0pt}\marginpar{#1}}
+
+% Environment for two-column table popular in WinHelp and manuals.
+\newcommand{\twocolwidtha}[1]{\def\twocolwidthaval{#1}}
+\newcommand{\twocolwidthb}[1]{\def\twocolwidthbval{#1}}
+\newcommand{\twocolspacing}[1]{\def\twocolspacingval{#1}}
+
+\twocolwidtha{3cm}
+\twocolwidthb{8.5cm}
+\twocolspacing{2}
+
+\newcommand{\twocolitem}[2]{#1 & #2\\}
+\newcommand{\twocolitemruled}[2]{#1 & #2\\\hline}
+
+\newenvironment{twocollist}{\renewcommand{\arraystretch}{\twocolspacingval}\begin{tabular}{lp{\twocolwidthbval}}}%
+{\end{tabular}\renewcommand{\arraystretch}{1}}
+
+% Specifying table rows for RTF compatibility
+\newcommand{\row}[1]{#1\\}
+
+% Use for the last ruled row for correct RTF generation.
+\newcommand{\ruledrow}[1]{#1\\\hline}
+
+% Indentation environment. Arg1 is left margin size
+\newenvironment{indented}[1]{\begin{list}{}{\leftmargin=#1}\item[]}%
+{\end{list}}
+
+% Framed box of text, normal formatting.
+\newcommand{\normalbox}[1]{\fbox{\vbox{#1}}}
+% Double-framed box of text.
+\newcommand{\normalboxd}[1]{\fbox{\fbox{\vbox{#1}}}}
+
+% WITHDRAWN -- can't do in RTF, easily.
+% Framed box of text, horizontally centred. Ragged right within box.
+% \newcommand{\centeredbox}[2]{\begin{center}\fbox{\parbox{#1}{\raggedright#2}}\end{center}}
+% Double-framed box of text, horizontally centred. Ragged right within box.
+% \newcommand{\centeredboxd}[2]{\begin{center}\fbox{\fbox{\parbox{#1}{\raggedright#2}}}\end{center}}
+
+% toocomplex environment: simply prints the argument in LaTeX,
+% comes out verbatim in all generated formats.
+\newenvironment{toocomplex}{}{}
+
+% Colour: dummy commands since LaTeX doesn't support colour.
+% \definecolour{name}{red}{blue}{green}
+% \fcol{name}{text} ; Foreground
+% \bcol{name}{text} ; Background
+\newcommand{\definecolour}[4]{}
+\newcommand{\definecolor}[4]{}
+\newcommand{\fcol}[2]{#2}
+\newcommand{\bcol}[2]{#2}
+\newcommand{\sethotspotcolour}[1]{}
+\newcommand{\sethotspotunderline}[1]{}
+\newcommand{\settransparency}[1]{}
+\newcommand{\backslashraw}[0]{}
+\newcommand{\lbraceraw}[0]{}
+\newcommand{\rbraceraw}[0]{}
+\newcommand{\registered}[0]{(r)}
+\newcommand{\background}[1]{}
+\newcommand{\textcolour}[1]{}
+\newcommand{\overview}[2]{See \helpref{#1}{#2}.}
+\newcommand{\docparam}[2]{{\it #1}\begin{list}{}{\leftmargin=1cm}\item[]
+#2%
+\end{list}}
+\newcommand{\wxheading}[1]{{\bf #1}}
+\newcommand{\const}[0]{{\bf const}}
+\newcommand{\constfunc}[3]{{\bf #1} {\bf #2}(#3) {\bf const}\index{#2}}
+