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:
Binary file not shown.
Before Width: | Height: | Size: 978 B |
@@ -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}
|
@@ -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.)
|
||||
|
@@ -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}
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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}
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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...
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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}
|
||||
|
||||
|
@@ -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.
|
||||
|
@@ -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?
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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!
|
||||
|
@@ -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.
|
||||
|
@@ -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, ...
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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, ...
|
||||
|
@@ -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.
|
||||
|
@@ -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}
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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.
|
||||
|
@@ -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 |
@@ -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"
|
||||
|
||||
|
@@ -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).
|
@@ -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}
|
||||
}
|
||||
|
@@ -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}%
|
||||
|
||||
|
@@ -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}}
|
||||
|
@@ -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 |
Reference in New Issue
Block a user