Removed obsolete files

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_2_4_BRANCH@34103 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Julian Smart
2005-05-17 17:34:16 +00:00
parent 399e279923
commit 26ba0c8fb0
51 changed files with 0 additions and 2675 deletions

Binary file not shown.

Before

Width:  |  Height:  |  Size: 978 B

View File

@@ -1,177 +0,0 @@
\documentstyle[a4,11pt,makeidx,verbatim,texhelp,fancyheadings,palatino]{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
% Remove this for processing with dvi2ps instead of dvips
%\special{!/@scaleunit 1 def}
\parskip=10pt
\parindent=0pt
%
\title{Multiplatform application development with wxWindows}
\author{Julian Smart, Robert Roebling, Vadim Zeitlin, Robin Dunn, et al}
\date{August 13th 2000}
%
\makeindex
\begin{document}
\maketitle
\pagestyle{fancyplain}
\bibliographystyle{plain}
\setheader{{\it CONTENTS}}{}{}{}{}{{\it CONTENTS}}
\setfooter{\thepage}{}{}{}{}{\thepage}%
\pagenumbering{roman}
\tableofcontents
% Acknowledgements
\input chap\_acknowledge.tex
%
% Chapter 01: Introduction, advocacy, etc.
\input chap\_intro.tex
%
% Chapter 02: Installing wxWindows (and what tools to use)
\input chap\_install.tex
%
% Chapter 03: C++ and wxWindows. Summarises the sorts of constructs used/not used, plus wxString class, some conventions. Vadim suggests putting it in 1st chapter but I think it deserves a chapter of its own.
\input chap\_cpp.tex
%
% Chapter 04: Getting started: Hello World. Introduces app class, frames, menus, status bar, message box
\input chap\_getstart.tex
%
% Chapter 05: Basic event handling
\input chap\_basic\_events.tex
%
% Chapter 06: Frames and menubars. The components of a frame, menubars.
\input chap\_frames.tex
%
% Chapter 07: Toolbars and status bars
\input chap\_toolbars.tex
%
% Chapter 08: Basic controls
\input chap\_basic\_controls.tex
%
% Chapter 09: Common dialogs
\input chap\_common\_dialogs.tex
%
% Chapter 10: Custom dialogs and resources (XML)
\input chap\_custom\_dialogs.tex
%
% Chapter 11: Drawing on device contexts
\input chap\_drawing.tex
%
% Chapter 12: Handling input (mouse, keyboard, joystick)
\input chap\_input.tex
%
% Chapter 14: Sizers
%
\input chap\_sizers.tex
%
% Chapter 15: Images and bitmaps
\input chap\_images.tex
%
% Chapter 16: Clipboard and drag and drop
\input chap\_clipboard\_dnd.tex
%
% Chapter 17: Advanced controls (list,tree,notebook,splitter,wxWizard,wxCalCtrl...)
\input chap\_advanced\_controls.tex
%
% Chapter 18: Document/view classes
\input chap\_docview.tex
%
% Chapter 19: Scrolling
\input chap\_scrolling.tex
%
% Chapter 20: MDI
\input chap\_mdi.tex
%
% Chapter 21: Printing
\input chap\_printing.tex
%
% Chapter 22: Providing help in your applications
\input chap\_help.tex
%
% Chapter 23: Strings and internationalization
\input chap\_strings.tex
%
\input chap\_data\_classes.tex
% Chapter 24: Collection and container classes
%
% Chapter 25: Memory management and debugging (including wxLog)
\input chap\_memory.tex
%
% Chapter 26: Run-time class information
\input chap\_runtime.tex
%
% Chapter 27: Advanced event handling (user-defined events, ...)
\input chap\_advanced\_events.tex
%
% Chapter 28: Communication classes, including wxSocket
\input chap\_comms.tex
%
% Chapter 29: Database classes
\input chap\_database.tex
%
% Chapter 30: File and stream classes
\input chap\_file\_stream.tex
%
% Chapter 31: Configuration classes
\input chap\_config.tex
%
% Chapter 32: Time, timers and idle processing
\input chap\_time.tex
%
% Chapter 33: Writing multithreading applications
\input chap\_multithreading.tex
%
% Chapter 34: Perfecting your UI (Adapting to system settings, accelerators, ...)
\input chap\_perfecting.tex
%
% Chapter 35: Platform-specific programming (metafiles, OLE automation, taskbar, ...)
\input chap\_platform.tex
%
% Chapter 36: Using wxHTML
\input chap\_wxhtml.tex
%
% Chapter 37: Using wxPython
\input chap\_wxpython.tex
%
% Chapter 38: wxBase?
\input chap\_wxbase.tex
%
% Appendix: Comparison with other toolkits: MFC, Qt etc.
\input chap\_comparison.tex
%
% Appendix: a compendium of external resources, libraries etc.
\input chap\_resources.tex
\bibliography{refs}
\addcontentsline{toc}{chapter}{Bibliography}
\setheader{{\it REFERENCES}}{}{}{}{}{{\it REFERENCES}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
\newpage
% Note: In RTF, the \printindex must come before the
% change of header/footer, since the \printindex inserts
% the RTF \sect command which divides one chapter from
% the next.
\rtfonly{\printindex
\addcontentsline{toc}{chapter}{Index}
\setheader{{\it INDEX}}{}{}{}{}{{\it INDEX}}%
\setfooter{\thepage}{}{}{}{}{\thepage}
}
% In Latex, it must be this way around (I think)
\latexonly{\addcontentsline{toc}{chapter}{Index}
\setheader{{\it INDEX}}{}{}{}{}{{\it INDEX}}%
\setfooter{\thepage}{}{}{}{}{\thepage}
\printindex
}
\end{document}

View File

@@ -1,9 +0,0 @@
\chapter*{Acknowledgements}\label{chapacknowledgements}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: ACKNOWLEDGEMENTS}}{}{}{}{}{{\it CHAPTER \thechapter: ACKNOWLEDGEMENTS}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
We would like to acknowledge the help of the following people.
(Insert list of people here.)

View File

@@ -1,17 +0,0 @@
\chapter{Advanced controls}\label{chapadvancedcontrols}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: ADVANCED CONTROLS}}{}{}{}{}{{\it CHAPTER \thechapter: ADVANCED CONTROLS}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
This chapter looks at the following advanced wxWindows controls:
\begin{itemize}\itemsep=0pt
\item wxListCtrl
\item wxTreeCtrl
\item wxNotebook
\item wxSplitterWindow
\item wxSashWindow
\item wxWizard
\item wxCalCtrl
\end{itemize}

View File

@@ -1,8 +0,0 @@
\chapter{Advanced event handling}\label{chapadvancedevents}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: ADVANCED EVENT HANDLING}}{}{}{}{}{{\it CHAPTER \thechapter: ADVANCED EVENT HANDLING}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
This chapter explores the wxWindows event system in more detail, and shows you how to
create your own event classes.

View File

@@ -1,8 +0,0 @@
\chapter{Basic controls}\label{chapbasiccontrols}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: BASIC CONTROLS}}{}{}{}{}{{\it CHAPTER \thechapter: BASIC CONTROLS}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
This chapter deals with the most fundamental controls (or widgets) that you will use in your
application.

View File

@@ -1,353 +0,0 @@
\chapter{Basic event handling}\label{chapbasicevents}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: BASIC EVENT HANDLING}}{}{}{}{}{{\it CHAPTER \thechapter: BASIC EVENT HANDLING}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
\section{Introduction}
In most cases, wxWindows uses the concept of {\it event tables} to catch user input.
An event table is placed in an implementation file to tell wxWindows how to map
events to member functions. These member functions are not virtual functions, but
they are all similar in form: they take a single wxEvent-derived argument, and have a void return
type.
Here's an example of an event table.
\begin{verbatim}
BEGIN_EVENT_TABLE(MyFrame, wxFrame)
EVT_MENU (wxID_EXIT, MyFrame::OnExit)
EVT_MENU (DO_TEST, MyFrame::DoTest)
EVT_SIZE ( MyFrame::OnSize)
EVT_BUTTON (BUTTON1, MyFrame::OnButton1)
END_EVENT_TABLE()
\end{verbatim}
The first two entries map menu commands to two different member functions. The EVT\_SIZE macro
doesn't need a window identifier, since normally you are only interested in the
current window's size events. (In fact you could intercept a particular window's size event
by using EVT\_CUSTOM(wxEVT\_SIZE, id, func).)
The EVT\_BUTTON macro demonstrates that the originating event does not have to come from
the window class implementing the event table - if the event source is a button within a panel within a frame, this will still
work, because event tables are searched up through the hierarchy of windows. In this
case, the button's event table will be searched, then the parent panel's, then the frame's.
As mentioned before, the member functions that handle events do not have to be virtual.
Indeed, the member functions should not be virtual as the event handler ignores that
the functions are virtual, i.e. overriding a virtual member function in a derived class
will not have any effect.
These member functions take an event argument, and the class of event differs according
to the type of event and the class of the originating window. For size
events, \wxhelpref{wxSizeEvent}{wxsizeevent} is used. For menu commands and most control
commands (such as button presses), \wxhelpref{wxCommandEvent}{wxcommandevent} is used.
When controls get more complicated, then specific event classes are used, such
as \wxhelpref{wxTreeEvent}{wxtreeevent} for events from \wxhelpref{wxTreeCtrl}{wxtreectrl} windows.
As well as the event table in the implementation file, there must be a DECLARE\_EVENT\_TABLE
macro in the class definition. For example:
{\small%
\begin{verbatim}
class MyFrame: public wxFrame {
DECLARE_DYNAMIC_CLASS(MyFrame)
public:
...
void OnExit(wxCommandEvent& event);
void OnSize(wxSizeEvent& event);
protected:
int m_count;
...
DECLARE_EVENT_TABLE()
};
\end{verbatim}
}%
\section{How events are processed}\label{eventprocessing}
When an event is received from the windowing system, wxWindows calls \wxhelpref{wxEvtHandler::ProcessEvent}{wxevthandlerprocessevent} on
the first event handler object belonging to the window generating the event.
It may be noted that wxWindows' event processing system implements something
very close to virtual methods in normal C++, i.e. it is possible to alter
the behaviour of a class by overriding its event handling functions. In
many cases this works even for changing the behaviour of native controls.
For example it is possible to filter out a number of key events sent by the
system to a native text control by overriding wxTextCtrl and defining a
handler for key events using EVT\_KEY\_DOWN. This would indeed prevent
any key events from being sent to the native control - which might not be
what is desired. In this case the event handler function has to call Skip()
so as to indicate that the search for the event handler should continue.
To summarize, instead of explicitly calling the base class version as you
would have done with C++ virtual functions (i.e. {\it wxTextCtrl::OnChar()}),
you should instead call \wxhelpref{wxEvent::Skip}{wxeventskip}.
In practice, this would look like the following if the derived text control only
accepts 'a' to 'z' and 'A' to 'Z':
{\small%
\begin{verbatim}
void MyTextCtrl::OnChar(wxKeyEvent& event)
{
if ( isalpha( event.KeyCode() ) )
{
// key code is within legal range. we call event.Skip() so the
// event can be processed either in the base wxWindows class
// or the native control.
event.Skip();
}
else
{
// illegal key hit. we don't call event.Skip() so the
// event is not processed anywhere else.
wxBell();
}
}
\end{verbatim}
}%
The normal order of event table searching by ProcessEvent is as follows:
\begin{enumerate}\itemsep=0pt
\item If the object is disabled (via a call to \wxhelpref{wxEvtHandler::SetEvtHandlerEnabled}{wxevthandlersetevthandlerenabled})
the function skips to step (6).
\item If the object is a wxWindow, {\bf ProcessEvent} is recursively called on the window's\rtfsp
\wxhelpref{wxValidator}{wxvalidator}. If this returns TRUE, the function exits.
\item {\bf SearchEventTable} is called for this event handler. If this fails, the base
class table is tried, and so on until no more tables exist or an appropriate function was found,
in which case the function exits.
\item The search is applied down the entire chain of event handlers (usually the chain has a length
of one). If this succeeds, the function exits.
\item If the object is a wxWindow and the event is a wxCommandEvent, {\bf ProcessEvent} is
recursively applied to the parent window's event handler. If this returns TRUE, the function exits.
\item Finally, {\bf ProcessEvent} is called on the wxApp object.
\end{enumerate}
{\bf Pay close attention to Step 5.} People often overlook or get
confused by this powerful feature of the wxWindows event processing
system. To put it a different way, events derived either directly or
indirectly from wxCommandEvent will travel up the containment
hierarchy from child to parent until an event handler is found that
doesn't call event.Skip(). Events not derived from wxCommandEvent are
sent only to the window they occurred in and then stop.
Typically events that deal with a window as a window (size, motion,
paint, mouse, keyboard, etc.) are sent only to the window. Events
that have a higher level of meaning and/or are generated by the window
itself, (button click, menu select, tree expand, etc.) are command
events and are sent up to the parent to see if it is interested in the
event.
Note that your application may wish to override ProcessEvent to redirect processing of
events. This is done in the document/view framework, for example, to allow event handlers
to be defined in the document or view. To test for command events (which will probably
be the only events you wish to redirect), you may use wxEvent::IsCommandEvent for
efficiency, instead of using the slower run-time type system.
As mentioned above, only command events are recursively applied to the parents event
handler. As this quite often causes confusion for users, here is a list of system
events which will {\it not} get sent to the parent's event handler:
\begin{twocollist}\itemsep=0pt
\twocolitem{\wxhelpref{wxEvent}{wxevent}}{The event base class}
\twocolitem{\wxhelpref{wxActivateEvent}{wxactivateevent}}{A window or application activation event}
\twocolitem{\wxhelpref{wxCloseEvent}{wxcloseevent}}{A close window or end session event}
\twocolitem{\wxhelpref{wxEraseEvent}{wxeraseevent}}{An erase background event}
\twocolitem{\wxhelpref{wxFocusEvent}{wxfocusevent}}{A window focus event}
\twocolitem{\wxhelpref{wxKeyEvent}{wxkeyevent}}{A keypress event}
\twocolitem{\wxhelpref{wxIdleEvent}{wxidleevent}}{An idle event}
\twocolitem{\wxhelpref{wxInitDialogEvent}{wxinitdialogevent}}{A dialog initialisation event}
\twocolitem{\wxhelpref{wxJoystickEvent}{wxjoystickevent}}{A joystick event}
\twocolitem{\wxhelpref{wxMenuEvent}{wxmenuevent}}{A menu event}
\twocolitem{\wxhelpref{wxMouseEvent}{wxmouseevent}}{A mouse event}
\twocolitem{\wxhelpref{wxMoveEvent}{wxmoveevent}}{A move event}
\twocolitem{\wxhelpref{wxPaintEvent}{wxpaintevent}}{A paint event}
\twocolitem{\wxhelpref{wxQueryLayoutInfoEvent}{wxquerylayoutinfoevent}}{Used to query layout information}
\twocolitem{\wxhelpref{wxSizeEvent}{wxsizeevent}}{A size event}
\twocolitem{\wxhelpref{wxScrollWinEvent}{wxscrollwinevent}}{A scroll event sent by a scrolled window (not a scroll bar)}
\twocolitem{\wxhelpref{wxSysColourChangedEvent}{wxsyscolourchangedevent}}{A system colour change event}
\twocolitem{\wxhelpref{wxUpdateUIEvent}{wxupdateuievent}}{A user interface update event}
\end{twocollist}
In some cases, it might be desired by the programmer to get a certain number
of system events in a parent window, for example all key events sent to, but not
used by, the native controls in a dialog. In this case, a special event handler
will have to be written that will override ProcessEvent() in order to pass
all events (or any selection of them) to the parent window.
% VZ: it doesn't work like this, but just in case we ever reenable this
% behaviour, I leave it here
%
% \section{Redirection of command events to the window with the focus}
%
% The usual upward search through the window hierarchy for command event
% handlers does not always meet an application's requirements. Say you have two
% wxTextCtrl windows in a frame, plus a toolbar with Cut, Copy and Paste
% buttons. To avoid the need to define event handlers in the frame
% and redirect them explicitly to the window with the focus, command events
% are sent to the window with the focus first, for
% menu and toolbar command and UI update events only. This means that
% each window can handle its own commands and UI updates independently. In
% fact wxTextCtrl can handle Cut, Copy, Paste, Undo and Redo commands and UI update
% requests, so no extra coding is required to support them in your menus and
% toolbars.
\section{Pluggable event handlers}
In fact, you don't have to derive a new class from a window class
if you don't want to. You can derive a new class from wxEvtHandler instead,
defining the appropriate event table, and then call
\rtfsp\wxhelpref{wxWindow::SetEventHandler}{wxwindowseteventhandler} (or, preferably,
\rtfsp\wxhelpref{wxWindow::PushEventHandler}{wxwindowpusheventhandler}) to make this
event handler the object that responds to events. This way, you can avoid
a lot of class derivation, and use the same event handler object to
handle events from instances of different classes. If you ever have to call a window's event handler
manually, use the GetEventHandler function to retrieve the window's event handler and use that
to call the member function. By default, GetEventHandler returns a pointer to the window itself
unless an application has redirected event handling using SetEventHandler or PushEventHandler.
One use of PushEventHandler is to temporarily or permanently change the
behaviour of the GUI. For example, you might want to invoke a dialog editor
in your application that changes aspects of dialog boxes. You can
grab all the input for an existing dialog box, and edit it `in situ',
before restoring its behaviour to normal. So even if the application
has derived new classes to customize behaviour, your utility can indulge
in a spot of body-snatching. It could be a useful technique for on-line
tutorials, too, where you take a user through a serious of steps and
don't want them to diverge from the lesson. Here, you can examine the events
coming from buttons and windows, and if acceptable, pass them through to
the original event handler. Use PushEventHandler/PopEventHandler
to form a chain of event handlers, where each handler processes a different
range of events independently from the other handlers.
\section{Window identifiers}\label{windowids}
\index{identifiers}\index{wxID}Window identifiers are integers, and are used to uniquely determine window identity in the
event system (though you can use it for other purposes). In fact, identifiers do not need
to be unique across your entire application just so long as they are unique within a particular context you're interested
in, such as a frame and its children. You may use the wxID\_OK identifier, for example, on
any number of dialogs so long as you don't have several within the same dialog.
If you pass -1 to a window constructor, an identifier will be generated for you, but beware:
if things don't respond in the way they should, it could be because of an id conflict. It is safer
to supply window ids at all times. Automatic generation of identifiers starts at 1 so may well conflict
with your own identifiers.
The following standard identifiers are supplied. You can use wxID\_HIGHEST to determine the
number above which it is safe to define your own identifiers. Or, you can use identifiers below
wxID\_LOWEST.
\begin{verbatim}
#define wxID_LOWEST 4999
#define wxID_OPEN 5000
#define wxID_CLOSE 5001
#define wxID_NEW 5002
#define wxID_SAVE 5003
#define wxID_SAVEAS 5004
#define wxID_REVERT 5005
#define wxID_EXIT 5006
#define wxID_UNDO 5007
#define wxID_REDO 5008
#define wxID_HELP 5009
#define wxID_PRINT 5010
#define wxID_PRINT_SETUP 5011
#define wxID_PREVIEW 5012
#define wxID_ABOUT 5013
#define wxID_HELP_CONTENTS 5014
#define wxID_HELP_COMMANDS 5015
#define wxID_HELP_PROCEDURES 5016
#define wxID_HELP_CONTEXT 5017
#define wxID_CUT 5030
#define wxID_COPY 5031
#define wxID_PASTE 5032
#define wxID_CLEAR 5033
#define wxID_FIND 5034
#define wxID_DUPLICATE 5035
#define wxID_SELECTALL 5036
#define wxID_FILE1 5050
#define wxID_FILE2 5051
#define wxID_FILE3 5052
#define wxID_FILE4 5053
#define wxID_FILE5 5054
#define wxID_FILE6 5055
#define wxID_FILE7 5056
#define wxID_FILE8 5057
#define wxID_FILE9 5058
#define wxID_OK 5100
#define wxID_CANCEL 5101
#define wxID_APPLY 5102
#define wxID_YES 5103
#define wxID_NO 5104
#define wxID_STATIC 5105
#define wxID_HIGHEST 5999
\end{verbatim}
\section{Event macros summary}\label{eventmacros}
\wxheading{Generic event table macros}
\twocolwidtha{8cm}%
\begin{twocollist}\itemsep=0pt
\twocolitem{\windowstyle{EVT\_CUSTOM(event, id, func)}}{Allows you to add a custom event table
entry by specifying the event identifier (such as wxEVT\_SIZE), the window identifier,
and a member function to call.}
\twocolitem{\windowstyle{EVT\_CUSTOM\_RANGE(event, id1, id2, func)}}{The same as EVT\_CUSTOM,
but responds to a range of window identifiers.}
\twocolitem{\windowstyle{EVT\_COMMAND(id, event, func)}}{The same as EVT\_CUSTOM, but
expects a member function with a wxCommandEvent argument.}
\twocolitem{\windowstyle{EVT\_COMMAND\_RANGE(id1, id2, event, func)}}{The same as EVT\_CUSTOM\_RANGE, but
expects a member function with a wxCommandEvent argument.}
\end{twocollist}
\wxheading{Macros listed by event class}
The documentation for specific event macros is organised by event class. Please refer
to these sections for details.
\twocolwidtha{8cm}%
\begin{twocollist}\itemsep=0pt
\twocolitem{\wxhelpref{wxActivateEvent}{wxactivateevent}}{The EVT\_ACTIVATE and EVT\_ACTIVATE\_APP macros intercept
activation and deactivation events.}
\twocolitem{\wxhelpref{wxCommandEvent}{wxcommandevent}}{A range of commonly-used control events.}
\twocolitem{\wxhelpref{wxCloseEvent}{wxcloseevent}}{The EVT\_CLOSE macro handles window closure
called via \wxhelpref{wxWindow::Close}{wxwindowclose}.}
\twocolitem{\wxhelpref{wxDropFilesEvent}{wxdropfilesevent}}{The EVT\_DROP\_FILES macros handles
file drop events.}
\twocolitem{\wxhelpref{wxEraseEvent}{wxeraseevent}}{The EVT\_ERASE\_BACKGROUND macro is used to handle window erase requests.}
\twocolitem{\wxhelpref{wxFocusEvent}{wxfocusevent}}{The EVT\_SET\_FOCUS and EVT\_KILL\_FOCUS macros are used to handle keyboard focus events.}
\twocolitem{\wxhelpref{wxKeyEvent}{wxkeyevent}}{EVT\_CHAR and EVT\_CHAR\_HOOK macros handle keyboard
input for any window.}
\twocolitem{\wxhelpref{wxIdleEvent}{wxidleevent}}{The EVT\_IDLE macro handle application idle events
(to process background tasks, for example).}
\twocolitem{\wxhelpref{wxInitDialogEvent}{wxinitdialogevent}}{The EVT\_INIT\_DIALOG macro is used
to handle dialog initialisation.}
\twocolitem{\wxhelpref{wxListEvent}{wxlistevent}}{These macros handle \wxhelpref{wxListCtrl}{wxlistctrl} events.}
\twocolitem{\wxhelpref{wxMenuEvent}{wxmenuevent}}{These macros handle special menu events (not menu commands).}
\twocolitem{\wxhelpref{wxMouseEvent}{wxmouseevent}}{Mouse event macros can handle either individual
mouse events or all mouse events.}
\twocolitem{\wxhelpref{wxMoveEvent}{wxmoveevent}}{The EVT\_MOVE macro is used to handle a window move.}
\twocolitem{\wxhelpref{wxPaintEvent}{wxpaintevent}}{The EVT\_PAINT macro is used to handle window paint requests.}
\twocolitem{\wxhelpref{wxScrollEvent}{wxscrollevent}}{These macros are used to handle scroll events from
\wxhelpref{wxScrollBar}{wxscrollbar}, \wxhelpref{wxSlider}{wxslider},and \wxhelpref{wxSpinButton}{wxspinbutton}.}
\twocolitem{\wxhelpref{wxSizeEvent}{wxsizeevent}}{The EVT\_SIZE macro is used to handle a window resize.}
\twocolitem{\wxhelpref{wxSplitterEvent}{wxsplitterevent}}{The EVT\_SPLITTER\_SASH\_POS\_CHANGED, EVT\_SPLITTER\_UNSPLIT
and EVT\_SPLITTER\_DCLICK macros are used to handle the various splitter window events.}
\twocolitem{\wxhelpref{wxSysColourChangedEvent}{wxsyscolourchangedevent}}{The EVT\_SYS\_COLOUR\_CHANGED macro is used to handle
events informing the application that the user has changed the system colours (Windows only).}
\twocolitem{\wxhelpref{wxTreeEvent}{wxtreeevent}}{These macros handle \wxhelpref{wxTreeCtrl}{wxtreectrl} events.}
\twocolitem{\wxhelpref{wxUpdateUIEvent}{wxupdateuievent}}{The EVT\_UPDATE\_UI macro is used to handle user interface
update pseudo-events, which are generated to give the application the chance to update the visual state of menus,
toolbars and controls.}
\end{twocollist}

View File

@@ -1,7 +0,0 @@
\chapter{The clipboard and drag-and-drop}\label{chapclipboard}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: THE CLIPBOARD AND DRAG-AND-DROP}}{}{}{}{}{{\it CHAPTER \thechapter: THE CLIPBOARD AND DRAG-AND-DROP}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
In which the murky workings of data transfer are ably described by One Who Knows.

View File

@@ -1,7 +0,0 @@
\chapter{Common dialogs}\label{commondialogs}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: COMMON DIALOGS}}{}{}{}{}{{\it CHAPTER \thechapter: COMMON DIALOGS}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
In which common dialogs, such as file and colour selectors, are described.

View File

@@ -1,7 +0,0 @@
\chapter{Interprocess communication}\label{chapcomms}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: INTERPROCESS COMMUNICATION}}{}{}{}{}{{\it CHAPTER \thechapter: INTERPROCESS COMMUNICATION}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
wxSocket, wxIPC, protocols...

View File

@@ -1,10 +0,0 @@
\chapter{Comparison with other toolkits}\label{chapcomparison}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: COMPARISON WITH OTHER TOOLKITS}}{}{}{}{}{{\it CHAPTER \thechapter: COMPARISON WITH OTHER TOOLKITS}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
In which we show the world how wonderful wxWindows is compared with the competition. But ever so modestly.
Actually, this chapter should be full of helpful tips for converting one's knowledge/apps from other toolkits
such as MFC.

View File

@@ -1,7 +0,0 @@
\chapter{Handling application settings with wxConfig}\label{chapconfig}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: HANDLING APPLICATION SETTINGS}}{}{}{}{}{{\it CHAPTER \thechapter: HANDLING APPLICATION SETTINGS}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
Using the wxConfig family of classes to save and restore application settings.

View File

@@ -1,8 +0,0 @@
\chapter{wxWindows and C++}\label{chapcpp}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: wxWINDOWS AND C++}}{}{}{}{}{{\it CHAPTER \thechapter: wxWINDOWS AND C++}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
What kind of C++ constructs wxWindows uses and doesn't use, and a little introduction to
some important classes such as wxString. Why STL isn't used within wxWindows.

View File

@@ -1,7 +0,0 @@
\chapter{Custom dialogs and resources}\label{chapcustomdialogs}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: CUSTOM DIALOGS AND RESOURCES}}{}{}{}{}{{\it CHAPTER \thechapter: CUSTOM DIALOGS AND RESOURCES}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
wxDialog introduced, and how XML resources work.

View File

@@ -1,7 +0,0 @@
\chapter{Data classes}\label{chapdataclasses}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: DATA CLASSES}}{}{}{}{}{{\it CHAPTER \thechapter: DATA CLASSES}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
Important collection and container classes in wxWindows.

View File

@@ -1,9 +0,0 @@
\chapter{Working with databases}\label{chapdatabase}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: WORKING WITH DATABASES}}{}{}{}{}{{\it CHAPTER \thechapter: WORKING WITH DATABASES}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
Using databases in wxWindows. This chapter mainly covers the wxDb ODBC classes, but should also
mention other cross-platform libraries such as Xbase. And perhaps a quick mention of wxExpr for very simple
data storage needs.

View File

@@ -1,7 +0,0 @@
\chapter{The document view framework}\label{chapdocview}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: THE DOCUMENT VIEW FRAMEWORK}}{}{}{}{}{{\it CHAPTER \thechapter: THE DOCUMENT VIEW FRAMEWORK}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
This chapter describes the document/view framework and in what situations it can be useful.

View File

@@ -1,118 +0,0 @@
\chapter{Drawing on device contexts}\label{chapdrawing}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: DRAWING ON DEVICE CONTEXTS}}{}{}{}{}{{\it CHAPTER \thechapter: DRAWING ON DEVICE CONTEXTS}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
\section{The concept of device contexts}
Device contexts, commonly referred as DCs, represent more or less anything
you can draw into, i.e. a window, a bitmap, the screen, a printer, a Postscript
file, most recently even an SVG file. There is one abstract base class (wxDC)
which defines the interface for all other classes so that drawing code for
one device context can be used for all others as well - with certain limitation
as the hardware specifies (e.g. you cannot read a pixel from a printer).
\section{Drawing into windows}
Let's start with the most simple case: you want to draw a line in a window.
Or rather not the window, but its client area, the usually white or grey
large area that is surrounded by the window's decorations such as its border
which you normally would not want to draw over.
In addition to defining classes that represent devices, wxWindows has a few
of classes that define colours and so-called pens and brushes. A pen is used
for drawing lines (which can be a curve or a rectangle) whereas brushes are
used to paint areas, such as a filled rectangle or a filled circle. Indeed,
you can use both at the same time for drawing a rectangle which is both filled
and has a border. If you want to draw a red rectangle with a black border,
you will do this:
\begin{verbatim}
void MyWindow::DrawSomething()
{
wxClientDC dc(this);
dc.SetPen( *wxBLACK_PEN );
dc.SetBrush( *wxRED_BRUSH );
dc.DrawRectangle( 0, 0, 100, 100 );
}
\end{verbatim}
If you want to draw a rectangle without any border, you can use the special
oen wxTRANSPARENT_PEN, if the rectangle is not supposed to be filled with
any colour, you use the special brush wxTRANSPARENT_BRUSH. When using both
these special classes, you could draw an invisible rectangle like this:
\begin{verbatim}
void MyWindow::DrawNothing()
{
wxClientDC dc(this);
dc.SetPen( *wxTRANSPARENT_PEN );
dc.SetBrush( *wxTRANSPARENT_BRUSH );
dc.DrawRectangle( 0, 0, 100, 100 );
}
\end{verbatim}
Now what happens when you window gets obscured by another window and
then returns to the surface again? The rectangle will not appear again
because a window does not remember what has been drawn into it. Instead,
your program has to remember what to draw and where and it will receive
a so called wxPaintEvent indicating that some region has been unobscured
and needs repainting. In order to catch such an event so that you can
react appropriately to it, you will have to set up an event handler
like this:
\begin{verbatim}
BEGIN_EVENT_TABLE(MyWindow, wxWindow)
EVT_PAINT (MyWindow::OnPaint)
END_EVENT_TABLE()
void MyWindow::OnPaint( wxPaintEvent &event )
{
wxPaintDC dc(this);
dc.SetPen( *wxBLACK_PEN );
dc.SetBrush( *wxRED_BRUSH );
dc.DrawRectangle( 0, 0, 100, 100 );
}
\end{verbatim}
Note that this time, you have to use a wxPaintDC as these are used
in connection with wxPaintEvents. Note also, that every such handler
has to use a wxPaintDC even of you (for the moment) don't draw anything.
If there is no such wxPaintDC, your program will not work under Windows.
One difference between a wxPaintDC and a wxClientDC is that the wxPaintDC
always sets a clipping region to the region of the window that was
unobscured with the effect that all drawing commands will be clipped to
that region. This leads to a reduction of flicker as only those
areas of the window get redrawn, which actually need to get redrawn.
\section{Querying the update region}
Call me lazy:
\begin{verbatim}
BEGIN_EVENT_TABLE(MyWindow, wxWindow)
EVT_PAINT (MyWindow::OnPaint)
END_EVENT_TABLE()
void MyWindow::OnPaint( wxPaintEvent &event )
{
wxPaintDC dc(this);
if (IsExposed( 0, 0, 100, 100))
{
dc.SetPen( *wxBLACK_PEN );
dc.SetBrush( *wxRED_BRUSH );
dc.DrawRectangle( 0, 0, 100, 100 );
}
}
\end{verbatim}

View File

@@ -1,7 +0,0 @@
\chapter{Working with files and streams}\label{chapfilestream}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: WORKING WITH FILES AND STREAMS}}{}{}{}{}{{\it CHAPTER \thechapter: WORKING WITH FILES AND STREAMS}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
All about the file and stream handling facilities in wxWindows.

View File

@@ -1,7 +0,0 @@
\chapter{Working with frames}\label{chapframes}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: WORKING WITH FRAMES}}{}{}{}{}{{\it CHAPTER \thechapter: WORKING WITH FRAMES}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
The humble wxFrame, menubars, etc. Should the toolbar chapter be merged with this one?

View File

@@ -1,7 +0,0 @@
\chapter{Getting started}\label{gettingstarted}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: GETTING STARTED}}{}{}{}{}{{\it CHAPTER \thechapter: GETTING STARTED}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
Getting started: Hello World. Introduces app class, frames, menus, status bar, message box.

View File

@@ -1,7 +0,0 @@
\chapter{Adding online help to your application}\label{chaphelp}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: ADDING ONLINE HELP TO YOUR APPLICATION}}{}{}{}{}{{\it CHAPTER \thechapter: ADDING ONLINE HELP TO YOUR APPLICATION}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
The varieties of help you can add to your masterwork.

View File

@@ -1,62 +0,0 @@
\chapter{Images and bitmaps}\label{chapimages}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: IMAGES AND BITMAPS}}{}{}{}{}{{\it CHAPTER \thechapter: IMAGES AND BITMAPS}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
\section{The basics of images and bitmaps}
Both wxImage and wxBitmap represent what would commonly be referred as
a photo with a given number of pixels - in contrast to a drawing consisting
of a collection of lines, curves, circles, squares etc.
The difference between a wxImage and a wxBitmap is that wxImage is a
platform and screen independent representation of an image - every
pixel is always represented by three bytes, one for red, one for green
and one for blue, thus yielding the classical RGB acronym. Due to the
simplicity of wxImage, you will do all kinds of image manipulation
with this class, this includes loading images in various formats
such as GIF, TIFF or JPEG (these and some more are supported by wxWindows
without further work), analyzing the image in terms of colour usage etc
and applying filters to the image for higher-level manipulation, such
as blurring, sharpening etc.
The problem with wxImage is that you cannot draw it, i.e. its destiny
is to live its shadow life in memory, without ever being seen by man.
If you ever want to draw an image to screen, you have to convert it
to a wxBitmap first, typically, this will look like this:
\begin{verbatim}
wxImage image( 200, 200 );
wxBitmap bitmap( image.ConvertToBitmap() );
wxClientDC dc( this )
dc.DrawBitmap( bitmap );
\end{verbatim}
Note, that such as image conversion is an extremely expensive operation
and you are very well advised to avoid having to call this routine
more than absolutely required. In practice, you should not do this
in a paint event handler, for instance.
There is one more thing you can do with a wxBitmap: you can draw into
it like you would do with a window. All you need to do is set up a
proper device context (DC) for it and ensure that you clean up the
DC correctly afterwards:
\begin{verbatim}
wxBitmap bitmap( 200, 200 );
wxMemoryDC dc;
dc.SelectObject( bitmap );
dc.SetPen( *wxBLACK_PEN );
dc.DrawLine( 0, 0, 199, 199 );
dc.SelectObject( wxNullBitmap );
\end{verbatim}
\section{wxImage built-in features}
You can save it, load it, get access to it, assign it a mask colour,
turn it around, mirror it.

View File

@@ -1,7 +0,0 @@
\chapter{Handling input}\label{chapinput}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: HANDLING INPUT}}{}{}{}{}{{\it CHAPTER \thechapter: HANDLING INPUT}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
Handling input from keyboard, mouse and joystick.

View File

@@ -1,467 +0,0 @@
\chapter{Installing wxWindows}\label{chapinstall}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: INSTALLING wxWINDOWS}}{}{}{}{}{{\it CHAPTER \thechapter: INSTALLING wxWINDOWS}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
CONTENTS: Installing wxWindows (and what tools to use).
Installing wxWindows isn't too hard. Each platform has a different method, so we'll look
at each major platform in turn.
\section{Unix: GTK+ and Motif}\label{installunix}
\subsection{The simplest case}
If you are compile wxWindows on Linux for the first time and don't like to read
install instructions, just do this in the base directory:
\begin{verbatim}
./configure --with-gtk
make
su <type root password>
make install
ldconfig
exit
\end{verbatim}
This is using the GTK+ port. If using the Motif port, type --with-motif instead of --with-gtk.
Afterwards you can continue with:
\begin{verbatim}
make
su <type root password>
make install
ldconfig
exit
\end{verbatim}
If you want to remove wxWindows on Unix you can do this:
\begin{verbatim}
su <type root password>
make uninstall
ldconfig
exit
\end{verbatim}
\subsection{The expert case}
If you want to do some more serious cross-platform programming with wxWindows,
such as for GTK and Motif, you can now build two complete libraries and use
them concurrently. For this end, you have to create a directory for each build
of wxWindows - you may also want to create different versions of wxWindows
and test them concurrently. Most typically, this would be a version configured
with --enable-debug\_flag and one without. Note, that only one build can currently
be installed, so you'd have to use a local version of the library for that purpose.
For building three versions (one for GTK+, one for Motif and a debug GTK+ version) you'd do this:
\begin{verbatim}
md buildmotif
cd buildmotif
../configure --with-motif
make
cd ..
md buildgtk
cd buildgtk
../configure --with-gtk
make
cd ..
md buildgtkd
cd buildgtkd
../configure --with-gtk --enable-debug_flag
make
cd ..
\end{verbatim}
\subsection{The simplest errors}
\begin{itemize}\itemsep=0pt
\item Configure reports, that you don't have GTK 1.2 installed although you are
very sure you have. Well, you have installed it, but you also have another
version of the GTK installed, which you may need to remove including other
versions of glib (and its headers). Also, look for the PATH variable and check
if it includes the path to the correct gtk-config! The check your LDPATH if it
points to the correct library. There is no way to compile wxGTK if configure
doesn't pass this test as all this test does is compile and link a GTK program.
\item You get errors during compilation: The reason is that you probably have a
broken compiler. GCC 2.8 and earlier versions and egcs are likely to cause
problems due to incomplete support for C++ and optimisation bugs. Best to use
GCC 2.95 or later.
\item You get immediate segfault when starting any sample or application: This is
either due to having compiled the library with different flags or options than
your program - typically you might have the \_\_WXDEBUG\_\_ option set for the
library but not for your program - or due to using a compiler with optimisation
bugs.
\end{itemize}
\subsection{The simplest program}
Now create your super-application myfoo.app and compile anywhere with:
\begin{verbatim}
g++ myfoo.cpp `wx-config --libs --cxxflags` -o myfoo
\end{verbatim}
\wxheading{General}
The Unix variants of wxWindows use GNU configure. If you have problems with your
make use GNU make instead.
If you have general problems with installation, visit Robert Roebling's homepage at
\begin{verbatim}
http://wesley.informatik.uni-freiburg.de/~wxxt
\end{verbatim}
for the latest information. If you still don't have any success, please send a bug
report to one of the mailing lists.
\wxheading{Libraries needed}
wxWindows/GTK requires the GTK+ library to be installed on your system. It has to
be a stable version, preferably version 1.2.3.
You can get the newest version of the GTK+ from the GTK homepage at:
\begin{verbatim}
http://www.gtk.org
\end{verbatim}
wxWindows/Gtk requires a thread library and X libraries known to work with threads.
This is the case on all commercial Unix-Variants and all Linux-Versions that are
based on glibc 2 except RedHat 5.0 which is broken in many aspects. As of writing
this, these Linux distributions have correct glibc 2 support:
\begin{itemize}\itemsep=0pt
\item RedHat 5.1
\item Debian 2.0 and 3.0
\item Stampede
\item DLD 6.0
\item SuSE 6.0
\end{itemize}
You can disable thread support by running
\begin{verbatim}
./configure --disable-threads
make
su <type root password>
make install
ldconfig
exit
\end{verbatim}
\subsection{Building wxGTK on OS/2}
Please send comments and question about the OS/2 installation
to Andrea Venturoli <a.ventu@flashnet.it> and patches to
the wxWindows mailing list.
You'll need OS/2 Warp (4.00FP#6), X-Free86/2 (3.3.3 or newer),
GTK+ (1.2.5 or newer), emx (0.9d fix 1), flex (2.5.4), yacc (1.8),
korn shell (5.2.13), Autoconf (2.13), GNU file utilities (3.6),
GNU text utilities (1.3), GNU shell utilites (1.12), m4 (1.4),
sed (2.05), grep (2.0), Awk (3.0.3), GNU Make (3.76.1).
Open an OS/2 prompt and switch to the directory above.
First set some global environment variables we need:
\begin{verbatim}
SET CXXFLAGS=-Zmtd -D__ST_MT_ERRNO__
SET CFLAGS=-Zmtd -D__ST_MT_ERRNO__
SET OSTYPE=OS2X
SET COMSPEC=sh
\end{verbatim}
Notice you can choose whatever you want, if you don't like OS2X.
Now, run autoconf in the main directory and in the samples, demos
and utils subdirectory. This will generate the OS/2 specific
versions of the configure scripts. Now run
\begin{verbatim}
configure --with-gtk
\end{verbatim}
as described above.
If you have pthreads library installed, but have a gtk version
which does not yet support threading, you need to explicitly
disable threading by using the option --disable-threads.
Note that configure assumes your flex will generate files named
"lexyy.c", not "lex.yy.c". If you have a version which does
generate "lex.yy.c", you need to manually change the generated
makefile.
\subsection{Building wxGTK on SGI}
Using the SGI native compilers, it is recommended that you
also set CFLAGS and CXXFLAGS before running configure. These
should be set to:
\begin{verbatim}
CFLAGS="-mips3 -n32"
CXXFLAGS="-mips3 -n32"
\end{verbatim}
This is essential if you want to use the resultant binaries
on any other machine than the one it was compiled on. If you
have a 64-bit machine (Octane) you should also do this to ensure
you don't accidently build the libraries as 64bit (which is
untested).
The SGI native compiler support has only been tested on Irix 6.5.
\subsection{Create your configuration}
Usage:
\begin{verbatim}
./configure options
\end{verbatim}
If you want to use system's C and C++ compiler,
set environment variables CC and CCC as
\begin{verbatim}
setenv CC cc
setenv CCC CC
./configure options
\end{verbatim}
to see all the options please use:
\begin{verbatim}
./configure --help
\end{verbatim}
The basic philosophy is that if you want to use different
configurations, like a debug and a release version,
or use the same source tree on different systems,
you have only to change the environment variable OSTYPE.
(Sadly this variable is not set by default on some systems
in some shells - on SGI's for example). So you will have to
set it there. This variable HAS to be set before starting
configure, so that it knows which system it tries to
configure for.
Configure (and sometimes make) will complain if the system variable OSTYPE has
not been defined.
\subsubsection{General options}
Given below are the commands to change the default behaviour,
i.e. if it says "--disable-threads" it means that threads
are enabled by default.
Normally, you won't have to choose a toolkit, because when
you download wxGTK, it will default to --with-gtk etc. But
if you use all of our CVS repository you have to choose a
toolkit. You must do this by running configure with either of:
\begin{verbatim}
--without-gtk Don't use the GIMP ToolKit (GTK)
--with-motif Use either Motif or Lesstif
Configure will look for both.
\end{verbatim}
The following options handle the kind of library you want to build.
\begin{verbatim}
--disable-threads Compile without thread support.
--disable-shared Do not create shared libraries.
--enable-static Create static libraries.
--disable-optimise Do not optimise the code. Can
sometimes be useful for debugging
and is required on some architectures
such as Sun with gcc 2.8.X which
and otherwise produce segvs.
--enable-profile Add profiling info to the object
files. Currently broken, I think.
--enable-no_rtti Enable compilation without creation of
C++ RTTI information in object files.
This will speed-up compilation and reduce
binary size.
--enable-no_exceptions Enable compilation without creation of
C++ exception information in object files.
This will speed-up compilation and reduce
binary size. Also fewer crashes during the
actual compilation...
--enable-no_deps Enable compilation without creation of
dependency information.
--enable-permissive Enable compilation without checking for strict
ANSI conformance. Useful to prevent the build
dying with errors as soon as you compile with
Solaris' ANSI-defying headers.
--enable-mem_tracing Add built-in memory tracing.
--enable-dmalloc Use the dmalloc memory debugger.
Read more at www.letters.com/dmalloc/
--enable-debug_info Add debug info to object files and
executables for use with debuggers
such as gdb (or its many frontends).
--enable-debug_flag Define __DEBUG__ and __WXDEBUG__ when
compiling. This enable wxWindows' very
useful internal debugging tricks (such
as automatically reporting illegal calls)
to work. Note that program and library
must be compiled with the same debug
options.
\end{verbatim}
\subsubsection{Feature Options}
When producing an executable that is linked statically with wxGTK
you'll be surprised at its immense size. This can sometimes be
drastically reduced by removing features from wxWindows that
are not used in your program. The most relevant such features
are
\begin{verbatim}
--with-odbc Enables ODBC code. This is disabled
by default because iODBC is under the
L-GPL license.
--without-libpng Disables PNG image format code.
--without-libjpeg Disables JPEG image format code.
--without-libtiff Disables TIFF image format code.
--disable-pnm Disables PNM image format code.
--disable-gif Disables GIF image format code.
--disable-pcx Disables PCX image format code.
--disable-resources Disables the use of *.wxr type
resources.
--disable-threads Disables threads. Will also
disable sockets.
--disable-sockets Disables sockets.
--disable-dnd Disables Drag'n'Drop.
--disable-clipboard Disables Clipboard.
--disable-serial Disables object instance serialisation.
--disable-streams Disables the wxStream classes.
--disable-file Disables the wxFile class.
--disable-textfile Disables the wxTextFile class.
--disable-intl Disables the internationalisation.
--disable-validators Disables validators.
--disable-accel Disables accel.
\end{verbatim}
Apart from disabling certain features you can very often "strip"
the program of its debugging information resulting in a significant
reduction in size.
\subsubsection{Compiling}
The following must be done in the base directory (e.g. ~/wxGTK
or ~/wxWin or whatever)
Now the makefiles are created (by configure) and you can compile
the library by typing:
\begin{verbatim}
make
\end{verbatim}
make yourself some coffee, as it will take some time. On an old
386SX possibly two weeks. During compilation, you'll get a few
warning messages depending in your compiler.
If you want to be more selective, you can change into a specific
directory and type "make" there.
Then you may install the library and it's header files under
/usr/local/include/wx and /usr/local/lib respectively. You
have to log in as root (i.e. run "su" and enter the root
password) and type
\begin{verbatim}
make install
\end{verbatim}
You can remove any traces of wxWindows by typing
\begin{verbatim}
make uninstall
\end{verbatim}
If you want to save disk space by removing unnecessary
object-files:
\begin{verbatim}
make clean
\end{verbatim}
in the various directories will do the work for you.
\subsubsection{Creating a new Project}
1\ket The first way uses the installed libraries and header files
automatically using wx-config
\begin{verbatim}
g++ myfoo.cpp `wx-config --cxxflags --libs` -o myfoo
\end{verbatim}
Using this way, a make file for the minimal sample would look
like this
\begin{verbatim}
CXX = g++
minimal: minimal.o
$(CXX) -o minimal minimal.o `wx-config --libs`
minimal.o: minimal.cpp mondrian.xpm
$(CXX) `wx-config --cxxflags` -c minimal.cpp -o minimal.o
clean:
rm -f *.o minimal
\end{verbatim}
This is certain to become the standard way unless we decide
to stick to tmake.
2\ket The other way creates a project within the source code
directories of wxWindows. For this endeavour, you'll need
GNU autoconf version 2.14 and add an entry to your Makefile.in
to the bottom of the configure.in script and run autoconf
and configure before you can type make.
\section{Windows}\label{installwindows}
\section{Mac}\label{installmac}
We don't have information about Mac installation at this time.

View File

@@ -1,180 +0,0 @@
\chapter{Introducing wxWindows}\label{chapintro}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: INTRODUCING wxWINDOWS}}{}{}{}{}{{\it CHAPTER \thechapter: INTRODUCING wxWINDOWS}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
\section{The need for portability}
Not so long ago, it seemed as though Microsoft was on course to
take over the desktop for good with the Windows range of
operating systems. Unix was retreating to server territory and
had all but given up the fight against NT. Apple was sickening
(in the non-derogatory sense of the word!) and it seemed almost
common sense that the quirky Mac had had its day.
At the start of the new century, the picture has changed quite
dramatically. Linux is advancing from its position of strength
in the server market and is poised to make inroads on the
desktop, where the high price of Windows gives it an advantage.
Apple has made an impressive comeback and is revamping its own
operating system. The embedded market continues to explode and
has given rise to new niches for specialist operating systems.
The keyword now is diversity, when the best guess of a few years
was that Microsoft would conquer all. More than ever,
application developers need to keep their options open and
targeting one platform only can be a recipe for commercial (or
open source) disaster.
In the light of this change in the computing landscape,
cross-platform development (or multiplatform development as we
call it in this book) has become quite a hot and sometimes
bitterly controversial topic. There are a number of ways to
achieve the goal of portability, and many tools and languages to choose from.
However, it is still generally agreed wisdom that C++ is the
language of choice for desktop applications that depend on
speed, ease of delivery and compatibility with billions of lines
of existing code. Plus, there are many hundreds of thousands of
developers now experienced in C++ programming.
The purpose of this book is to give you (the developer or
interested manager) a solid grounding in one increasingly
popular multiplatform solution: wxWindows. wxWindows is an open
source GUI toolkit that has been on the scene since 1993 and has
reached a high degree of stability and functionality. It is
available for Linux (and most other Unix variants), all desktop
versions of Microsoft Windows, and Mac. Other ports are in
progress.
\section{Why wxWindows?}
While wxWindows is labelled a GUI development toolkit, it is in
fact much more than that and has many features that are useful
for many aspects of application development. This has to
be the case, since the whole of a wxWindows application needs to
be portable to different platforms, and not just the GUI
component. So wxWindows provides classes for working with files
and streams, multithreading, management of application settings,
interprocess communication, and much else.
wxWindows is open source, with a vibrant developer and user
community, and may be used in any proprietary or non-proprietary
project. wxWindows encompasses the whole spectrum of users from
one-man software outfits to big-name companies such as Xerox,
Lockheed-Martin, Pratt and Whitney, and Motorola; from computer
science departments to medical research groups; from ecological
research, to the telecommunications industry, and in a myriad of
open source projects.
When you use wxWindows you tap into an astonishing talent pool,
with contributors from a wide range of backgrounds. Many aspects
of application development that you might otherwise have to
laboriously code yourself have been encapsulated by these
developers in easy-to-use classes that you can plug into your
code. Since there are a lot of people subscribed to the mailing
lists, you'll enjoy discussions not only about wxWindows but
often other matters close to the hearts of both experienced and
inexperienced developers. And hopefully, one day you'll join in the
success of wxWindows and become a contributor yourself!
\section{The history of wxWindows}
wxWindows was started in 1992 at the Artificial Intelligence
Applications Institute, University of Edinburgh, by Julian
Smart. Julian was designing a kind of meta-CASE tool called
Hardy which needed to run on Windows as well as X-based Unix
workstations. The existing commercial cross-platform tools were
deemed too expensive for an in-house experimental project, so
the only alternative was to build one. wxWindows (w for Microsoft
Windows, x for the X Windowing System) started off with support for Sun's XView
and Microsoft's MFC 1.0, and
AIAI allowed it to be released to the Internet. As it became
clear that XView was doomed, a Motif port was written. Borland
C++ users began to request a version that was not dependent on
MFC, so the Windows port was rewritten to use the native Windows
API. Over time, a small but enthusiastic community of wxWindows
users was established and a mailing list set up. Many contributions
and fixes were sent in. wxWindows gradually picked up more and more users
from all over the world: academic, government, and corporate users
who found that wxWindows offered a better product, and better support, than the
commercial products they had looked at or used.
During 1995, Markus Holzem released his port of wxWindows to Xt,
the X toolkit. This meant that software could be written that
would work on X-based systems without the need for installing Motif,
then still a commercial product.
In 1996, Julian left AIAI to pursue freelance consultancy, and
there were few new releases. The seemingly unstoppable advance
of Java was throwing some doubt on the future of C++ libraries.
After many contributions, the wxWindows code was looking rather
tired and in need of a serious rethink. At the start of 1997 it
was make or break time - call it a day and move onto other
things, or commit to re-engineering wxWindows with an API that
was flexible enough for current and future user interface
trends, with more sophisticated widgets, and making better use of C++.
After a short debate, the effort was relaunched
with Julian concentrating on the Windows port, and Markus on the combined Motif/Xt port,
with both contributing to the common and generic parts. wxWindows 2 API
ideas and code started to take shape.
During 1997 an effort to produce a standard Linux desktop
environment was underway - GNOME. Its widget set was GTK+, built
on top of X11 and it looked as though GTK+-based apps were to
become the standard in the Linux universe. Its one major problem:
GTK+ was C-based, and only a thin (and unportable) C++ wrapper
existed for it. In August 1997, Wolfram Gloger made a suggestion
that wxWindows 2 should be ported to GTK+ - Robert Roebling had
initial reservations, but in general supported the idea. He
became the prime mover for wxGTK and alphas were made available
at the beginning of 1998. In May 1998 the Windows and GTK+ ports
were merged and put into a CVS repository made available to all
contributors to wxWindows: a decision that has accelerated the development
effort tremendously. At this point Vadim Zeitlin became a prime
mover on the Windows port and revamped much of the container
and collection support.
Markus Holzem had to drop out of the wxWindows 2 effort in early
1998, but Julian Smart started a new wxMotif port. The idea of
an Xt port was dropped, since there remain two possibilities for
free Unix programming with wxWindows: wxGTK, and wxMotif using
the Motif clone Lesstif.
In September 1998, Stefan Csomor started a new version of the
wxMac 2 port based in part on Greg Whitehead's initial work.
In 1999 wxMac became ready for prime-time and Stefan has
made it ready for MacOS X.
Also in 1998, Vaclav Slavik burst onto the wxWindows scene with his
exciting wxHTML module that can now provide applications with (to name but a few) HTML help, superb
About boxes, and report viewing and printing facilities. Vaclav has
also written an enhanced resource system for wxWindows based on XML,
that supports many more wxWindows features than the old WXR-based system.
Since 1998 Robin Dunn has been completely rewriting the old Python/wxWindows
marriage and now wxPython is another force to be reckoned with in the
development community.
%David Webster and Stefan Neis have been working on an OS/2 port, and
%interest has been expressed in ports to other systems, such as
%BeOS.
%
Development on wxWindows is concentrating on achieving more modularity,
additional sophisticated GUI components, and compatibility with
a wider range platforms. The wxStudio IDE project promises to
make wxWindows development much easier and introduce wxWindows to people
used to rapid application development environments under Microsoft Windows.
\section{How to use this book}
The chapters in this book are meant to be fairly independent, but
as usual, the ordering reflects a progression from basic concepts
to more advanced ones, so the first few chapters at least
should be read consecutively for best effect.
Complete programs illustrating concepts in many of the chapters can be
found in the accompanying CD-ROM, along with wxWindows itself and lots
of extra, cool stuff.
We all hope that you enjoy reading this book and, most importantly,
have fun using wxWindows to build great-looking, multiplatform applications!

View File

@@ -1,7 +0,0 @@
\chapter{The multiple document interface}\label{chapmdi}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: MDI}}{}{}{}{}{{\it CHAPTER \thechapter: MDI}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
MDI.

View File

@@ -1,7 +0,0 @@
\chapter{Memory management and debugging}\label{chapdebug}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: MEMORY MANAGEMENT AND DEBUGGING}}{}{}{}{}{{\it CHAPTER \thechapter: MEMORY MANAGEMENT AND DEBUGGING}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
Memory management, debugging, wxLog, ...

View File

@@ -1,7 +0,0 @@
\chapter{Multithreading your application}\label{chapmultithreading}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: MULTITHREADING YOUR APPLICATION}}{}{}{}{}{{\it CHAPTER \thechapter: MULTITHREADING YOUR APPLICATION}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
Multithreading.

View File

@@ -1,8 +0,0 @@
\chapter{Perfecting your application}\label{chapperfecting}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: PERFECTING YOUR APPLICATION}}{}{}{}{}{{\it CHAPTER \thechapter: PERFECTING YOUR APPLICATION}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
Finishing touches: UI update, splash screen, about box, managing registration, help files (see specific chapter),
making an installation.

View File

@@ -1,7 +0,0 @@
\chapter{Platform-specific classes}\label{chapplatform}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: PLATFORM-SPECIFIC CLASSES}}{}{}{}{}{{\it CHAPTER \thechapter: PLATFORM-SPECIFIC CLASSES}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
Metafiles, OLE automation, GNOME integration, taskbar, ...

View File

@@ -1,7 +0,0 @@
\chapter{Adding printing to your application}\label{chapprinting}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: ADDING PRINTING TO YOUR APPLICATION}}{}{}{}{}{{\it CHAPTER \thechapter: ADDING PRINTING TO YOUR APPLICATION}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
The joys of printing.

View File

@@ -1,12 +0,0 @@
\chapter{Further resources}\label{chapresources}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: FURTHER RESOURCES}}{}{}{}{}{{\it CHAPTER \thechapter: FURTHER RESOURCES}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
A compendium of external resources, such as:
\begin{itemize}\itemsep=0pt
\item \urlref{wxTTS}{http://www.anthemion.co.uk/code.htm}
\item Xbase
\end{itemize}

View File

@@ -1,7 +0,0 @@
\chapter{Using run-time class information}\label{chapruntime}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: USING RUN-TIME CLASS INFORMATION}}{}{}{}{}{{\it CHAPTER \thechapter: USING RUN-TIME CLASS INFORMATION}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
CLASSINFO and friends.

View File

@@ -1,7 +0,0 @@
\chapter{Managing scrolling}\label{chapscrolling}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: MANAGING SCROLLING}}{}{}{}{}{{\it CHAPTER \thechapter: MANAGING SCROLLING}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
Scrolling can be hard. Here's how to do it.

View File

@@ -1,7 +0,0 @@
\chapter{Working with sizers}\label{chapsizers}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: WORKING WITH SIZERS}}{}{}{}{}{{\it CHAPTER \thechapter: WORKING WITH SIZERS}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
wxSizer and friends.

View File

@@ -1,7 +0,0 @@
\chapter{The wxString class}\label{chapstrings}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: THE wxSTRING CLASS}}{}{}{}{}{{\it CHAPTER \thechapter: THE wxSTRING CLASS}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
A rather important class explained, together with how internationalisation works.

View File

@@ -1,7 +0,0 @@
\chapter{Time, timers and idle processing}\label{chaptime}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: TIME, TIMERS AND IDLE PROCESSING}}{}{}{}{}{{\it CHAPTER \thechapter: TIME, TIMERS AND IDLE PROCESSING}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
Time, timers and idle processing.

View File

@@ -1,7 +0,0 @@
\chapter{Working with toolbars}\label{chaptoolbars}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: WORKING WITH TOOLBARS}}{}{}{}{}{{\it CHAPTER \thechapter: WORKING WITH TOOLBARS}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
Working with toolbars.

View File

@@ -1,7 +0,0 @@
\chapter{wxBase: wxWindows without the GUI}\label{chapwxbase}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: wxBASE: wxWINDOWS WITHOUT THE GUI}}{}{}{}{}{{\it CHAPTER \thechapter: wxBASE: wxWINDOWS WITHOUT THE GUI}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
All about wxBase.

View File

@@ -1,7 +0,0 @@
\chapter{Working with the HTML classes}\label{chapwxhtml}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: WORKING WITH THE HTML CLASSES}}{}{}{}{}{{\it CHAPTER \thechapter: WORKING WITH THE HTML CLASSES}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
The coolness of wxHTML.

View File

@@ -1,7 +0,0 @@
\chapter{An introduction to wxPython}\label{chapwxpython}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: AN INTRODUCTION TO wxPYTHON}}{}{}{}{}{{\it CHAPTER \thechapter: AN INTRODUCTION TO wxPYTHON}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%
wxPython.

Binary file not shown.

Before

Width:  |  Height:  |  Size: 996 B

Binary file not shown.

Before

Width:  |  Height:  |  Size: 959 B

View File

@@ -1,117 +0,0 @@
# File: makefile.vc
# Author: Julian Smart
# Created: 2000
# Updated:
# Copyright: (c) 2000, Julian Smart
#
# "%W% %G%"
#
# Makefile : Builds wxWindows book
THISDIR=$(WXWIN)\src\msw
# WXDIR=$(WXWIN)
WXDIR=$(WXWIN)
DOCDIR = $(WXDIR)\docs
WAITFLAG=/wait
# Making documents
docs: bookhlp bookhtml bookpdfrtf htb htmlhelp
alldocs: docs
hlp: bookhlp
bookhlp: $(DOCDIR)/winhelp/book.hlp
rtf: $(DOCDIR)/winhelp/book.rtf
pdfrtf: $(DOCDIR)/pdf/book.rtf
html: bookhtml
htb: $(DOCDIR)\htb\book.htb
bookhtml: $(DOCDIR)\html\book\book.htm
htmlhelp: $(DOCDIR)\htmlhelp\book.chm
bookps: $(WXDIR)\docs\ps\book.ps
$(DOCDIR)/winhelp/book.hlp: $(DOCDIR)/latex/book/book.rtf $(DOCDIR)/latex/book/book.hpj
cd $(DOCDIR)/latex/book
-erase book.ph
hc book
move book.hlp $(DOCDIR)\winhelp\book.hlp
move book.cnt $(DOCDIR)\winhelp\book.cnt
cd $(THISDIR)
$(DOCDIR)/latex/book/book.rtf: $(DOCDIR)/latex/book/book.tex
cd $(DOCDIR)\latex\book
-start $(WAITFLAG) tex2rtf $(DOCDIR)/latex/book/book.tex $(DOCDIR)/latex/book/book.rtf -twice -winhelp
cd $(THISDIR)
$(DOCDIR)/pdf/book.rtf: $(DOCDIR)/latex/book/book.tex
cd $(DOCDIR)\latex\book
-copy *.wmf $(DOCDIR)\pdf
-copy *.bmp $(DOCDIR)\pdf
-start $(WAITFLAG) tex2rtf $(DOCDIR)/latex/book/book.tex $(DOCDIR)/pdf/book.rtf -twice -rtf
cd $(THISDIR)
$(DOCDIR)\html\book\book.htm: $(DOCDIR)\latex\book\book.tex
cd $(DOCDIR)\latex\book
-mkdir $(DOCDIR)\html\book
copy *.gif $(DOCDIR)\html\book
-start $(WAITFLAG) tex2rtf $(DOCDIR)\latex\book\book.tex $(DOCDIR)\html\book\book.htm -twice -html
-erase $(DOCDIR)\html\book\*.con
-erase $(DOCDIR)\html\book\*.ref
-erase $(DOCDIR)\latex\book\*.con
-erase $(DOCDIR)\latex\book\*.ref
cd $(THISDIR)
$(DOCDIR)\htmlhelp\book.chm : $(DOCDIR)\html\book\book.htm $(DOCDIR)\html\book\book.hhp
cd $(DOCDIR)\html\book
-hhc book.hhp
-mkdir ..\..\htmlhelp
-erase ..\..\htmlhelp\book.chm
move book.chm ..\..\htmlhelp
cd $(THISDIR)
$(WXDIR)\docs\latex\book\book.dvi: $(DOCDIR)/latex/book/body.tex $(DOCDIR)/latex/book/book.tex
cd $(WXDIR)\docs\latex\book
-latex book
-latex book
-makeindx book
-bibtex book
-latex book
-latex book
cd $(THISDIR)
$(WXDIR)\docs\ps\book.ps: $(WXDIR)\docs\latex\book\book.dvi
cd $(WXDIR)\docs\latex\book
-dvips32 -o book.ps book
move book.ps $(WXDIR)\docs\ps\book.ps
cd $(THISDIR)
# An htb file is a zip file containing the .htm, .gif, .hhp, .hhc and .hhk
# files, renamed to htb.
# This can then be used with e.g. helpview.
# Optionally, a cached version of the .hhp file can be generated with hhp2cached.
$(DOCDIR)\htb\book.htb: $(DOCDIR)\html\book\book.htm
cd $(WXDIR)\docs\html\book
-erase book.zip book.htb
zip book.zip *.htm *.gif *.hhp *.hhc *.hhk
-mkdir $(DOCDIR)\htb
move book.zip $(DOCDIR)\htb\book.htb
cd $(THISDIR)
# In order to force document reprocessing
touchbook:
-touch $(WXDIR)\docs\latex\book\book.tex
updatedocs: touchbook alldocs
cleandocs:
-erase $(DOCDIR)\html\book\*.htm
-erase $(DOCDIR)\pdf\book.rtf
-erase $(DOCDIR)\latex\book\book.rtf
-erase $(DOCDIR)\htmlhelp\book.chm
-erase $(DOCDIR)\htb\book.htb
# Start Word, running the GeneratePDF macro. MakeManual.dot should be in the
# Office StartUp folder, and PDFMaker should be installed.
updatepdf: # touchbook pdfrtf
start $(WAITFLAG) "winword d:\book2\bookWindows\docs\latex\pdf\book.rtf /mGeneratePDF"

View File

@@ -1,520 +0,0 @@
%
% %%%%%%% %%%%% %%%%%% %%%%% % %
% % % % % % % % % %
% % % % % % % % % %
% %%%%%%% %%%%% %%%%%% % % %
% % % % % % % % %
% % % % % % % % %
% % %%%%%% %%%%%% %%%%% % %
%
% By Jean Orloff
% Comments & suggestions by e-mail: ORLOFF@surya11.cern.ch
% No modification of this file allowed if not e-sent to me.
%
% A simple way to measure the size of encapsulated postscript figures
% from inside TeX, and to use it for automatically formatting texts
% with inserted figures. Works both under Plain TeX-based macros
% (Phyzzx, Harvmac, Psizzl, ...) and LaTeX environment.
% Provides exactly the same result on any PostScript printer provided
% the single instruction \psfor... is changed to fit the needs of the
% particular dvi->ps translator used.
% History:
% 1.31: adds \psforDVIALW(?)
% 1.30: adds \splitfile & \joinfiles for multi-file management
% 1.24: fix error handling & add \psonlyboxes
% 1.23: adds \putsp@ce for OzTeX fix
% 1.22: makes \drawingBox \global for use in Phyzzx
% 1.21: accepts %%BoundingBox: (atend)
% 1.20: tries to add \psfordvitps for the TeXPS package.
% 1.10: adds \psforoztex, error handling...
%2345678 1 2345678 2 2345678 3 2345678 4 2345678 5 2345678 6 2345678 7 23456789
%
\def\temp{1.31}
\let\tempp=\relax
\expandafter\ifx\csname psboxversion\endcsname\relax
\message{version: \temp}
\else
\ifdim\temp cm>\psboxversion cm
\message{version: \temp}
\else
\message{psbox(\psboxversion) is already loaded: I won't load
psbox(\temp)!}
\let\temp=\psboxversion
\let\tempp=\endinput
\fi
\fi
\tempp
\let\psboxversion=\temp
\catcode`\@=11
% Every macro likes a little privacy...
%
% Some common defs
%
\def\execute#1{#1}% NOT stupid: cs in #1 are then identified BEFORE execution
\def\psm@keother#1{\catcode`#112\relax}% borrowed from latex
\def\executeinspecs#1{%
\execute{\begingroup\let\do\psm@keother\dospecials\catcode`\^^M=9#1\endgroup}}
%
%Trying to tame the variety of \special commands for Postscript: the
% universal internal command \PSspeci@l##1##2 takes ##1 to be the
% filename and ##2 to be the integer scale factor*1000 (as for usual
% TeX \scale commands)
%
\def\psfortextures{% For TeXtures on the Macintosh
%-----------------
\def\PSspeci@l##1##2{%
\special{illustration ##1\space scaled ##2}%
}}
%
\def\psfordvitops{% For the DVItoPS converter on IBM mainframes
%----------------
\def\PSspeci@l##1##2{%
\special{dvitops: import ##1\space \the\drawingwd \the\drawinght}%
}}
%
\def\psfordvips{% For DVIPS converter on VAX, UNIX and PC's
%--------------
\def\PSspeci@l##1##2{%
% \special{/@scaleunit 1000 def}% never read dox without trying!
\d@my=0.1bp \d@mx=\drawingwd \divide\d@mx by\d@my%
\special{PSfile=##1\space llx=\psllx\space lly=\pslly\space%
urx=\psurx\space ury=\psury\space rwi=\number\d@mx}%
}}
%
\def\psforoztex{% For the OzTeX shareware on the Macintosh
%--------------
\def\PSspeci@l##1##2{%
\special{##1 \space
##2 1000 div dup scale
\putsp@ce{\number-\psllx} \putsp@ce{\number-\pslly} translate
}%
}}
\def\putsp@ce#1{#1 }
%
\def\psfordvitps{% From the UNIX TeXPS package, vers.>3.12
%---------------
% Convert a dimension into the number \psn@sp (in scaled points)
\def\psdimt@n@sp##1{\d@mx=##1\relax\edef\psn@sp{\number\d@mx}}
\def\PSspeci@l##1##2{%
% psfig.psr contains the def of "startTexFig": if you can locate it
% and include the correct pathname, it should work
\special{dvitps: Include0 "psfig.psr"}% contains def of "startTexFig"
\psdimt@n@sp{\drawingwd}
\special{dvitps: Literal "\psn@sp\space"}
\psdimt@n@sp{\drawinght}
\special{dvitps: Literal "\psn@sp\space"}
\psdimt@n@sp{\psllx bp}
\special{dvitps: Literal "\psn@sp\space"}
\psdimt@n@sp{\pslly bp}
\special{dvitps: Literal "\psn@sp\space"}
\psdimt@n@sp{\psurx bp}
\special{dvitps: Literal "\psn@sp\space"}
\psdimt@n@sp{\psury bp}
\special{dvitps: Literal "\psn@sp\space startTexFig\space"}
\special{dvitps: Include1 "##1"}
\special{dvitps: Literal "endTexFig\space"}
}}
\def\psforDVIALW{% Try for dvialw, a UNIX public domain
%---------------
\def\PSspeci@l##1##2{
\special{language "PS"
literal "##2 1000 div dup scale"
include "##1"}}}
\def\psonlyboxes{% Draft-like behaviour if none of the others works
%---------------
\def\PSspeci@l##1##2{%
\at(0cm;0cm){\boxit{\vbox to\drawinght
{\vss
\hbox to\drawingwd{\at(0cm;0cm){\hbox{(##1)}}\hss}
}}}
}%
}
%
\def\psloc@lerr#1{%
\let\savedPSspeci@l=\PSspeci@l%
\def\PSspeci@l##1##2{%
\at(0cm;0cm){\boxit{\vbox to\drawinght
{\vss
\hbox to\drawingwd{\at(0cm;0cm){\hbox{(##1) #1}}\hss}
}}}
\let\PSspeci@l=\savedPSspeci@l% restore normal output for other figs!
}%
}
%
%\def\psfor... add your own!
%
% \ReadPSize{PSfilename} reads the dimensions of a PostScript drawing
% and stores it in \drawinght(wd)
\newread\pst@mpin
\newdimen\drawinght\newdimen\drawingwd
\newdimen\psxoffset\newdimen\psyoffset
\newbox\drawingBox
\newif\ifNotB@undingBox
\newhelp\PShelp{Proceed: you will have a 5cm square blank box instead of
your graphics (Jean Orloff).}
\def\@mpty{}
\def\s@tsize#1 #2 #3 #4\@ndsize{
\def\psllx{#1}\def\pslly{#2}%
\def\psurx{#3}\def\psury{#4}% needed by a crazyness of dvips!
\ifx\psurx\@mpty\NotB@undingBoxtrue% this is not a valid one!
\else
\drawinght=#4bp\advance\drawinght by-#2bp
\drawingwd=#3bp\advance\drawingwd by-#1bp
% !Units related by crazy factors as bp/pt=72.27/72 should be BANNED!
\fi
}
\def\sc@nline#1:#2\@ndline{\edef\p@rameter{#1}\edef\v@lue{#2}}
\def\g@bblefirstblank#1#2:{\ifx#1 \else#1\fi#2}
\def\psm@keother#1{\catcode`#112\relax}% borrowed from latex
\def\execute#1{#1}% Seems stupid, but cs are identified BEFORE execution
{\catcode`\%=12
\xdef\B@undingBox{%%BoundingBox}
} %% is not a true comment in PostScript, even if % is!
\def\ReadPSize#1{
\edef\PSfilename{#1}
\openin\pst@mpin=#1\relax
\ifeof\pst@mpin \errhelp=\PShelp
\errmessage{I haven't found your postscript file (\PSfilename)}
\psloc@lerr{was not found}
\s@tsize 0 0 142 142\@ndsize
\closein\pst@mpin
\else
\immediate\write\psbj@inaux{#1,}
\loop
\executeinspecs{\catcode`\ =10\global\read\pst@mpin to\n@xtline}
\ifeof\pst@mpin
\errhelp=\PShelp
\errmessage{(\PSfilename) is not an Encapsulated PostScript File:
I could not find any \B@undingBox: line.}
\edef\v@lue{0 0 142 142:}
\psloc@lerr{is not an EPSFile}
\NotB@undingBoxfalse
\else
\expandafter\sc@nline\n@xtline:\@ndline
\ifx\p@rameter\B@undingBox\NotB@undingBoxfalse
\edef\t@mp{%
\expandafter\g@bblefirstblank\v@lue\space\space\space}
\expandafter\s@tsize\t@mp\@ndsize
\else\NotB@undingBoxtrue
\fi
\fi
\ifNotB@undingBox\repeat
\closein\pst@mpin
\fi
\message{#1}
}
%
% \psboxto(xdim;ydim){psfilename}: you specify the dimensions and
% TeX uniformly scales to fit the largest one. If xdim=0pt, the
% scale is fully determined by ydim and vice versa.
% Notice: psboxes are a real vboxes; couldn't take hbox otherwise all
% indentation and all cr's would be interpreted as spaces (hugh!).
%
\newcount\xscale \newcount\yscale \newdimen\pscm\pscm=1cm
\newdimen\d@mx \newdimen\d@my
\let\ps@nnotation=\relax
\def\psboxto(#1;#2)#3{\vbox{
\ReadPSize{#3}
\divide\drawingwd by 1000
\divide\drawinght by 1000
\d@mx=#1
\ifdim\d@mx=0pt\xscale=1000
\else \xscale=\d@mx \divide \xscale by \drawingwd\fi
\d@my=#2
\ifdim\d@my=0pt\yscale=1000
\else \yscale=\d@my \divide \yscale by \drawinght\fi
\ifnum\yscale=1000
\else\ifnum\xscale=1000\xscale=\yscale
\else\ifnum\yscale<\xscale\xscale=\yscale\fi
\fi
\fi
\divide \psxoffset by 1000\multiply\psxoffset by \xscale
\divide \psyoffset by 1000\multiply\psyoffset by \xscale
\global\divide\pscm by 1000
\global\multiply\pscm by\xscale
\multiply\drawingwd by\xscale \multiply\drawinght by\xscale
\ifdim\d@mx=0pt\d@mx=\drawingwd\fi
\ifdim\d@my=0pt\d@my=\drawinght\fi
\message{scaled \the\xscale}
\hbox to\d@mx{\hss\vbox to\d@my{\vss
\global\setbox\drawingBox=\hbox to 0pt{\kern\psxoffset\vbox to 0pt{
\kern-\psyoffset
\PSspeci@l{\PSfilename}{\the\xscale}
\vss}\hss\ps@nnotation}
\global\ht\drawingBox=\the\drawinght
\global\wd\drawingBox=\the\drawingwd
\baselineskip=0pt
\copy\drawingBox
\vss}\hss}
\global\psxoffset=0pt
\global\psyoffset=0pt% These are local to one figure
\global\pscm=1cm
\global\drawingwd=\drawingwd
\global\drawinght=\drawinght
}}
%
% \psboxscaled{scalefactor*1000}{PSfilename} allows to bypass the
% rounding errors of TeX integer divisions for situations where the
% TeX box should fit the original BoundingBox with a precision better
% than 1/1000.
%
\def\psboxscaled#1#2{\vbox{
\ReadPSize{#2}
\xscale=#1
\message{scaled \the\xscale}
\divide\drawingwd by 1000\multiply\drawingwd by\xscale
\divide\drawinght by 1000\multiply\drawinght by\xscale
\divide \psxoffset by 1000\multiply\psxoffset by \xscale
\divide \psyoffset by 1000\multiply\psyoffset by \xscale
\global\divide\pscm by 1000
\global\multiply\pscm by\xscale
\global\setbox\drawingBox=\hbox to 0pt{\kern\psxoffset\vbox to 0pt{
\kern-\psyoffset
\PSspeci@l{\PSfilename}{\the\xscale}
\vss}\hss\ps@nnotation}
\global\ht\drawingBox=\the\drawinght
\global\wd\drawingBox=\the\drawingwd
\baselineskip=0pt
\copy\drawingBox
\global\psxoffset=0pt
\global\psyoffset=0pt% These are local to one figure
\global\pscm=1cm
\global\drawingwd=\drawingwd
\global\drawinght=\drawinght
}}
%
% \psbox{PSfilename} makes a TeX box having the minimal size to
% enclose the picture
\def\psbox#1{\psboxscaled{1000}{#1}}
%
%
% \joinfiles file1, file2, ...n \into joinedfilename .
% makes one file out of many
% \splitfile joinedfilename
% the opposite
%
%\def\execute#1{#1}% NOT stupid: cs in #1 are then identified BEFORE execution
%\def\psm@keother#1{\catcode`#112\relax}% borrowed from latex
%\def\executeinspecs#1{%
%\execute{\begingroup\let\do\psm@keother\dospecials\catcode`\^^M=9#1\endgroup}}
%\newread\pst@mpin
\newif\ifn@teof\n@teoftrue
\newif\ifc@ntrolline
\newif\ifmatch
\newread\j@insplitin
\newwrite\j@insplitout
\newwrite\psbj@inaux
\immediate\openout\psbj@inaux=psbjoin.aux
\immediate\write\psbj@inaux{\string\joinfiles}
\immediate\write\psbj@inaux{\jobname,}
%
% We redefine input to keep track of the various files inputted
%
\immediate\let\oldinput=\input
\def\input#1 {
\immediate\write\psbj@inaux{#1,}
\oldinput #1 }
\def\empty{}
\def\setmatchif#1\contains#2{
\def\match##1#2##2\endmatch{
\def\tmp{##2}
\ifx\empty\tmp
\matchfalse
\else
\matchtrue
\fi}
\match#1#2\endmatch}
\def\warnopenout#1#2{
\setmatchif{TrashMe,psbjoin.aux,psbjoin.all}\contains{#2}
\ifmatch
\else
\immediate\openin\pst@mpin=#2
\ifeof\pst@mpin
\else
\errhelp{If the content of this file is so precious to you, abort (ie
press x or e) and rename it before retrying.}
\errmessage{I'm just about to replace your file named #2}
\fi
\immediate\closein\pst@mpin
\fi
\message{#2}
\immediate\openout#1=#2}
% No comments allowed below: % will have an unusual catcode
{
\catcode`\%=12
\gdef\splitfile#1 {
\immediate\openin\j@insplitin=#1
\message{Splitting file #1 into:}
\warnopenout\j@insplitout{TrashMe}
\loop
\ifeof
\j@insplitin\immediate\closein\j@insplitin\n@teoffalse
\else
\n@teoftrue
\executeinspecs{\global\read\j@insplitin to\spl@tinline\expandafter
\ch@ckbeginnewfile\spl@tinline%Beginning-Of-File-Named:%\endcheck}
\ifc@ntrolline
\else
\toks0=\expandafter{\spl@tinline}
\immediate\write\j@insplitout{\the\toks0}
\fi
\fi
\ifn@teof\repeat
\immediate\closeout\j@insplitout}
\gdef\ch@ckbeginnewfile#1%Beginning-Of-File-Named:#2%#3\endcheck{
\def\t@mp{#1}
\ifx\empty\t@mp
\def\t@mp{#3}
\ifx\empty\t@mp
\global\c@ntrollinefalse
\else
\immediate\closeout\j@insplitout
\warnopenout\j@insplitout{#2}
\global\c@ntrollinetrue
\fi
\else
\global\c@ntrollinefalse
\fi}
\gdef\joinfiles#1\into#2 {
\message{Joining following files into}
\warnopenout\j@insplitout{#2}
\message{:}
{
\edef\w@##1{\immediate\write\j@insplitout{##1}}
\w@{% This text was produced with psbox's \string\joinfiles.}
\w@{% To decompose and tex it:}
\w@{%-save this with a filename CONTAINING ONLY LETTERS, and no extensions}
\w@{% (say, JOINTFIL), in some uncrowded directory;}
\w@{%-make sure you can \string\input\space psbox.tex (version>=1.3);}
\w@{%-tex JOINTFIL using Plain, or LaTeX, or whatever is needed by}
\w@{% the first part in the joining (after splitting JOINTFIL into}
\w@{% it is constituents, TeX will try to process it as it stands).}
\w@{\string\input\space psbox.tex}
\w@{\string\splitfile{\string\jobname}}
}
\tre@tfilelist#1, \endtre@t
\immediate\closeout\j@insplitout}
\gdef\tre@tfilelist#1, #2\endtre@t{
\def\t@mp{#1}
\ifx\empty\t@mp
\else
\llj@in{#1}
\tre@tfilelist#2, \endtre@t
\fi}
\gdef\llj@in#1{
\immediate\openin\j@insplitin=#1
\ifeof\j@insplitin
\errmessage{I couldn't find file #1.}
\else
\message{#1}
\toks0={%Beginning-Of-File-Named:#1}
\immediate\write\j@insplitout{\the\toks0}
\executeinspecs{\global\read\j@insplitin to\oldj@ininline}
\loop
\ifeof\j@insplitin\immediate\closein\j@insplitin\n@teoffalse
\else\n@teoftrue
\executeinspecs{\global\read\j@insplitin to\j@ininline}
\toks0=\expandafter{\oldj@ininline}
\let\oldj@ininline=\j@ininline
\immediate\write\j@insplitout{\the\toks0}
\fi
\ifn@teof
\repeat
\immediate\closein\j@insplitin
\fi}
}
% To be put at the end of a file, for making an tar-like file containing
% everything it used.
\def\autojoin{
\immediate\write\psbj@inaux{\string\into\space psbjoin.all}
\immediate\closeout\psbj@inaux
\input psbjoin.aux
}
%
% Annotations & Captions etc...
%
%
% \centinsert{anybox} is just a centered \midinsert, but is included as
% people barely use the original inserts from TeX.
%
\def\centinsert#1{\midinsert\line{\hss#1\hss}\endinsert}
\def\psannotate#1#2{\def\ps@nnotation{#2\global\let\ps@nnotation=\relax}#1}
\def\pscaption#1#2{\vbox{
\setbox\drawingBox=#1
\copy\drawingBox
\vskip\baselineskip
\vbox{\hsize=\wd\drawingBox\setbox0=\hbox{#2}
\ifdim\wd0>\hsize
\noindent\unhbox0\tolerance=5000
\else\centerline{\box0}
\fi
}}}
% for compatibility with older versions
\def\psfig#1#2#3{\pscaption{\psannotate{#1}{#2}}{#3}}
\def\psfigurebox#1#2#3{\pscaption{\psannotate{\psbox{#1}}{#2}}{#3}}
%
% \at(#1;#2)#3 puts #3 at #1-higher and #2-right of the current
% position without moving it (to be used in annotations).
\def\at(#1;#2)#3{\setbox0=\hbox{#3}\ht0=0pt\dp0=0pt
\rlap{\kern#1\vbox to0pt{\kern-#2\box0\vss}}}
%
% \gridfill(ht;wd) makes a 1cm*1cm grid of ht by wd whose lower-left
% corner is the current point
\newdimen\gridht \newdimen\gridwd
\def\gridfill(#1;#2){
\setbox0=\hbox to 1\pscm
{\vrule height1\pscm width.4pt\leaders\hrule\hfill}
\gridht=#1
\divide\gridht by \ht0
\multiply\gridht by \ht0
\gridwd=#2
\divide\gridwd by \wd0
\multiply\gridwd by \wd0
\advance \gridwd by \wd0
\vbox to \gridht{\leaders\hbox to\gridwd{\leaders\box0\hfill}\vfill}}
%
% Useful to measure where to put annotations
\def\fillinggrid{\at(0cm;0cm){\vbox{
\gridfill(\drawinght;\drawingwd)}}}
%
% \textleftof\anybox: Sample text\endtext
% inserts "Sample text" on the left of \anybox ie \vbox, \psbox.
% \textrightof is the symmetric (not documented, too ugly)
% Welcome any suggestion about clean wraparound macros from
% TeXhackers reading this
%
\def\textleftof#1:{
\setbox1=#1
\setbox0=\vbox\bgroup
\advance\hsize by -\wd1 \advance\hsize by -2em}
\def\textrightof#1:{
\setbox0=#1
\setbox1=\vbox\bgroup
\advance\hsize by -\wd0 \advance\hsize by -2em}
\def\endtext{
\egroup
\hbox to \hsize{\valign{\vfil##\vfil\cr%
\box0\cr%
\noalign{\hss}\box1\cr}}}
%
% \frameit{\thick}{\skip}{\anybox}
% draws with thickness \thick a box around \anybox, leaving \skip of
% blank around it. eg \frameit{0.5pt}{1pt}{\hbox{hello}}
% \boxit{\anybox} is a shortcut.
\def\frameit#1#2#3{\hbox{\vrule width#1\vbox{
\hrule height#1\vskip#2\hbox{\hskip#2\vbox{#3}\hskip#2}%
\vskip#2\hrule height#1}\vrule width#1}}
\def\boxit#1{\frameit{0.4pt}{0pt}{#1}}
%
%
\catcode`\@=12 % cs containing @ are unreachable
%
% CUSTOMIZE YOUR DEFAULT DRIVER:
% Uncomment the line corresponding to your TeX system:
%\psfortextures% For TeXtures on the Macintosh
%\psforoztex % For OzTeX shareware on the Macintosh
%\psfordvitops % For the DVItoPS converter for TeX on IBM mainframes
\psfordvips % For DVIPS converter on VAX and UNIX
%\psfordvitps % For dvitps from TeXPS package under UNIX
%\psforDVIALW % For DVIALW, UNIX public domain
%\psonlyboxes % Blank Boxes (when all else fails).

View File

@@ -1,59 +0,0 @@
@techreport{robins87,
author = {Robins, Gabriel},
title = {The {ISI} grapher: a portable tool for displaying graphs pictorially (ISI/RS-87-196)},
institution = {University of South California},
year = {1987},
month = {September}
}
@book{helpbook,
author = {Boggan, Scott and Fakas, David and Welinske, Joe}
, title = {Developing on-line help for {W}indows}
, publisher = {Sams Publishing}
, address = {11711 North College, Carmel, Indiana 46032, USA}
, year = {1993}
}
@book{wong93,
author = {Wong, William}
, title = {Plug and play programming}
, publisher = {M and T Books}
, address = {115 West 18th Street, New York, New York 10011}
, year = {1993}
}
@book{pree94,
author = {Pree, Wolfgang}
, title = {Design patterns for object-oriented software development}
, publisher = {Addison-Wesley}
, address = {Reading, MA}
, year = {1994}
}
@book{gamma95,
author = {Gamma, Erich and Helm, Richard and Johnson, Ralph and Vlissides, John}
, title = {Design patterns: elements of reusable object-oriented software}
, publisher = {Addison-Wesley}
, address = {Reading, MA}
, year = {1994}
}
@book{kopka,
author = {Kopka, Helmut and Daly, Patrick W.}
, title = {A Guide to LaTeX}
, publisher = {Addison-Wesley}
, year = {1993}
}
@manual{smart95a,
author = {Smart, Julian}
, title = {wxCLIPS User Manual}
, publisher = {Artificial Intelligence Applications Institute}
, organization = {University of Edinburgh}
, address = {80 South Bridge, Edinburgh, EH1 1HN}
, year = {1995}
}
@manual{smart95b,
author = {Smart, Julian}
, title = {Tex2RTF User Manual}
, publisher = {Artificial Intelligence Applications Institute}
, organization = {University of Edinburgh}
, address = {80 South Bridge, Edinburgh, EH1 1HN}
, year = {1995}
}

View File

@@ -1,6 +0,0 @@
\chapter{My Chapter}\label{mychapter}
\pagenumbering{arabic}%
\setheader{{\it CHAPTER \thechapter: My Chapter}}{}{}{}{}{{\it CHAPTER \thechapter: My Chapter}}%
\setfooter{\thepage}{}{}{}{}{\thepage}%

View File

@@ -1,44 +0,0 @@
; Last change: JAC 23 Nov 100 8:27 pm
;;; Tex2RTF initialisation file
runTwice = yes
titleFontSize = 12
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 = "Multiplatform application development with wxWindows"
truncateFilenames = no
combineSubSections = yes
;;
;; These two are for generating MS HTML Help project, contents and index files.
;;
htmlWorkshopFiles = true
htmlIndex = true
;\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}}
\overview [2] {\helpref{#1}{#2}}
\docparam [2]{\parskip{0}{\it #1}\htmlignore{\par}\parskip{10}\indented{1cm}{#2}}
\wxheading [1]{{\bf \htmlignore{\fcol{blue}{#1}}\htmlonly{\fcol{red}{#1}}}}
\const [0] {{\bf const}}
\constfunc [3] {{\bf #1} {\bf #2}(#3) {\bf const}\index{#2}}
\windowstyle [1] {{\bf #1}\index{#1}}
\bftt [1] {\bf{\tt{#1}}}
\pythonnote [1] {{\bf \fcol{blue}{wxPython note:}} #1}
%\pythonnote [1] {}
% Use this if not including the class reference in the book
\wxhelpref [2] {#1}
% Use this if including the class reference in the book
%\wxhelpref [2] {\helpref{#1}{#2}}

View File

@@ -1,301 +0,0 @@
% 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}}
%\newcommand{\docparam}[2]{\parskip=0pt {\it #1}\par\parskip=10pt\begin{indented}{1cm}{#2}\end{indented}}
% Void type
\newcommand{\void}{{\it void}}
% Typeset destructor
\newcommand{\destruct}[1]{{$\sim$}#1}
% Typeset insert/extract operators
\newcommand{\cinsert}{$<<$}
\newcommand{\cextract}{$>>$}
% pythonnote: A note about the wxpython interface.
%\newcommand{\pythonnote}[1]{{\bf wxPython note: }#1}
\newcommand{\pythonnote}[1]{{}}
% =================== 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}}
\newcommand{\windowstyle}[1]{{\bf #1}\index{#1}}
\addtolength{\textwidth}{1in}
\addtolength{\oddsidemargin}{-0.5in}
\addtolength{\topmargin}{-0.5in}
\addtolength{\textheight}{1in}
\sloppy

Binary file not shown.

Before

Width:  |  Height:  |  Size: 998 B