Fixed typos in the docs
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_2_2_BRANCH@6892 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
@@ -86,7 +86,7 @@ in Windows Help, HTML and Word RTF formats.
|
||||
\item Simple-to-use, object-oriented API.
|
||||
\item Flexible event system.
|
||||
\item Graphics calls include lines, rounded rectangles, splines, polylines, etc.
|
||||
\item Constraint-based and sizer-based layouting.
|
||||
\item Constraint-based and sizer-based layouts.
|
||||
\item Print/preview and document/view architectures.
|
||||
\item Toolbar, notebook, tree control, advanced list control classes.
|
||||
\item PostScript generation under Unix, normal MS Windows printing on the PC.
|
||||
@@ -99,7 +99,7 @@ them to the clipboard.
|
||||
\item Ready-to-use HTML window (supporting a subset of HTML).
|
||||
\item Dialog Editor for building dialogs.
|
||||
\item Network support via a family of socket and protocol classes.
|
||||
\item Support for platform independent image procesing.
|
||||
\item Support for platform independent image processing.
|
||||
\item Built-in support for many file formats (BMP, PNG, JPEG, GIF, XPM, PNM, PCX).
|
||||
\end{itemize}
|
||||
|
||||
@@ -123,7 +123,7 @@ Additions and changes:
|
||||
|
||||
\begin{itemize}\itemsep=0pt
|
||||
\item class hierarchy changed, and restrictions about subwindow nesting lifted;
|
||||
\item header files reorganised to conform to normal C++ standards;
|
||||
\item header files reorganized to conform to normal C++ standards;
|
||||
\item classes less dependent on each another, to reduce executable size;
|
||||
\item wxString used instead of char* wherever possible;
|
||||
\item the number of separate but mandatory utilities reduced;
|
||||
@@ -449,7 +449,7 @@ fine on some platforms, and then fail under Windows.
|
||||
\section{Architecture dependency}
|
||||
|
||||
A problem which sometimes arises from writing multi-platform programs is that
|
||||
the basic C types are not defiend the same on all platforms. This holds true
|
||||
the basic C types are not defined the same on all platforms. This holds true
|
||||
for both the length in bits of the standard types (such as int and long) as
|
||||
well as their byte order, which might be little endian (typically
|
||||
on Intel computers) or big endian (typically on some Unix workstations). wxWindows
|
||||
@@ -492,7 +492,7 @@ its own run-time type information system, implemented using macros.
|
||||
|
||||
Some compilers (e.g. the native IRIX cc) define NULL to be 0L so that
|
||||
no conversion to pointers is allowed. Because of that, all these
|
||||
occurences of NULL in the GTK port use an explicit conversion such
|
||||
occurrences of NULL in the GTK port use an explicit conversion such
|
||||
as
|
||||
|
||||
{\small
|
||||
@@ -527,7 +527,7 @@ X and Windows parts of the library) conditional
|
||||
compilation that under Unix, includes a minimal set of headers;
|
||||
and when using Visual C++, includes {\tt wx.h}. This should help provide
|
||||
the optimal compilation for each compiler, although it is
|
||||
biassed towards the precompiled headers facility available
|
||||
biased towards the precompiled headers facility available
|
||||
in Microsoft C++.
|
||||
|
||||
\section{File handling}
|
||||
@@ -577,7 +577,7 @@ more easily accessed via the Contributions page on the Web site.
|
||||
wxHelp is a stand-alone program, written using wxWindows,
|
||||
for displaying hypertext help. It is necessary since not all target
|
||||
systems (notably X) supply an adequate
|
||||
standard for on-line help. wxHelp is modelled on the MS Windows help
|
||||
standard for on-line help. wxHelp is modeled on the MS Windows help
|
||||
system, with contents, search and browse buttons, but does not reformat
|
||||
text to suit the size of window, as WinHelp does, and its input files
|
||||
are uncompressed ASCII with some embedded font commands and an .xlp
|
||||
@@ -690,7 +690,7 @@ it can alert you to problems later on.
|
||||
\subsection{Use wxString in preference to character arrays}
|
||||
|
||||
Using wxString can be much safer and more convenient than using char *.
|
||||
Again, I haven't practised what I'm preaching, but I'm now trying to use
|
||||
Again, I haven't practiced what I'm preaching, but I'm now trying to use
|
||||
wxString wherever possible. You can reduce the possibility of memory
|
||||
leaks substantially, and it's much more convenient to use the overloaded
|
||||
operators than functions such as strcmp. wxString won't add a significant
|
||||
|
@@ -35,7 +35,7 @@ wxALIGN\_CENTER\_VERTICAL). Default alignment is wxALIGN\_LEFT | wxALIGN\_TOP.
|
||||
As mentioned above, any window belonging to a sizer may have border, and it can be specified
|
||||
which of the four sides may have this border, using the wxTOP, wxLEFT, wxRIGHT and wxBOTTOM
|
||||
constants or wxALL for all directions (and you may also use wxNORTH, wxWEST etc instead). These
|
||||
flags can be used in combintaion with the alignement flags above as the second paramter of the
|
||||
flags can be used in combination with the alignment flags above as the second parameter of the
|
||||
Add() method using the binary or operator |. The sizer of the border also must be made known,
|
||||
and it is the third parameter in the Add() method. This means, that the entire behaviour of
|
||||
a sizer and its children can be controlled by the three parameters of the Add() method.
|
||||
|
@@ -6,7 +6,7 @@
|
||||
%% Created: 03.01.00
|
||||
%% RCS-ID: $Id$
|
||||
%% Copyright: (c) Vadim Zeitlin
|
||||
%% Licence: wxWindows licence
|
||||
%% License: wxWindows license
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{\class{wxCalendarCtrl}}\label{wxcalendarctrl}
|
||||
|
@@ -81,8 +81,8 @@ that are not static can have \helpref{validators}{wxvalidator} associated with t
|
||||
\twocolitem{\helpref{wxListBox}{wxlistbox}}{A list of strings for single or multiple selection}
|
||||
\twocolitem{\helpref{wxListCtrl}{wxlistctrl}}{A control for displaying lists of strings and/or icons, plus a multicolumn report view}
|
||||
\twocolitem{\helpref{wxTabCtrl}{wxtabctrl}}{Manages several tabs}
|
||||
\twocolitem{\helpref{wxTextCtrl}{wxtextctrl}}{Single or multline text editing control}
|
||||
\twocolitem{\helpref{wxTreeCtrl}{wxtreectrl}}{Tree (hierachy) control}
|
||||
\twocolitem{\helpref{wxTextCtrl}{wxtextctrl}}{Single or multiline text editing control}
|
||||
\twocolitem{\helpref{wxTreeCtrl}{wxtreectrl}}{Tree (hierarchy) control}
|
||||
\twocolitem{\helpref{wxScrollBar}{wxscrollbar}}{Scrollbar control}
|
||||
\twocolitem{\helpref{wxSpinButton}{wxspinbutton}}{A spin or `up-down' control}
|
||||
\twocolitem{\helpref{wxSpinCtrl}{wxspinctrl}}{A spin control - i.e. spin button and text control}
|
||||
@@ -103,7 +103,7 @@ that are not static can have \helpref{validators}{wxvalidator} associated with t
|
||||
|
||||
{\large {\bf Window layout}}
|
||||
|
||||
There are two different systems for layouting windows (and dialogs in particluar).
|
||||
There are two different systems for layouting windows (and dialogs in particular).
|
||||
One is based upon so-called sizers and it requires less typing, thinking and calculating
|
||||
and will in almost all cases produce dialogs looking equally well on all platforms, the
|
||||
other is based on so-called constraints and allows for more detailed layouts.
|
||||
@@ -288,7 +288,7 @@ classes, functions and macros.
|
||||
wxWindows provides its own classes for socket based networking.
|
||||
|
||||
\begin{twocollist}\itemsep=0pt
|
||||
\twocolitem{\helpref{wxIPV4address}{wxipv4address}}{Represents an Internet adress}
|
||||
\twocolitem{\helpref{wxIPV4address}{wxipv4address}}{Represents an Internet address}
|
||||
\twocolitem{\helpref{wxSocketBase}{wxsocketbase}}{Represents a socket base object}
|
||||
\twocolitem{\helpref{wxSocketClient}{wxsocketclient}}{Represents a socket client}
|
||||
\twocolitem{\helpref{wxSocketServer}{wxsocketserver}}{Represents a socket server}
|
||||
@@ -326,7 +326,7 @@ housekeeping for a document-centric application.
|
||||
\begin{twocollist}\itemsep=0pt
|
||||
\twocolitem{\helpref{wxDocument}{wxdocument}}{Represents a document}
|
||||
\twocolitem{\helpref{wxView}{wxview}}{Represents a view}
|
||||
\twocolitem{\helpref{wxDocTemplate}{wxdoctemplate}}{Manages the relationship between a document class and a veiw class}
|
||||
\twocolitem{\helpref{wxDocTemplate}{wxdoctemplate}}{Manages the relationship between a document class and a view class}
|
||||
\twocolitem{\helpref{wxDocManager}{wxdocmanager}}{Manages the documents and views in an application}
|
||||
\twocolitem{\helpref{wxDocChildFrame}{wxdocchildframe}}{A child frame for showing a document view}
|
||||
\twocolitem{\helpref{wxDocParentFrame}{wxdocparentframe}}{A parent frame to contain views}
|
||||
@@ -339,7 +339,7 @@ housekeeping for a document-centric application.
|
||||
\overview{Overview}{printingoverview}
|
||||
|
||||
A printing and previewing framework is implemented to
|
||||
make it relatively straighforward to provide document printing
|
||||
make it relatively straightforward to provide document printing
|
||||
facilities.
|
||||
|
||||
\begin{twocollist}\itemsep=0pt
|
||||
@@ -432,7 +432,7 @@ capabilities of the various platforms.
|
||||
\twocolitem{\helpref{wxMutex}{wxmutex}}{Mutex class}
|
||||
\twocolitem{\helpref{wxMutexLocker}{wxmutexlocker}}{Mutex locker utility class}
|
||||
\twocolitem{\helpref{wxCriticalSection}{wxcriticalsection}}{Critical section class}
|
||||
\twocolitem{\helpref{wxCriticalSectionLocker}{wxcriticalsectionlocker}}{ritical section locker utility class}
|
||||
\twocolitem{\helpref{wxCriticalSectionLocker}{wxcriticalsectionlocker}}{Critical section locker utility class}
|
||||
\twocolitem{\helpref{wxCondition}{wxcondition}}{Condition class}
|
||||
\end{twocollist}
|
||||
|
||||
|
@@ -31,7 +31,7 @@ class, so there is no need to create such objects explicitly in an application.
|
||||
\func{wxObject*}{CreateObject}{\void}
|
||||
|
||||
Creates an object of the appropriate kind. Returns NULL if the class has not been declared
|
||||
dynamically createable (typically, it's an abstract class).
|
||||
dynamically creatable (typically, it's an abstract class).
|
||||
|
||||
\membersection{wxClassInfo::FindClass}
|
||||
|
||||
|
@@ -45,6 +45,7 @@
|
||||
\input database.tex
|
||||
\input dataform.tex
|
||||
\input dataobj.tex
|
||||
\input db.tex
|
||||
\input dobjcomp.tex
|
||||
\input dobjsmpl.tex
|
||||
\input datstrm.tex
|
||||
@@ -265,6 +266,7 @@
|
||||
\input textdlg.tex
|
||||
\input txtdrptg.tex
|
||||
\input valtext.tex
|
||||
\input table.tex
|
||||
\input textfile.tex
|
||||
\input thread.tex
|
||||
\input time.tex
|
||||
|
@@ -18,6 +18,12 @@ Note: this class is considered obsolete, replaced by the Remstar wxDB/wxTable cl
|
||||
|
||||
\overview{wxDatabase overview}{wxdatabaseoverview}, \helpref{wxRecordSet}{wxrecordset}
|
||||
|
||||
A much more robust and feature-rich set of ODBC classes is now
|
||||
available and recommended for use in place of the wxDatabase class.
|
||||
|
||||
See details of these classes in:
|
||||
\helpref{wxDB}{wxdb}, \helpref{wxTable}{wxtable}
|
||||
|
||||
\latexignore{\rtfignore{\wxheading{Members}}}
|
||||
|
||||
\membersection{wxDatabase::wxDatabase}
|
||||
@@ -74,9 +80,9 @@ and disconnects from the current data source.
|
||||
|
||||
Commits previous transactions. Not implemented.
|
||||
|
||||
\membersection{wxDatabase::ErrorOccured}
|
||||
\membersection{wxDatabase::ErrorOccurred}
|
||||
|
||||
\func{bool}{ErrorOccured}{\void}
|
||||
\func{bool}{ErrorOccurred}{\void}
|
||||
|
||||
Returns TRUE if the last action caused an error.
|
||||
|
||||
@@ -84,7 +90,7 @@ Returns TRUE if the last action caused an error.
|
||||
|
||||
\func{void}{ErrorSnapshot}{\param{HSTMT}{ statement = SQL\_NULL\_HSTMT}}
|
||||
|
||||
This function will be called whenever an ODBC error occured. It stores the
|
||||
This function will be called whenever an ODBC error occurred. It stores the
|
||||
error related information returned by ODBC. If a statement handle of the
|
||||
concerning ODBC action is available it should be passed to the function.
|
||||
|
||||
|
@@ -6,7 +6,7 @@
|
||||
%% Created: 03.11.99
|
||||
%% RCS-ID: $Id$
|
||||
%% Copyright: (c) Vadim Zeitlin
|
||||
%% Licence: wxWindows licence
|
||||
%% License: wxWindows license
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{\class{wxDataFormat}}\label{wxdataformat}
|
||||
|
@@ -6,7 +6,7 @@
|
||||
%% Created: 18.10.99
|
||||
%% RCS-ID: $Id$
|
||||
%% Copyright: (c) wxWindows team
|
||||
%% Licence: wxWindows licence
|
||||
%% License: wxWindows license
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{\class{wxDataObject}}\label{wxdataobject}
|
||||
|
@@ -6,7 +6,7 @@
|
||||
%% Created: 07.03.00
|
||||
%% RCS-ID: $Id$
|
||||
%% Copyright: (c) Vadim Zeitlin
|
||||
%% Licence: wxWindows licence
|
||||
%% License: wxWindows license
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{\class{wxDateTime}}\label{wxdatetime}
|
||||
|
@@ -7,7 +7,7 @@ To create a client which can communicate with a suitable server,
|
||||
you need to derive a class from wxDDEConnection and another from wxDDEClient.
|
||||
The custom wxDDEConnection class will intercept communications in
|
||||
a `conversation' with a server, and the custom wxDDEServer is required
|
||||
so that a user-overriden \helpref{wxDDEClient::OnMakeConnection}{wxddeclientonmakeconnection} member can return
|
||||
so that a user-overridden \helpref{wxDDEClient::OnMakeConnection}{wxddeclientonmakeconnection} member can return
|
||||
a wxDDEConnection of the required class, when a connection is made.
|
||||
|
||||
This DDE-based implementation is
|
||||
|
@@ -94,7 +94,7 @@ class is not meant to be used polymorphically.
|
||||
\func{bool}{Open}{\param{const wxString\& }{dir}}
|
||||
|
||||
Open the directory for enumerating, returns TRUE on success or FALSE if an
|
||||
error occured.
|
||||
error occurred.
|
||||
|
||||
\membersection{wxDir::IsOpened}\label{wxdirisopened}
|
||||
|
||||
|
@@ -6,7 +6,7 @@
|
||||
%% Created: 02.11.99
|
||||
%% RCS-ID: $Id$
|
||||
%% Copyright: (c) Vadim Zeitlin
|
||||
%% Licence: wxWindows licence
|
||||
%% License: wxWindows license
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{\class{wxDataObjectComposite}}\label{wxdataobjectcomposite}
|
||||
|
@@ -6,7 +6,7 @@
|
||||
%% Created: 02.11.99
|
||||
%% RCS-ID: $Id$
|
||||
%% Copyright: (c) Vadim Zeitlin
|
||||
%% Licence: wxWindows licence
|
||||
%% License: wxWindows license
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{\class{wxDataObjectSimple}}\label{wxdataobjectsimple}
|
||||
|
@@ -252,7 +252,7 @@ The actual offset position achieved, or wxInvalidOffset on failure.
|
||||
\constfunc{off\_t}{Tell}{\void}
|
||||
|
||||
Returns the current position or wxInvalidOffset if file is not opened or if another
|
||||
error occured.
|
||||
error occurred.
|
||||
|
||||
\membersection{wxFile::Write}\label{wxfilewrite}
|
||||
|
||||
|
@@ -6,7 +6,7 @@
|
||||
%% Created: 03.11.99
|
||||
%% RCS-ID: $Id$
|
||||
%% Copyright: (c) Vadim Zeitlin
|
||||
%% Licence: wxWindows licence
|
||||
%% License: wxWindows license
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{\class{wxFontEnumerator}}\label{wxfontenumerator}
|
||||
|
@@ -181,7 +181,7 @@ You will be notified when the EOF is reached by an error.
|
||||
|
||||
\wxheading{Return value}
|
||||
|
||||
Returns NULL if an error occured (it could be a network failure or the fact
|
||||
Returns NULL if an error occurred (it could be a network failure or the fact
|
||||
that the file doesn't exist).
|
||||
|
||||
Returns the initialized stream. You will have to delete it yourself when you
|
||||
|
@@ -21,8 +21,8 @@ The functions defined in wxWindows are described here.
|
||||
This function must be called when any thread other than the main GUI thread
|
||||
wants to get access to the GUI library. This function will block the execution
|
||||
of the calling thread until the main thread (or any other thread holding the
|
||||
main GUI lock) leaves the GUI library and no other other thread will enter
|
||||
the GUI library until the calling thread calls \helpref{::wxMutexGuiLeave()}{wxmutexguileave}.
|
||||
main GUI lock) leaves the GUI library and no other thread will enter the GUI
|
||||
library until the calling thread calls \helpref{::wxMutexGuiLeave()}{wxmutexguileave}.
|
||||
|
||||
Typically, these functions are used like this:
|
||||
|
||||
@@ -270,7 +270,7 @@ wxSplitPath() will correctly handle filenames with both DOS and Unix path separa
|
||||
Windows, however it will not consider backslashes as path separators under Unix (where backslash
|
||||
is a valid character in a filename).
|
||||
|
||||
On entry, {\it fullname} should be non NULL (it may be empty though).
|
||||
On entry, {\it fullname} should be non-NULL (it may be empty though).
|
||||
|
||||
On return, {\it path} contains the file path (without the trailing separator), {\it name}
|
||||
contains the file name and {\it ext} contains the file extension without leading dot. All
|
||||
@@ -632,7 +632,7 @@ to be used for entering passwords as the function name implies.
|
||||
\param{const wxString\& }{default\_value = ``"}, \param{wxWindow *}{parent = NULL},\\
|
||||
\param{int}{ x = -1}, \param{int}{ y = -1}, \param{bool}{ centre = TRUE}}
|
||||
|
||||
Pop up a dialog box with title set to {\it caption}, message {\it message}, and a
|
||||
Pop up a dialog box with title set to {\it caption}, {\it message}, and a
|
||||
\rtfsp{\it default\_value}. The user may type in text and press OK to return this text,
|
||||
or press Cancel to return the empty string.
|
||||
|
||||
@@ -1285,7 +1285,7 @@ For asynchronous execution, however, the return value is the process id and
|
||||
zero value indicates that the command could not be executed.
|
||||
|
||||
If callback isn't NULL and if execution is asynchronous (note that callback
|
||||
parameter can not be non NULL for synchronous execution),
|
||||
parameter can not be non-NULL for synchronous execution),
|
||||
\helpref{wxProcess::OnTerminate}{wxprocessonterminate} will be called when
|
||||
the process finishes.
|
||||
|
||||
@@ -1439,7 +1439,7 @@ Returns the mouse position in screen coordinates.
|
||||
\func{wxString}{wxGetOsDescription}{\void}
|
||||
|
||||
Returns the string containing the description of the current platform in a
|
||||
user-readable form. For example, this function may return strings like
|
||||
user-readable form. For example, this function may return strings like
|
||||
{\tt Windows NT Version 4.0} or {\tt Linux 2.2.2 i386}.
|
||||
|
||||
\wxheading{See also}
|
||||
@@ -1457,7 +1457,7 @@ user-readable form. For example, this function may return strings like
|
||||
Gets operating system version information.
|
||||
|
||||
\begin{twocollist}\itemsep=0pt
|
||||
\twocolitemruled{Platform}{Return tyes}
|
||||
\twocolitemruled{Platform}{Return types}
|
||||
\twocolitem{Macintosh}{Return value is wxMACINTOSH.}
|
||||
\twocolitem{GTK}{Return value is wxGTK, For GTK 1.0, {\it major} is 1, {\it minor} is 0. }
|
||||
\twocolitem{Motif}{Return value is wxMOTIF\_X, {\it major} is X version, {\it minor} is X revision.}
|
||||
@@ -1876,7 +1876,7 @@ iteration), call \helpref{wxLog::FlushActive}{wxlogflushactive}.
|
||||
|
||||
This functions wakes up the (internal and platform dependent) idle system, i.e. it
|
||||
will force the system to send an idle event even if the system currently {\it is}
|
||||
idle and thus would not send any idle event until after some other event would get
|
||||
idle and thus would not send any idle event until after some other event would get
|
||||
sent. This is also useful for sending events between two threads and is used by
|
||||
the corresponding functions \helpref{::wxPostEvent}{wxpostevent} and
|
||||
\helpref{wxEvtHandler::AddPendingEvent}{wxevthandleraddpendingevent}.
|
||||
@@ -2008,7 +2008,7 @@ dynamically. The same as DECLARE\_ABSTRACT\_CLASS.
|
||||
\func{}{DECLARE\_DYNAMIC\_CLASS}{className}
|
||||
|
||||
Used inside a class declaration to declare that the objects of this class should be dynamically
|
||||
createable from run-time type information.
|
||||
creatable from run-time type information.
|
||||
|
||||
Example:
|
||||
|
||||
@@ -2185,7 +2185,7 @@ In non-debug mode, this is defined as the normal new operator.
|
||||
|
||||
This macro returns the pointer {\it ptr} cast to the type {\it classname *} if
|
||||
the pointer is of this type (the check is done during the run-time) or NULL
|
||||
otherwise. Usage of this macro is prefered over obsoleted wxObject::IsKindOf()
|
||||
otherwise. Usage of this macro is preferred over obsoleted wxObject::IsKindOf()
|
||||
function.
|
||||
|
||||
The {\it ptr} argument may be NULL, in which case NULL will be returned.
|
||||
@@ -2528,7 +2528,7 @@ Mostly used by wxWindows itself, but might be handy for logging errors after
|
||||
system call (API function) failure. It logs the specified message text as well
|
||||
as the last system error code ({\it errno} or {\it ::GetLastError()} depending
|
||||
on the platform) and the corresponding error message. The second form
|
||||
of this function takes the error code explitly as the first argument.
|
||||
of this function takes the error code explicitly as the first argument.
|
||||
|
||||
\wxheading{See also}
|
||||
|
||||
@@ -2617,7 +2617,7 @@ Returns the error message corresponding to the given system error code. If
|
||||
|
||||
\section{Debugging macros and functions}\label{debugmacros}
|
||||
|
||||
Useful macros and functins for error checking and defensive programming. ASSERTs are only
|
||||
Useful macros and functions for error checking and defensive programming. ASSERTs are only
|
||||
compiled if \_\_WXDEBUG\_\_ is defined, whereas CHECK macros stay in release
|
||||
builds.
|
||||
|
||||
|
@@ -89,7 +89,7 @@ If {\it show\_wait\_msg} is TRUE then a decorationless window with progress mess
|
||||
|
||||
\func{virtual wxHtmlHelpFrame*}{CreateHelpFrame}{\param{wxHtmlHelpData * }{data}}
|
||||
|
||||
This protected virtual method may be overriden so that the controller
|
||||
This protected virtual method may be overridden so that the controller
|
||||
uses slightly different frame. See {\it samples/html/helpview} sample for
|
||||
an example.
|
||||
\membersection{wxHtmlHelpController::Display}\label{wxhtmlhelpcontrollerdisplay}
|
||||
|
@@ -15,7 +15,7 @@ passed {\bf string}. See the example:
|
||||
mywin -> LoadPage("test.htm");
|
||||
mywin -> SetPage("<html><body>"
|
||||
"<h1>Error</h1>"
|
||||
"Some error occured :-H)"
|
||||
"Some error occurred :-H)"
|
||||
"</body></hmtl>");
|
||||
\end{verbatim}
|
||||
|
||||
|
@@ -131,7 +131,7 @@ Returns pointer to the source being parsed.
|
||||
|
||||
\func{virtual void}{InitParser}{\param{const wxString\& }{source}}
|
||||
|
||||
Setups the parser for parsing the {\it source} string. (Should be overriden
|
||||
Setups the parser for parsing the {\it source} string. (Should be overridden
|
||||
in derived class)
|
||||
|
||||
\membersection{wxHtmlParser::Parse}\label{wxhtmlparserparse}
|
||||
@@ -188,7 +188,7 @@ It is obvious that you cannot use only one tag handler for <param> tag.
|
||||
Instead you must use context-sensitive handlers for <param> inside <myitems>
|
||||
and <param> inside <execute>.
|
||||
|
||||
This is the prefered solution:
|
||||
This is the preferred solution:
|
||||
|
||||
\begin{verbatim}
|
||||
TAG_HANDLER_BEGIN(MYITEM, "MYITEMS")
|
||||
|
@@ -127,7 +127,7 @@ htmlwin -> SetPage("help/myproject/index.htm");
|
||||
|
||||
\wxheading{Return value}
|
||||
|
||||
FALSE if an error occured, TRUE otherwise
|
||||
FALSE if an error occurred, TRUE otherwise
|
||||
|
||||
\membersection{wxHtmlWindow::OnLinkClicked}\label{wxhtmlwindowonlinkclicked}
|
||||
|
||||
@@ -230,7 +230,7 @@ If you want to load a document from some location use
|
||||
|
||||
\wxheading{Return value}
|
||||
|
||||
FALSE if an error occured, TRUE otherwise.
|
||||
FALSE if an error occurred, TRUE otherwise.
|
||||
|
||||
\membersection{wxHtmlWindow::SetRelatedFrame}\label{wxhtmlwindowsetrelatedframe}
|
||||
|
||||
|
@@ -1,11 +1,11 @@
|
||||
\section{wxWindows "Hello World"}\label{helloworld}
|
||||
|
||||
As many people have requested a mini-sample to be published here
|
||||
so that some quick judgements concerning syntax
|
||||
so that some quick judgments concerning syntax
|
||||
and basic principles can be made, you can now look at wxWindows'
|
||||
"Hello World":
|
||||
|
||||
You have to include wxWindows's header files, of course. This can
|
||||
You have to include wxWindows' header files, of course. This can
|
||||
be done on a file by file basis (such as \#include "wx/window.h")
|
||||
or using one global include (\#include "wx/wx.h"). This is
|
||||
also useful on platforms which support precompiled headers such
|
||||
@@ -75,7 +75,7 @@ enum
|
||||
};
|
||||
\end{verbatim}
|
||||
|
||||
We then procede to actually implement an event table in which the events
|
||||
We then proceed to actually implement an event table in which the events
|
||||
are routed to their respective handler functions in the class MyFrame.
|
||||
There are predefined macros for routing all common events, ranging from
|
||||
the selection of a list box entry to a resize event when a user resizes
|
||||
@@ -101,11 +101,11 @@ using this macro, which creates an application instance and starts the program.
|
||||
IMPLEMENT_APP(MyApp)
|
||||
\end{verbatim}
|
||||
|
||||
As mentionend above, wxApp::OnInit() is called upon startup and should be
|
||||
As mentioned above, wxApp::OnInit() is called upon startup and should be
|
||||
used to initialize the program, maybe showing a "splash screen" and creating
|
||||
the main window (or several). The frame should get a title bar text ("Hello World")
|
||||
and a position and start-up size. One frame can also be declared to be the
|
||||
top window. Returning TRUE indicates a successful intialization.
|
||||
top window. Returning TRUE indicates a successful initialization.
|
||||
|
||||
\begin{verbatim}
|
||||
bool MyApp::OnInit()
|
||||
@@ -142,9 +142,9 @@ MyFrame::MyFrame(const wxString& title, const wxPoint& pos, const wxSize& size)
|
||||
\end{verbatim}
|
||||
|
||||
Here are the actual event handlers. MyFrame::OnQuit() closes the main window
|
||||
by calling Close(). The paramter TRUE indicates that other windows have no veto
|
||||
by calling Close(). The parameter TRUE indicates that other windows have no veto
|
||||
power such as after asking "Do you really want to close?". If there is no other
|
||||
main window left, the applicatin will quit.
|
||||
main window left, the application will quit.
|
||||
|
||||
\begin{verbatim}
|
||||
void MyFrame::OnQuit(wxCommandEvent& WXUNUSED(event))
|
||||
@@ -159,7 +159,7 @@ case a typical "About" window with information about the program.
|
||||
\begin{verbatim}
|
||||
void MyFrame::OnAbout(wxCommandEvent& WXUNUSED(event))
|
||||
{
|
||||
wxMessageBox( "This is a wxWindows's Hello world sample",
|
||||
wxMessageBox( "This is a wxWindows' Hello world sample",
|
||||
"About Hello World", wxOK | wxICON_INFORMATION );
|
||||
}
|
||||
\end{verbatim}
|
||||
|
@@ -6,7 +6,7 @@
|
||||
%% Created: 07.03.00
|
||||
%% RCS-ID: $Id$
|
||||
%% Copyright: (c) Vadim Zeitlin
|
||||
%% Licence: wxWindows licence
|
||||
%% License: wxWindows license
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{\class{wxLongLong}}\label{wxlonglong}
|
||||
|
@@ -91,7 +91,7 @@ members of the wxWindows team\\
|
||||
Portions (c) 1996 Artificial Intelligence Applications Institute\\
|
||||
\end{center}
|
||||
|
||||
Please also see the wxWindows licence files (preamble.txt, lgpl.txt, gpl.txt, licence.txt,
|
||||
Please also see the wxWindows license files (preamble.txt, lgpl.txt, gpl.txt, license.txt,
|
||||
licendoc.txt) for conditions of software and documentation use.
|
||||
|
||||
\section*{wxWindows Library License, Version 3}
|
||||
|
@@ -245,7 +245,7 @@ Child frames may be either \helpref{wxMDIChildFrame}{wxmdichildframe}, or \helpr
|
||||
|
||||
An MDI parent frame always has a \helpref{wxMDIClientWindow}{wxmdiclientwindow} associated with it, which
|
||||
is the parent for MDI client frames.
|
||||
This client window may be resized to accomodate non-MDI windows, as seen in Microsoft Visual C++ (TM) and
|
||||
This client window may be resized to accommodate non-MDI windows, as seen in Microsoft Visual C++ (TM) and
|
||||
Microsoft Publisher (TM), where a documentation window is placed to one side of the workspace.
|
||||
|
||||
MDI remains popular despite dire warnings from Microsoft itself that MDI is an obsolete
|
||||
|
@@ -527,7 +527,7 @@ Adds the item to the end of the menu bar.
|
||||
|
||||
\wxheading{Return value}
|
||||
|
||||
TRUE on success, FALSE if an error occured.
|
||||
TRUE on success, FALSE if an error occurred.
|
||||
|
||||
\wxheading{See also}
|
||||
|
||||
@@ -720,7 +720,7 @@ position $0$ will insert it in the very beginning of it, inserting at position
|
||||
|
||||
\wxheading{Return value}
|
||||
|
||||
TRUE on success, FALSE if an error occured.
|
||||
TRUE on success, FALSE if an error occurred.
|
||||
|
||||
\wxheading{See also}
|
||||
|
||||
|
@@ -25,7 +25,7 @@ None.
|
||||
|
||||
\func{}{wxMutexLocker}{\param{wxMutex *}{mutex}}
|
||||
|
||||
Constructs a wxMutexLocker object associated with mutex which must be non NULL
|
||||
Constructs a wxMutexLocker object associated with mutex which must be non-NULL
|
||||
and locks it. Call \helpref{IsLocked}{wxmutexlockerisok} to check if the mutex was
|
||||
successfully locked.
|
||||
|
||||
|
@@ -18,7 +18,7 @@ and will be supported by the user community for some time. And when you have
|
||||
changed to 2.0, we hope that you will appreciate the benefits in terms
|
||||
of greater flexibility, better user interface aesthetics, improved C++ conformance,
|
||||
improved compilation speed, and many other enhancements. The revised architecture
|
||||
of 2.0 will ensure that wxWindows can continue to evolve for the forseeable
|
||||
of 2.0 will ensure that wxWindows can continue to evolve for the foreseeable
|
||||
future.
|
||||
|
||||
{\it Please note that this document is a work in progress.}
|
||||
@@ -147,7 +147,7 @@ See \helpref{Device contexts and painting}{portingdc}.
|
||||
These objects - instances of classes such as wxPen, wxBrush, wxBitmap (but not wxColour) -
|
||||
are now implemented with reference-counting. This makes assignment a very cheap operation,
|
||||
and also means that management of the resource is largely automatic. You now pass {\it references} to
|
||||
objects to functions such as wxDC::SetPen, not pointers, so you will need to derefence your pointers.
|
||||
objects to functions such as wxDC::SetPen, not pointers, so you will need to dereference your pointers.
|
||||
The device context does not store a copy of the pen
|
||||
itself, but takes a copy of it (via reference counting), and the object's data gets freed up
|
||||
when the reference count goes to zero. The application does not have to worry so much about
|
||||
|
@@ -783,7 +783,7 @@ this by a scaling factor to take the preview DC size into account.
|
||||
|
||||
\func{bool}{HasPage}{\param{int}{ pageNum}}
|
||||
|
||||
Should be overriden to return TRUE if the document has this page, or FALSE
|
||||
Should be overridden to return TRUE if the document has this page, or FALSE
|
||||
if not. Returning FALSE signifies the end of the document. By default,
|
||||
HasPage behaves as if the document has only one page.
|
||||
|
||||
@@ -802,9 +802,9 @@ this function cancels the print job. OnBeginDocument is called once for every
|
||||
copy printed.
|
||||
|
||||
The base wxPrintout::OnBeginDocument {\it must} be called (and the return value
|
||||
checked) from within the overriden function, since it calls wxDC::StartDoc.
|
||||
checked) from within the overridden function, since it calls wxDC::StartDoc.
|
||||
|
||||
\pythonnote{If this method is overriden in a Python class then the
|
||||
\pythonnote{If this method is overridden in a Python class then the
|
||||
base class version can be called by using the method
|
||||
{\tt base_OnBeginDocument(startPage, endPage)}. }
|
||||
|
||||
@@ -816,7 +816,7 @@ Called by the framework at the end of document printing. OnEndDocument
|
||||
is called once for every copy printed.
|
||||
|
||||
The base wxPrintout::OnEndDocument {\it must} be called
|
||||
from within the overriden function, since it calls wxDC::EndDoc.
|
||||
from within the overridden function, since it calls wxDC::EndDoc.
|
||||
|
||||
\membersection{wxPrintout::OnBeginPrinting}\label{wxprintoutonbeginprinting}
|
||||
|
||||
|
@@ -83,7 +83,7 @@ See \helpref{wxProcess::Redirect}{wxprocessredirect}.
|
||||
\constfunc{void}{OnTerminate}{\param{int}{ pid}, \param{int}{ status}}
|
||||
|
||||
It is called when the process with the pid {\it pid} finishes.
|
||||
It raises a wxWindows event when it isn't overriden.
|
||||
It raises a wxWindows event when it isn't overridden.
|
||||
|
||||
\docparam{pid}{The pid of the process which has just terminated.}
|
||||
|
||||
|
@@ -333,7 +333,7 @@ one property, and there is no provision for invoking further dialogs. The reader
|
||||
may like to work out how the form view could be extended to provide some of the
|
||||
functionality of the property list!
|
||||
|
||||
Validator objects may be associated explictly with a wxProperty, or they may be
|
||||
Validator objects may be associated explicitly with a wxProperty, or they may be
|
||||
indirectly associated by virtue of a property `kind' that matches validators having
|
||||
that kind. In the latter case, such validators are stored in a validator registry
|
||||
which is passed to the view before the dialog is shown. If the validator takes
|
||||
@@ -453,7 +453,7 @@ example, in Visual Basic and similar programming environments, you can
|
||||
`edit a button', or rather, edit the button's properties. One of the
|
||||
properties you can edit is {\it width} - but there is no explicit
|
||||
representation of width in a wxWindows button; instead, you call SetSize
|
||||
and GetSize members. To translate this into a consisent,
|
||||
and GetSize members. To translate this into a consistent,
|
||||
property-oriented scheme, we could derive a new class
|
||||
wxButtonWithProperties, which has two new functions: SetProperty and
|
||||
GetProperty. SetProperty accepts a property name and a value, and calls
|
||||
|
@@ -68,19 +68,19 @@ Returns TRUE, if successful, else FALSE.
|
||||
|
||||
\func{wxProtocolError}{GetError}{\void}
|
||||
|
||||
Returns the last occured error.
|
||||
Returns the last occurred error.
|
||||
|
||||
\twocolwidtha{7cm}
|
||||
\begin{twocollist}\itemsep=0pt
|
||||
\twocolitem{{\bf wxPROTO\_NOERR}}{No error.}
|
||||
\twocolitem{{\bf wxPROTO\_NETERR}}{A generic network error occured.}
|
||||
\twocolitem{{\bf wxPROTO\_PROTERR}}{An error occured during negotiation.}
|
||||
\twocolitem{{\bf wxPROTO\_NETERR}}{A generic network error occurred.}
|
||||
\twocolitem{{\bf wxPROTO\_PROTERR}}{An error occurred during negotiation.}
|
||||
\twocolitem{{\bf wxPROTO\_CONNERR}}{The client failed to connect the server.}
|
||||
\twocolitem{{\bf wxPROTO\_INVVAL}}{Invalid value.}
|
||||
\twocolitem{{\bf wxPROTO\_NOHNDLR}}{.}
|
||||
\twocolitem{{\bf wxPROTO\_NOFILE}}{The remote file doesn't exist.}
|
||||
\twocolitem{{\bf wxPROTO\_ABRT}}{Last action aborted.}
|
||||
\twocolitem{{\bf wxPROTO\_RCNCT}}{An error occured during reconnection.}
|
||||
\twocolitem{{\bf wxPROTO\_RCNCT}}{An error occurred during reconnection.}
|
||||
\twocolitem{{\bf wxPROTO\_STREAM}}{Someone tried to send a command during a transfer.}
|
||||
\end{twocollist}
|
||||
|
||||
|
@@ -20,7 +20,7 @@ What makes sizers so well fitted for use in wxWindows is the fact that every con
|
||||
reports its own minimal size and the algorithm can handle differences in font sizes
|
||||
or different window (dialog item) sizes on different platforms without problems. If e.g.
|
||||
the standard font as well as the overall design of Motif widgets requires more space than
|
||||
on Windows, the intial dialog size will automatically be bigger on Motif than on Windows.
|
||||
on Windows, the initial dialog size will automatically be bigger on Motif than on Windows.
|
||||
|
||||
\pythonnote{If you wish to create a sizer class in wxPython you should
|
||||
derive the class from {\tt wxPySizer} in order to get Python-aware
|
||||
@@ -56,7 +56,7 @@ The destructor.
|
||||
Adds the {\it window} to the sizer. As wxSizer itself is an abstract class, the parameters
|
||||
have no meaning in the wxSizer class itself, but as there currently is only one class
|
||||
deriving directly from wxSizer and this class does not override these methods, the meaning
|
||||
of the paramters is described here:
|
||||
of the parameters is described here:
|
||||
|
||||
\docparam{window}{The window to be added to the sizer. Its initial size (either set explicitly by the
|
||||
user or calculated internally when using wxDefaultSize) is interpreted as the minimal and in many
|
||||
|
@@ -6,7 +6,7 @@
|
||||
%% Created: 1999
|
||||
%% RCS-ID: $Id$
|
||||
%% Copyright: (c) wxWindows team
|
||||
%% Licence: wxWindows licence
|
||||
%% License: wxWindows license
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{\class{wxSocketBase}}\label{wxsocketbase}
|
||||
@@ -219,7 +219,7 @@ void SocketCallback(wxSocketBase& sock, wxSocketNotify evt, char *cdata);
|
||||
\end{verbatim}
|
||||
|
||||
The first parameter is a reference to the socket object in which the
|
||||
event occured. The second parameter tells you which event occured.
|
||||
event occurred. The second parameter tells you which event occurred.
|
||||
(See \helpref{wxSocket events}{wxsocketbase}). The third parameter
|
||||
is the user data you specified using \helpref{CallbackData}{wxsocketbasecallbackdata}.
|
||||
|
||||
@@ -316,7 +316,7 @@ If you use \helpref{Error}{wxsocketbaseerror}, it will always return FALSE.
|
||||
|
||||
\constfunc{bool}{Error}{\void}
|
||||
|
||||
Returns TRUE if an error occured in the last IO operation.
|
||||
Returns TRUE if an error occurred in the last IO operation.
|
||||
|
||||
Use this function to check for an error condition after one of the
|
||||
following calls: Discard, Peek, Read, ReadMsg, Unread, Write, WriteMsg.
|
||||
@@ -446,7 +446,7 @@ ReadMsg, Unread, Write, WriteMsg.
|
||||
Returns the last wxSocket error. See \helpref{wxSocket errors}{wxsocketbase}.
|
||||
|
||||
Please note that this function merely returns the last error code,
|
||||
but it should not be used to determine if an error has occured (this
|
||||
but it should not be used to determine if an error has occurred (this
|
||||
is because successful operations do not change the LastError value).
|
||||
Use \helpref{Error}{wxsocketbaseerror} first, in order to determine
|
||||
if the last IO call failed. If this returns TRUE, use LastError
|
||||
@@ -1085,7 +1085,7 @@ and {\bf wxSOCKET\_LOST} events (for connection failure).
|
||||
|
||||
Returns TRUE if the connection is established and no error occurs.
|
||||
|
||||
If {\it wait} was TRUE, and Connect returns FALSE, an error occured
|
||||
If {\it wait} was TRUE, and Connect returns FALSE, an error occurred
|
||||
and the connection failed.
|
||||
|
||||
If {\it wait} was FALSE, and Connect returns FALSE, you should still
|
||||
@@ -1277,7 +1277,7 @@ that there is an incoming connection waiting to be accepted.
|
||||
|
||||
\wxheading{Return value}
|
||||
|
||||
Returns an opened socket connection, or NULL if an error occured or
|
||||
Returns an opened socket connection, or NULL if an error occurred or
|
||||
if the {\it wait} parameter was FALSE and there were no pending
|
||||
connections.
|
||||
|
||||
@@ -1303,7 +1303,7 @@ Accept an incoming connection using the specified socket object.
|
||||
|
||||
\wxheading{Return value}
|
||||
|
||||
Returns TRUE on success, or FALSE if an error occured or if the
|
||||
Returns TRUE on success, or FALSE if an error occurred or if the
|
||||
{\it wait} parameter was FALSE and there were no pending
|
||||
connections.
|
||||
|
||||
|
@@ -106,7 +106,7 @@ See \helpref{wxSpinButton::wxSpinButton}{wxspinbuttonconstr} for details.
|
||||
|
||||
\constfunc{int}{GetMax}{\void}
|
||||
|
||||
Returns the maximum permissable value.
|
||||
Returns the maximum permissible value.
|
||||
|
||||
\wxheading{See also}
|
||||
|
||||
@@ -116,7 +116,7 @@ Returns the maximum permissable value.
|
||||
|
||||
\constfunc{int}{GetMin}{\void}
|
||||
|
||||
Returns the minimum permissable value.
|
||||
Returns the minimum permissible value.
|
||||
|
||||
\wxheading{See also}
|
||||
|
||||
|
@@ -114,7 +114,7 @@ May only be called while processing
|
||||
wxEVT\_COMMAND\_SPLITTER\_SASH\_POS\_CHANGING and
|
||||
wxEVT\_COMMAND\_SPLITTER\_SASH\_POS\_CHANGED events.
|
||||
|
||||
\wxheading{Paramters}
|
||||
\wxheading{Parameters}
|
||||
|
||||
\docparam{pos}{New sash position.}
|
||||
|
||||
|
@@ -252,7 +252,7 @@ and then resplitting the window back because it will provoke much less flicker
|
||||
(if any). It is valid to call this function whether the splitter has two
|
||||
windows or only one.
|
||||
|
||||
Both parameters should be non NULL and {\it winOld} must specify one of the
|
||||
Both parameters should be non-NULL and {\it winOld} must specify one of the
|
||||
windows managed by the splitter. If the parameters are incorrect or the window
|
||||
couldn't be replaced, FALSE is returned. Otherwise the function will return
|
||||
TRUE, but please notice that it will not delete the replaced window and you
|
||||
|
@@ -90,7 +90,7 @@ accordingly until all requested data is read.
|
||||
\wxheading{Return value}
|
||||
|
||||
It returns the size of the data read. If the returned size is different of the specified
|
||||
{\it size}, an error has occured and should be tested using
|
||||
{\it size}, an error has occurred and should be tested using
|
||||
\helpref{LastError}{wxstreambaselasterror}.
|
||||
|
||||
\func{size\_t}{Read}{\param{wxStreamBuffer *}{buffer}}
|
||||
@@ -121,7 +121,7 @@ Gets a single char from the stream buffer. It acts like the Read call.
|
||||
|
||||
\wxheading{Problem}
|
||||
|
||||
You aren't directly notified if an error occured during the IO call.
|
||||
You aren't directly notified if an error occurred during the IO call.
|
||||
|
||||
\wxheading{See also}
|
||||
|
||||
@@ -135,7 +135,7 @@ Puts a single char to the stream buffer.
|
||||
|
||||
\wxheading{Problem}
|
||||
|
||||
You aren't directly notified if an error occured during the IO call.
|
||||
You aren't directly notified if an error occurred during the IO call.
|
||||
|
||||
\wxheading{See also}
|
||||
|
||||
|
@@ -43,7 +43,7 @@ Destructor.
|
||||
|
||||
\constfunc{wxStreamError}{IsOk}{\void}
|
||||
|
||||
Returns TRUE if no error occured on the stream.
|
||||
Returns TRUE if no error occurred on the stream.
|
||||
|
||||
\wxheading{See also}
|
||||
|
||||
@@ -57,10 +57,10 @@ This function returns the last error.
|
||||
|
||||
\twocolwidtha{5cm}
|
||||
\begin{twocollist}\itemsep=0pt
|
||||
\twocolitem{{\bf wxSTREAM\_NO\_ERROR}}{No error occured.}
|
||||
\twocolitem{{\bf wxSTREAM\_EOF}}{An End-Of-File occured.}
|
||||
\twocolitem{{\bf wxSTREAM\_WRITE\_ERROR}}{A generic error occured on the last write call.}
|
||||
\twocolitem{{\bf wxSTREAM\_READ\_ERROR}}{A generic error occured on the last read call.}
|
||||
\twocolitem{{\bf wxSTREAM\_NO\_ERROR}}{No error occurred.}
|
||||
\twocolitem{{\bf wxSTREAM\_EOF}}{An End-Of-File occurred.}
|
||||
\twocolitem{{\bf wxSTREAM\_WRITE\_ERROR}}{A generic error occurred on the last write call.}
|
||||
\twocolitem{{\bf wxSTREAM\_READ\_ERROR}}{A generic error occurred on the last read call.}
|
||||
\end{twocollist}
|
||||
|
||||
\membersection{wxStreamBase::OnSysRead}\label{wxstreambaseonsysread}
|
||||
|
@@ -6,7 +6,7 @@
|
||||
%% Created: 1999
|
||||
%% RCS-ID: $Id$
|
||||
%% Copyright: (c) wxWindows team
|
||||
%% Licence: wxWindows licence
|
||||
%% License: wxWindows license
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
% -----------------------------------------------------------------------------
|
||||
|
@@ -80,7 +80,7 @@ it to wxBitmap form. Note that using wxImage is the preferred way to
|
||||
load images in wxWindows, with the exception of resources (XPM-files or
|
||||
native Windows resources). Writing an image format handler for wxImage
|
||||
is also far easier than writing one for wxBitmap, because wxImage has
|
||||
exactly one format on all platforms wheras wxBitmap can store pixel data
|
||||
exactly one format on all platforms whereas wxBitmap can store pixel data
|
||||
very differently, depending on colour depths and platform.
|
||||
|
||||
\wxheading{wxBitmap}
|
||||
|
@@ -35,7 +35,7 @@ should do.
|
||||
|
||||
The data provider is responsible for creating a
|
||||
\helpref{wxDataObject}{wxdataobject} containing the data to be
|
||||
transfered. Then it should either pass it to the clipboard using
|
||||
transferred. Then it should either pass it to the clipboard using
|
||||
\helpref{SetData}{wxclipboardsetdata} function or to
|
||||
\helpref{wxDropSource}{wxdropsource} and call
|
||||
\helpref{DoDragDrop}{wxdropsourcedodragdrop} function.
|
||||
@@ -62,7 +62,7 @@ create a \helpref{wxDataObject}{wxdataobject} derived class which supports the
|
||||
data formats you need and pass it as argument to
|
||||
\helpref{wxClipboard::GetData}{wxclipboardgetdata}. If it returns {\tt FALSE},
|
||||
no data in (any of) the supported format(s) is available. If it returns {\tt
|
||||
TRUE}, the data has been successfully transfered to wxDataObject.
|
||||
TRUE}, the data has been successfully transferred to wxDataObject.
|
||||
|
||||
For drag and drop case, the \helpref{wxDropTarget::OnData}{wxdroptargetondata}
|
||||
virtual function will be called when a data object is dropped, from which the
|
||||
|
@@ -23,7 +23,7 @@ consumption point of view.
|
||||
\end{enumerate}
|
||||
|
||||
On the other hand, the features provided make them very useful for storing all
|
||||
kinds of small to medium volumes of hierarchically-organized, heterogenous
|
||||
kinds of small to medium volumes of hierarchically-organized, heterogeneous
|
||||
data. In short, this is a place where you can conveniently stuff all your data
|
||||
(numbers and strings) organizing it in a tree where you use the
|
||||
filesystem-like paths to specify the location of a piece of data. In
|
||||
|
@@ -69,13 +69,13 @@ When the user sets constraints, many of the constraints for windows
|
||||
edges and dimensions remain unconstrained. For a given window,
|
||||
the wxWindow::Layout algorithm first resets all constraints
|
||||
in all children to have unknown edge or dimension values, and then iterates through the constraints,
|
||||
evaulating them. For unconstrained edges and dimensions, it
|
||||
evaluating them. For unconstrained edges and dimensions, it
|
||||
tries to find the value using known relationships that always hold. For example,
|
||||
an unconstrained {\it width} may be calculated from the {\it left} and {\it right edges}, if
|
||||
both are currently known. For edges and dimensions with user-supplied constraints, these
|
||||
constraints are evaulated if the inputs of the constraint are known.
|
||||
constraints are evaluated if the inputs of the constraint are known.
|
||||
|
||||
The algorithm stops when all child edges and dimension are known (success), or there
|
||||
The algorithm stops when all child edges and dimension are known (success), or
|
||||
there are unknown edges or dimensions but there has been no change in this cycle (failure).
|
||||
|
||||
It then sets all the window positions and sizes according to the values it has found.
|
||||
@@ -85,7 +85,7 @@ irrelevant, however you may reduce the number of iterations (and thus speed up
|
||||
the layout calculations) by creating the controls in such order that as many
|
||||
constraints as possible can be calculated during the first iteration. For example, if
|
||||
you have 2 buttons which you'd like to position in the lower right corner, it is
|
||||
slighty more efficient to first create the second button and specify that its
|
||||
slightly more efficient to first create the second button and specify that its
|
||||
right border IsSameAs(parent, wxRight) and then create the first one by
|
||||
specifying that it should be LeftOf() the second one than to do in a more
|
||||
natural left-to-right order.
|
||||
|
@@ -9,7 +9,7 @@ To create a client which can communicate with a suitable server,
|
||||
you need to derive a class from wxTCPConnection and another from wxTCPClient.
|
||||
The custom wxTCPConnection class will intercept communications in
|
||||
a `conversation' with a server, and the custom wxTCPServer is required
|
||||
so that a user-overriden \helpref{wxTCPClient::OnMakeConnection}{wxtcpclientonmakeconnection} member can return
|
||||
so that a user-overridden \helpref{wxTCPClient::OnMakeConnection}{wxtcpclientonmakeconnection} member can return
|
||||
a wxTCPConnection of the required class, when a connection is made.
|
||||
|
||||
\wxheading{Derived from}
|
||||
|
@@ -6,7 +6,7 @@
|
||||
%% Created: 07.03.00
|
||||
%% RCS-ID: $Id$
|
||||
%% Copyright: (c) Vadim Zeitlin
|
||||
%% Licence: wxWindows licence
|
||||
%% License: wxWindows license
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{Date and time classes overview}\label{wxdatetimeoverview}
|
||||
|
@@ -17,7 +17,7 @@ file via an ODBC driver. The language for most of the database
|
||||
operations is SQL, so you need to learn a small amount of SQL as well as
|
||||
the wxWindows ODBC wrapper API. Even though the databases may not be
|
||||
SQL-based, the ODBC drivers translate SQL into appropriate operations
|
||||
for the database or file: even text files have rudimentry ODBC support,
|
||||
for the database or file: even text files have rudimentary ODBC support,
|
||||
along with dBASE, Access, Excel and other file formats.
|
||||
|
||||
The run-time files for ODBC are bundled with many existing database
|
||||
|
@@ -70,7 +70,7 @@ the exit command altogether.
|
||||
|
||||
\wxheading{What should I do to upgrade my 1.xx OnClose to 2.0?}
|
||||
|
||||
In wxWindows 1.xx, the {\bf OnClose} function did not actually delete 'this', but signalled
|
||||
In wxWindows 1.xx, the {\bf OnClose} function did not actually delete 'this', but signaled
|
||||
to the calling function (either {\bf Close}, or the wxWindows framework) to delete
|
||||
or not delete the window.
|
||||
|
||||
|
@@ -189,7 +189,7 @@ The wxDocManager class is part of the document/view framework supported by wxWin
|
||||
and cooperates with the \helpref{wxView}{wxview}, \helpref{wxDocument}{wxdocument}\rtfsp
|
||||
and \helpref{wxDocTemplate}{wxdoctemplate} classes.
|
||||
|
||||
A wxDocManager instance coordinates documents, views and document templates. It keeps a list of document and
|
||||
A wxDocManager instance coordinates documents, views and document templates. It keeps a list of document
|
||||
and template instances, and much functionality is routed through this object, such
|
||||
as providing selection and file dialogs. The application can use this class `as is' or
|
||||
derive a class and override some members to extend or change the functionality.
|
||||
|
@@ -66,7 +66,7 @@ Associates wxTempFile with the file to be replaced and opens it. You should use
|
||||
\func{bool}{Open}{\param{const wxString\& }{strName}}
|
||||
|
||||
Open the temporary file (strName is the name of file to be replaced), returns
|
||||
TRUE on success, FALSE if an error occured.
|
||||
TRUE on success, FALSE if an error occurred.
|
||||
|
||||
\membersection{wxTempFile::IsOpened}\label{wxtempfileisopened}
|
||||
\constfunc{bool}{IsOpened}{\void}
|
||||
|
@@ -136,7 +136,7 @@ recursively applied to the parent window's event handler. If this returns TRUE,
|
||||
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
|
||||
heirarchy from child to parent until an event handler is found that
|
||||
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.
|
||||
|
||||
@@ -328,7 +328,7 @@ called via \helpref{wxWindow::Close}{wxwindowclose}.}
|
||||
\twocolitem{\helpref{wxDropFilesEvent}{wxdropfilesevent}}{The EVT\_DROP\_FILES macros handles
|
||||
file drop events.}
|
||||
\twocolitem{\helpref{wxEraseEvent}{wxeraseevent}}{The EVT\_ERASE\_BACKGROUND macro is used to handle window erase requests.}
|
||||
\twocolitem{\helpref{wxFocusEvent}{wxfocusevent}}{The EVT\_SET\_FOCUS and EVT\_KILL\_FOCUS macros are used to handle keybaord focus events.}
|
||||
\twocolitem{\helpref{wxFocusEvent}{wxfocusevent}}{The EVT\_SET\_FOCUS and EVT\_KILL\_FOCUS macros are used to handle keyboard focus events.}
|
||||
\twocolitem{\helpref{wxKeyEvent}{wxkeyevent}}{EVT\_CHAR and EVT\_CHAR\_HOOK macros handle keyboard
|
||||
input for any window.}
|
||||
\twocolitem{\helpref{wxIdleEvent}{wxidleevent}}{The EVT\_IDLE macro handle application idle events
|
||||
@@ -341,7 +341,7 @@ to handle dialog initialisation.}
|
||||
mouse events or all mouse events.}
|
||||
\twocolitem{\helpref{wxMoveEvent}{wxmoveevent}}{The EVT\_MOVE macro is used to handle a window move.}
|
||||
\twocolitem{\helpref{wxPaintEvent}{wxpaintevent}}{The EVT\_PAINT macro is used to handle window paint requests.}
|
||||
\twocolitem{\helpref{wxScrollEvent}{wxscrollevent}}{These macros are used to handle scroll events from
|
||||
\twocolitem{\helpref{wxScrollEvent}{wxscrollevent}}{These macros are used to handle scroll events from
|
||||
\helpref{wxScrollBar}{wxscrollbar}, \helpref{wxSlider}{wxslider},and \helpref{wxSpinButton}{wxspinbutton}.}
|
||||
\twocolitem{\helpref{wxSizeEvent}{wxsizeevent}}{The EVT\_SIZE macro is used to handle a window resize.}
|
||||
\twocolitem{\helpref{wxSplitterEvent}{wxsplitterevent}}{The EVT\_SPLITTER\_SASH\_POS\_CHANGED, EVT\_SPLITTER\_UNSPLIT
|
||||
|
@@ -140,7 +140,7 @@ way to the current compilation.
|
||||
These are the known bugs:
|
||||
|
||||
\begin{enumerate}\itemsep=0pt
|
||||
\item Functors are permissable only in the main clause (object).
|
||||
\item Functors are permissible only in the main clause (object).
|
||||
Therefore nesting of structures must be done using lists, not predicates
|
||||
as in Prolog.
|
||||
\item There is a limit to the size of strings read in (about 5000 bytes).
|
||||
|
@@ -6,7 +6,7 @@
|
||||
%% Created: 03.11.99
|
||||
%% RCS-ID: $Id$
|
||||
%% Copyright: (c) Vadim Zeitlin
|
||||
%% Licence: wxWindows licence
|
||||
%% License: wxWindows license
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{Font encoding overview}\label{wxfontencodingoverview}
|
||||
@@ -16,7 +16,7 @@ By encoding we mean here the mapping between the character codes and the
|
||||
letters. Probably the most well-known encoding is (7 bit) ASCII one which is
|
||||
used almost universally now to represent the letters of the English alphabet
|
||||
and some other common characters. However, it is not enough to represent the
|
||||
letters of foreign alphabetes and here other encodings come into play. Please
|
||||
letters of foreign alphabets and here other encodings come into play. Please
|
||||
note that we will only discuss 8-bit fonts here and not
|
||||
\helpref{Unicode}{unicode}.
|
||||
|
||||
@@ -38,27 +38,28 @@ wxFONTENCODING\_SYSTEM, but may be changed to make all the fonts created later
|
||||
to use it (by default).}
|
||||
\twocolitem{wxFONTENCODING\_ISO8859\_1..15}{ISO8859 family encodings which are
|
||||
usually used by all non-Microsoft operating systems}
|
||||
\twocolitem{wxFONTENCODING\_KOI8}{Standard cyrillic encoding for the Internet
|
||||
\twocolitem{wxFONTENCODING\_KOI8}{Standard Cyrillic encoding for the Internet
|
||||
(but see also wxFONTENCODING\_ISO8859\_5 and wxFONTENCODING\_CP1251)}
|
||||
\twocolitem{wxFONTENCODING\_CP1250}{Microsoft analogue of ISO8859-2}
|
||||
\twocolitem{wxFONTENCODING\_CP1251}{Microsoft analogue of ISO8859-5}
|
||||
\twocolitem{wxFONTENCODING\_CP1252}{Microsoft analogue of ISO8859-1}
|
||||
\end{twocollist}
|
||||
|
||||
As you may see, Microsofts encoding partly mirror the standard ISO8859 ones,
|
||||
As you may see, Microsoft's encoding partly mirror the standard ISO8859 ones,
|
||||
but there are (minor) differences even between ISO8859-1 (Latin1, ISO encoding
|
||||
for Western Europe) and CP1251 (WinLatin1, standard code page for English
|
||||
versions of Windows) and there are more of them for other encodings.
|
||||
|
||||
The situation is particularly complicated with cyrillic encodings for which
|
||||
The situation is particularly complicated with Cyrillic encodings for which
|
||||
(more than) three incompatible encodings exist: KOI8 (the old standard, widely
|
||||
used on the Internet), ISO8859-5 (ISO standard for cyrillic) and CP1251
|
||||
used on the Internet), ISO8859-5 (ISO standard for Cyrillic) and CP1251
|
||||
(WinCyrillic).
|
||||
|
||||
This abundance of (incompatible) encodigns should make it clear that using
|
||||
This abundance of (incompatible) encoding:w
|
||||
s should make it clear that using
|
||||
encodings is less easy than it might seem. The problems arise both from the
|
||||
fact that the standard encodigns for the given language (say Russian, which is
|
||||
written in cyrillic) are different on different platforms and because the
|
||||
fact that the standard encodings for the given language (say Russian, which is
|
||||
written in Cyrillic) are different on differe nt platforms and because the
|
||||
fonts in the given encoding might just not be installed (this is especially a
|
||||
problem with Unix, or, in general, not Win32, systems).
|
||||
|
||||
|
@@ -24,7 +24,7 @@ to be buggy, so you should find a later version of it!
|
||||
|
||||
There are two kinds of message catalogs: source catalogs which are text files
|
||||
with extension .po and binary catalogs which are created from the source ones
|
||||
with {\it msgfmt} program (part fo gettext package) and have the extension .mo.
|
||||
with {\it msgfmt} program (part of gettext package) and have the extension .mo.
|
||||
Only the binary files are needed during program execution.
|
||||
|
||||
The program i18n involves several steps:
|
||||
|
@@ -51,7 +51,7 @@ identify the server and a topic name to identify the topic for the
|
||||
duration of the connection. Under Unix, the service name must contain an
|
||||
integer port identifier.
|
||||
|
||||
The server then responds and either vetos the connection or allows it.
|
||||
The server then responds and either vetoes the connection or allows it.
|
||||
If allowed, a connection object is created which persists until the
|
||||
connection is closed. The connection object is then used for subsequent
|
||||
messages between client and server.
|
||||
@@ -132,7 +132,7 @@ To create a client which can communicate with a suitable server,
|
||||
you need to derive a class from wxDDEConnection and another from wxDDEClient.
|
||||
The custom wxDDEConnection class will intercept communications in
|
||||
a `conversation' with a server, and the custom wxDDEServer is required
|
||||
so that a user-overriden \helpref{wxDDEClient::OnMakeConnection}{wxddeclientonmakeconnection} member can return
|
||||
so that a user-overridden \helpref{wxDDEClient::OnMakeConnection}{wxddeclientonmakeconnection} member can return
|
||||
a wxDDEConnection of the required class, when a connection is made.
|
||||
|
||||
For example:
|
||||
|
@@ -39,7 +39,7 @@ bar of the active or specified (as the first argument) \helpref{wxFrame}{wxframe
|
||||
handy for logging errors after system call (API function) failure. It logs the
|
||||
specified message text as well as the last system error
|
||||
code ({\it errno} or {\it ::GetLastError()} depending on the platform) and the corresponding error
|
||||
message. The second form of this function takes the error code explitly as the
|
||||
message. The second form of this function takes the error code explicitly as the
|
||||
first argument.
|
||||
\item{\bf wxLogDebug} is {\bf the} right function for debug output. It only
|
||||
does anything at all in the debug mode (when the preprocessor symbol
|
||||
|
@@ -14,7 +14,7 @@ and it will be handled transparently under all systems.
|
||||
Please read \helpref{Internationalization}{internationalization} which
|
||||
describes locales concept.
|
||||
|
||||
Whereever in the following text {\it iso8859-2} and {\it windows-1250} are
|
||||
Wherever in the following text {\it iso8859-2} and {\it windows-1250} are
|
||||
used, any encodings are meant and any encodings may be substituted there.
|
||||
|
||||
\wxheading{Locales}
|
||||
@@ -82,7 +82,7 @@ How is this done? When you tell wxLocale class to load message catalog that
|
||||
contains the header (msgid "". Normal .mo catalogs do {\bf not} contain it,
|
||||
you must remove the line with {\it fuzzy}!), it checks the charset. If the
|
||||
charset is "alien" on the platform the program is currently running (e.g.
|
||||
any of ISO encodings under Windows or CP12XX under Unix) it uses
|
||||
any of ISO encodings under Windows or CP12XX under Unix) it uses
|
||||
\helpref{wxEncodingConverter::GetPlatformEquivalents}{wxencodingconvertergetplatformequivalents}
|
||||
to obtain encoding that is more common on this platform and converts
|
||||
the message catalog to this encoding. Note that it does {\bf not} check
|
||||
|
@@ -19,7 +19,7 @@ to use whenever possible \helpref{wxDynamicCast()}{wxdynamiccast} macro which,
|
||||
for the implementations that support it, is defined just as dynamic\_cast<> and
|
||||
uses wxWindows RTTI for all the others. This macro is limited to wxWindows
|
||||
classes only and only works with pointers (unlike the real dynamic\_cast<> which
|
||||
also accepts referencies).
|
||||
also accepts references).
|
||||
|
||||
Each class that you wish to be known the type system should have
|
||||
a macro such as DECLARE\_DYNAMIC\_CLASS just inside the class declaration.
|
||||
|
@@ -6,7 +6,7 @@
|
||||
%% Created: 02.11.99
|
||||
%% RCS-ID: $Id$
|
||||
%% Copyright: (c) wxWindows team
|
||||
%% Licence: wxWindows licence
|
||||
%% License: wxWindows license
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
% NB: please keep the subsections in alphabetic order!
|
||||
|
||||
@@ -61,8 +61,8 @@ menu) and also how to process the notifications from it.
|
||||
|
||||
This sample demonstrates the use of the \helpref{wxCheckListBox}{wxchecklistbox}
|
||||
class intercepting check, select and double click events. It also tests the
|
||||
use of various methods modifiying the control, such as by deleting items
|
||||
from it or inserting new once (these fucntions are actually implememted in
|
||||
use of various methods modifying the control, such as by deleting items
|
||||
from it or inserting new once (these functions are actually implemented in
|
||||
the parent class \helpref{wxListBox}{wxlistbox} so the sample tests that class
|
||||
as well). The layout of the dialog is created using a \helpref{wxBoxSizer}{wxboxsizer}
|
||||
demonstrating a simple dynamic layout.
|
||||
@@ -70,7 +70,7 @@ demonstrating a simple dynamic layout.
|
||||
\subsection{Config sample}\label{sampleconfig}
|
||||
|
||||
This sample demonstrates the \helpref{wxConfig}{wxconfigbase} classes in a platform
|
||||
indepedent way, i.e. it uses text based files to store a given configuration under
|
||||
indenpedent way, i.e. it uses text based files to store a given configuration under
|
||||
Unix and uses the Registry under Windows.
|
||||
|
||||
See \helpref{wxConfig overview}{wxconfigoverview} for the descriptions of all
|
||||
@@ -83,9 +83,9 @@ wxWindows. The sample tests their basic functionality, events, placement,
|
||||
modification in terms of colour and font as well as the possibility to change
|
||||
the controls programmatically, such as adding item to a list box etc. Apart
|
||||
from that, the sample uses a \helpref{wxNotebook}{wxnotebook} and tests most
|
||||
fetaures of this special control (using bitmap in the tabs, using
|
||||
features of this special control (using bitmap in the tabs, using
|
||||
\helpref{wxSizers}{wxsizer} and \helpref{constraints}{wxlayoutconstraints} within
|
||||
notebook pages, advanving pages programmatically and vetoing a page change
|
||||
notebook pages, advancing pages programmatically and vetoing a page change
|
||||
by intercepting the \helpref{wxNotebookEvent}{wxnotebookevent}.
|
||||
|
||||
The various controls tested are listed here:
|
||||
@@ -119,7 +119,7 @@ system.
|
||||
\subsection{Dialogs sample}\label{sampledialogs}
|
||||
|
||||
This sample shows how to use the common dialogs available from wxWindows. These
|
||||
dialogs are desrcibed in details in the \helpref{Common dialogs overview}{commondialogsoverview}.
|
||||
dialogs are described in details in the \helpref{Common dialogs overview}{commondialogsoverview}.
|
||||
|
||||
\subsection{Dynamic sample}\label{sampledynamic}
|
||||
|
||||
@@ -128,7 +128,7 @@ This sample is a very small sample that demonstrates the use of the
|
||||
should be used whenever it is not known at compile time, which control
|
||||
will receive which event or which controls are actually going to be in
|
||||
a dialog or frame. This is most typically the case for any scripting
|
||||
languge that would work as a wrapper for wxWindows or programs where
|
||||
language that would work as a wrapper for wxWindows or programs where
|
||||
forms or similar datagrams can be created by the uses.
|
||||
|
||||
\subsection{Exec sample}\label{sampleexec}
|
||||
@@ -141,7 +141,7 @@ until the program terminates) or asynchronously (notification will come later).
|
||||
\subsection{Scroll subwindow sample}\label{samplescrollsub}
|
||||
|
||||
This sample demonstrates the use of the \helpref{wxScrolledWindow}{wxscrolledwindow}
|
||||
class including placing subwindows into it and drawing simple graphics. It uses the
|
||||
class including placing subwindows into it and drawing simple graphics. It uses the
|
||||
\helpref{SetTargetWindow}{wxscrolledwindowsettargetwindow} method and thus the effect
|
||||
of scrolling does not show in the scrolled window itself, but in one of its subwindows.
|
||||
|
||||
@@ -234,7 +234,7 @@ class which serves as as-simple-as-possible interface for printing HTML
|
||||
documents without much work. In fact, only few function calls are sufficient.
|
||||
|
||||
{\bf Help} and {\bf Helpview} are variations on displaying HTML help
|
||||
(compatible with MS HTML Help Workshop). {\it Help} shows how to embed
|
||||
(compatible with MS HTML Help Workshop). {\it Help} shows how to embed
|
||||
\helpref{wxHtmlHelpController}{wxhtmlhelpcontroller} in your application
|
||||
while {\it Helpview} is simple tool that only pops up help window and
|
||||
displays help books given at command line.
|
||||
@@ -244,7 +244,7 @@ displays help books given at command line.
|
||||
The image sample demonstrates the use of the \helpref{wxImage}{wximage} class
|
||||
and shows how to download images in a variety of formats, currently PNG, GIF,
|
||||
TIFF, JPEG, BMP, PNM and PCX. The top of the sample shows to rectangles, one
|
||||
of which is drawn directly in the window, the other one is drawn into a
|
||||
of which is drawn directly in the window, the other one is drawn into a
|
||||
\helpref{wxBitmap}{wxbitmap}, converted to a wxImage, saved as a PNG image
|
||||
and then reloaded from the PNG file again so that conversions between wxImage
|
||||
and wxBitmap as well as loading and save PNG files are tested.
|
||||
@@ -353,10 +353,10 @@ password, ignoring TAB, ignoring ENTER).
|
||||
|
||||
Secondly it shows how to intercept a \helpref{wxKeyEvent}{wxkeyevent} in both
|
||||
the raw form using the {\tt EVT\_KEY\_UP} and {\tt EVT\_KEY\_DOWN} macros and the
|
||||
higherlevel from using the {\tt EVT\_CHAR} macro. All characters will be logged
|
||||
higher level from using the {\tt EVT\_CHAR} macro. All characters will be logged
|
||||
in a log window at the bottom of the main window. By pressing some of the function
|
||||
keys, you can test some actions in the text ctrl as well as get statitics on the
|
||||
text ctrls, which is useful for testing if these statitics actually are correct.
|
||||
keys, you can test some actions in the text ctrl as well as get statistics on the
|
||||
text ctrls, which is useful for testing if these stastitics actually are correct.
|
||||
|
||||
Thirdly, on platforms which support it, the sample will offer to copy text to the
|
||||
\helpref{wxClipboard}{wxclipboard} and to paste text from it. The GTK version will
|
||||
@@ -397,7 +397,7 @@ The following things are demonstrated:
|
||||
and \helpref{wxToolBar::AddControl}{wxtoolbaraddcontrol}: see
|
||||
MyApp::InitToolbar in the sample.
|
||||
\item Using {\tt EVT\_UPDATE\_UI} handler for automatically enabling/disabling
|
||||
toolbar buttons without having to explicitly call EnableTool. This is is done
|
||||
toolbar buttons without having to explicitly call EnableTool. This is done
|
||||
in MyFrame::OnUpdateCopyAndCut.
|
||||
\item Using \helpref{wxToolBar::DeleteTool}{wxtoolbardeletetool} and
|
||||
\helpref{wxToolBar::InsertTool}{wxtoolbarinserttool} to dynamically update the
|
||||
|
@@ -27,7 +27,7 @@ that implements its own scrolling, largely because columns and rows can vary in
|
||||
\wxheading{The scrollbar model}
|
||||
|
||||
The function \helpref{wxWindow::SetScrollbar}{wxwindowsetscrollbar} gives a clue about
|
||||
the way a scrollbar is modelled. This function takes the following arguments:
|
||||
the way a scrollbar is modeled. This function takes the following arguments:
|
||||
|
||||
\twocolwidtha{5cm}%
|
||||
\begin{twocollist}
|
||||
|
@@ -27,7 +27,7 @@ wxFilterIn/OutputStream
|
||||
\end{enumerate}
|
||||
|
||||
wxStreamBase is the base definition of a stream. It defines, for example,
|
||||
the API of OnSysRead, OnSysWrite, OnSysSeek and OnSysTell. These functions are
|
||||
the API of OnSysRead, OnSysWrite, OnSysSeek and OnSysTell. These functions
|
||||
are really implemented by the "IO" classes.
|
||||
wxInputStream and wxOutputStream inherit from it.
|
||||
|
||||
@@ -39,8 +39,8 @@ wxInputStream is the base class for read-only streams. It implements Read,
|
||||
SeekI (I for Input), and all read or IO generic related functions.
|
||||
wxOutputStream does the same thing but it is for write-only streams.
|
||||
|
||||
wxFilterIn/OutputStream is base class definition for stream filtering.
|
||||
I mean by stream filtering, a stream which does no syscall but filter datas
|
||||
wxFilterIn/OutputStream is the base class definition for stream filtering.
|
||||
Stream filtering means a stream which does no syscall but filters data
|
||||
which are passed to it and then pass them to another stream.
|
||||
For example, wxZLibInputStream is an inline stream decompressor.
|
||||
|
||||
|
@@ -13,7 +13,7 @@ wxString only works with ASCII (8 bit characters) strings as of this release,
|
||||
but support for UNICODE (16 but characters) is planned for the next one.
|
||||
|
||||
This class has all the standard operations you can expect to find in a string class:
|
||||
dynamic memory management (string extends to accomodate new characters),
|
||||
dynamic memory management (string extends to accommodate new characters),
|
||||
construction from other strings, C strings and characters, assignment operators,
|
||||
access to individual characters, string concatenation and comparison, substring
|
||||
extraction, case conversion, trimming and padding (with spaces), searching and
|
||||
@@ -73,7 +73,7 @@ in both wxWindows and other programs (by just typedefing wxString as std::string
|
||||
when used outside wxWindows) and by staying compatible with future versions of
|
||||
wxWindows which will probably start using std::string sooner or later too.
|
||||
|
||||
In the situations where there is no correspondinw std::string function, please
|
||||
In the situations where there is no corresponding std::string function, please
|
||||
try to use the new wxString methods and not the old wxWindows 1.xx variants
|
||||
which are deprecated and may disappear in future versions.
|
||||
|
||||
@@ -171,7 +171,7 @@ share the same data.
|
||||
|
||||
But as soon as one of the two (or more) strings is modified, the data has to be
|
||||
copied because the changes to one of the strings shouldn't be seen in the
|
||||
otheres. As data copying only happens when the string is written to, this is
|
||||
others. As data copying only happens when the string is written to, this is
|
||||
known as COW.
|
||||
|
||||
What is important to understand is that all this happens absolutely
|
||||
@@ -259,7 +259,7 @@ which tells the wxString class to collect performance statistics and to show
|
||||
them on stderr on program termination. This will show you the average length of
|
||||
strings your program manipulates, their average initial length and also the
|
||||
percent of times when memory wasn't reallocated when string concatenation was
|
||||
done but the alread preallocated memory was used (this value should be about
|
||||
done but the already preallocated memory was used (this value should be about
|
||||
98\% for the default allocation policy, if it is less than 90\% you should
|
||||
really consider fine tuning wxString for your application).
|
||||
|
||||
|
@@ -15,7 +15,7 @@ well.
|
||||
|
||||
These classes will hopefully make writing MT programs easier and they also
|
||||
provide some extra error checking (compared to the native (be it Win32 or Posix)
|
||||
thread API), however it is still an untrivial undertaking especially for large
|
||||
thread API), however it is still an non-trivial undertaking especially for large
|
||||
projects. Before starting an MT application (or starting to add MT features to
|
||||
an existing one) it is worth asking oneself if there is no easier and safer way
|
||||
to implement the same functionality. Of course, in some situations threads
|
||||
|
@@ -39,7 +39,7 @@ No absolute positioning is supported but you can specify the number
|
||||
of rows, and add tool separators with {\bf AddSeparator}.
|
||||
Tooltips are supported. {\bf OnRightClick} is not supported. This is the default wxToolBar
|
||||
on Windows 95, Windows NT 4 and above. With the style wxTB\_FLAT, the flat toolbar
|
||||
look is used, with a border that is highlit when the cursor moves over the buttons.
|
||||
look is used, with a border that is highlighted when the cursor moves over the buttons.
|
||||
\end{itemize}
|
||||
|
||||
A toolbar might appear as a single row of images under
|
||||
@@ -86,7 +86,7 @@ overriding OnLeftClick.
|
||||
// Created: 04/01/98
|
||||
// RCS-ID: $Id$
|
||||
// Copyright: (c) Julian Smart
|
||||
// Licence: wxWindows licence
|
||||
// License: wxWindows license
|
||||
/////////////////////////////////////////////////////////////////////////////
|
||||
|
||||
// For compilers that support precompilation, includes "wx/wx.h".
|
||||
|
@@ -23,7 +23,7 @@ may be retrieved with the corresponding functions:
|
||||
\helpref{IsSelected}{wxtreectrlisselected},
|
||||
\helpref{IsVisible}{wxtreectrlisvisible}, \helpref{IsBold}{wxtreectrlisbold}
|
||||
and \helpref{IsExpanded}{wxtreectrlisexpanded}. Only one item at a time may be
|
||||
selected, selecting anopther one (with
|
||||
selected, selecting another one (with
|
||||
\helpref{SelectItem}{wxtreectrlselectitem}) automatically unselects the
|
||||
previously selected one.
|
||||
|
||||
@@ -47,7 +47,7 @@ beginning, only the root item is created (with
|
||||
EVT\_TREE\_ITEM\_EXPANDING event is received: then all items lying immediately
|
||||
under the item being expanded should be added, but, of course, only when this
|
||||
event is received for the first time for this item - otherwise, the items would
|
||||
be added twice if the user expands/collapses/reexapnds the branch.
|
||||
be added twice if the user expands/collapses/re-expands the branch.
|
||||
|
||||
The tree control provides functions for enumerating its items. There are 3
|
||||
groups of enumeration functions: for the children of a given item, for the
|
||||
|
@@ -19,7 +19,7 @@ characters from languages other than English.
|
||||
|
||||
Starting with release 2.1 wxWindows has support for compiling in Unicode mode
|
||||
on the platforms which support it. Unicode is a standard for character
|
||||
encoding which addreses the shortcomings of the previous, 8 bit standards, by
|
||||
encoding which addresses the shortcomings of the previous, 8 bit standards, by
|
||||
using 16 bit for encoding each character. This allows to have 65536 characters
|
||||
instead of the usual 256 and is sufficient to encode all of the world
|
||||
languages at once. More details about Unicode may be found at {\tt www.unicode.org}.
|
||||
@@ -28,14 +28,14 @@ languages at once. More details about Unicode may be found at {\tt www.unicode.o
|
||||
|
||||
As this solution is obviously preferable to the previous ones (think of
|
||||
incompatible encodings for the same language, locale chaos and so on), many
|
||||
modern ooperating systems support it. The probably first example is Windows NT
|
||||
modern operating systems support it. The probably first example is Windows NT
|
||||
which uses only Unicode internally since its very first version.
|
||||
|
||||
Writing internationalized programs is much easier with Unicode and, as the
|
||||
support for it improves, it should become more and more so. Moreover, in the
|
||||
Windows NT/2000 case, even the program which uses only standard ASCII can profit
|
||||
from using Unicode because they will work more efficiently - there will be no
|
||||
need for the system to convert all strings hte program uses to/from Unicode
|
||||
need for the system to convert all strings the program uses to/from Unicode
|
||||
each time a system call is made.
|
||||
|
||||
\subsection{Unicode and ANSI modes}
|
||||
@@ -46,7 +46,7 @@ environment. A better solution is to write programs in such way that they may
|
||||
be compiled either in ANSI (traditional) mode or in the Unicode one.
|
||||
|
||||
This can be achieved quite simply by using the means provided by wxWindows.
|
||||
Basicly, there are only a few things to watch out for:
|
||||
Basically, there are only a few things to watch out for:
|
||||
|
||||
\begin{itemize}
|
||||
\item Character type ({\tt char} or {\tt wchar\_t})
|
||||
@@ -96,7 +96,7 @@ section.
|
||||
|
||||
\subsection{Unicode support in wxWindows}
|
||||
|
||||
In wxWindows, the code fragment froim above should be written instead:
|
||||
In wxWindows, the code fragment from above should be written instead:
|
||||
|
||||
\begin{verbatim}
|
||||
wxChar ch = wxT('*');
|
||||
@@ -145,7 +145,7 @@ Although everything works fine inside the program, things can get nasty when
|
||||
it tries to communicate with the outside world which, sadly, often expects
|
||||
ANSI strings (a notable exception is the entire Win32 API which accepts either
|
||||
Unicode or ANSI strings and which thus makes it unnecessary to ever perform
|
||||
any convertions in the program).
|
||||
any conversions in the program).
|
||||
|
||||
To get a ANSI string from a wxString, you may use the
|
||||
mb\_str() function which always returns an ANSI
|
||||
|
@@ -89,7 +89,7 @@ It can be one of these errors:
|
||||
\twocolitem{{\bf wxURL\_NOHOST}}{An host name is required for this protocol.}
|
||||
\twocolitem{{\bf wxURL\_NOPATH}}{A path is required for this protocol.}
|
||||
\twocolitem{{\bf wxURL\_CONNERR}}{Connection error.}
|
||||
\twocolitem{{\bf wxURL\_PROTOERR}}{An error occured during negotiation.}
|
||||
\twocolitem{{\bf wxURL\_PROTOERR}}{An error occurred during negotiation.}
|
||||
\end{twocollist}%
|
||||
|
||||
%
|
||||
|
@@ -1738,7 +1738,7 @@ Physically scrolls the pixels in the window and move child windows accordingly.
|
||||
|
||||
\docparam{rect}{Rectangle to invalidate. If this is NULL, the whole window is invalidated. If you
|
||||
pass a rectangle corresponding to the area of the window exposed by the scroll, your painting handler
|
||||
can optimise painting by checking for the invalidated region. This paramter is ignored under GTK.}
|
||||
can optimize painting by checking for the invalidated region. This parameter is ignored under GTK.}
|
||||
|
||||
\wxheading{Remarks}
|
||||
|
||||
@@ -1758,7 +1758,7 @@ Sets the accelerator table for this window. See \helpref{wxAcceleratorTable}{wxa
|
||||
Determines whether the \helpref{wxWindow::Layout}{wxwindowlayout} function will
|
||||
be called automatically when the window is resized. Use in connection with
|
||||
\helpref{wxWindow::SetSizer}{wxwindowsetsizer} and
|
||||
\helpref{wxWindow::SetConstraints}{wxwindowsetconstraints} for layouting subwindows.
|
||||
\helpref{wxWindow::SetConstraints}{wxwindowsetconstraints} for laying out subwindows.
|
||||
|
||||
\wxheading{Parameters}
|
||||
|
||||
|
@@ -6,7 +6,7 @@
|
||||
%% Created: 03.03.00
|
||||
%% RCS-ID: $Id$
|
||||
%% Copyright: (c) Vadim Zeitlin
|
||||
%% Licence: wxWindows licence
|
||||
%% License: wxWindows license
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\section{\class{wxWindowDisabler}}\label{wxwindowdisabler}
|
||||
|
@@ -35,8 +35,8 @@ wxPython is a Python package that can be imported at runtime that
|
||||
includes a collection of Python modules and an extension module
|
||||
(native code). It provides a series of Python classes that mirror (or
|
||||
shadow) many of the wxWindows GUI classes. This extension module
|
||||
attempts to mirror the class heiarchy of wxWindows as closely as
|
||||
possble. This means that there is a wxFrame class in wxPython that
|
||||
attempts to mirror the class heirarchy of wxWindows as closely as
|
||||
possible. This means that there is a wxFrame class in wxPython that
|
||||
looks, smells, tastes and acts almost the same as the wxFrame class in
|
||||
the C++ version.
|
||||
|
||||
@@ -55,7 +55,7 @@ details about getting wxPython working for you.
|
||||
So why would you want to use wxPython over just C++ and wxWindows?
|
||||
Personally I prefer using Python for everything. I only use C++ when
|
||||
I absolutely have to eek more performance out of an algorithm, and even
|
||||
then I ususally code it as an extension module and leave the majority
|
||||
then I usually code it as an extension module and leave the majority
|
||||
of the program in Python.
|
||||
|
||||
Another good thing to use wxPython for is quick prototyping of your
|
||||
@@ -80,7 +80,7 @@ This has its upsides and its downsides...
|
||||
|
||||
The upside is that Tk is a pretty versatile toolkit. It can be made
|
||||
to do a lot of things in a lot of different environments. It is fairly
|
||||
easy to create new widgets and use them interchangably in your
|
||||
easy to create new widgets and use them interchangeably in your
|
||||
programs.
|
||||
|
||||
The downside is Tcl. When using Tkinter you actually have two
|
||||
@@ -89,7 +89,7 @@ Tcl interpreter for the GUI. Since the guts of Tcl is mostly about
|
||||
string processing, it is fairly slow as well. (Not too bad on a fast
|
||||
Pentium II, but you really notice the difference on slower machines.)
|
||||
|
||||
It wasn't until the lastest version of Tcl/Tk that native Look and
|
||||
It wasn't until the latest version of Tcl/Tk that native Look and
|
||||
Feel was possible on non-Motif platforms. This is because Tk
|
||||
usually implements its own widgets (controls) even when there are
|
||||
native controls available.
|
||||
@@ -111,7 +111,7 @@ to use the GUI portions.
|
||||
\wxheading{Others}
|
||||
|
||||
There are quite a few other GUI modules available for Python, some in
|
||||
active use, some that havn't been updated for ages. Most are simple
|
||||
active use, some that haven't been updated for ages. Most are simple
|
||||
wrappers around some C or C++ toolkit or another, and most are not
|
||||
cross-platform compatible. See \urlref{this link}{http://www.python.org/download/Contributed.html\#Graphics}
|
||||
for a listing of a few of them.
|
||||
@@ -123,7 +123,7 @@ I used SWIG (\urlref{http://www.swig.org}{http://www.swig.org}) to
|
||||
to create the source code for the
|
||||
extension module. This enabled me to only have to deal with a small
|
||||
amount of code and only have to bother with the exceptional issues.
|
||||
SWIG takes care of the rest and generates all the repetative code for
|
||||
SWIG takes care of the rest and generates all the repetitive code for
|
||||
me. You don't need SWIG to build the extension module as all the
|
||||
generated C++ code is included under the src directory.
|
||||
|
||||
@@ -173,7 +173,7 @@ The build.py script actually generates a Makefile based on what it
|
||||
finds on your system and information found in the build.cfg file.
|
||||
If you have troubles building or you want it built or installed in
|
||||
a different way, take a look at the docstring in build.py. You are
|
||||
able to to override many configuration options in a file named
|
||||
able to override many configuration options in a file named
|
||||
build.local.
|
||||
\item To build and install the add-on modules, change to the appropriate
|
||||
directory under {\tt \$(WXWIN)/utils/wxPython/modules} and run the build
|
||||
@@ -300,7 +300,7 @@ methods of the class. These helper functions are intended to be like
|
||||
the event table macros that wxWindows employs. But since static event
|
||||
tables are impossible with wxPython, we use helpers that are named the
|
||||
same to dynamically build the table. The only real difference is
|
||||
that the first arguemnt to the event helpers is always the window that
|
||||
that the first argument to the event helpers is always the window that
|
||||
the event table entry should be added to.
|
||||
\item Notice the use of {\tt wxDLG\_PNT} and {\tt wxDLG\_SZE} in lines 19
|
||||
- 29 to convert from dialog units to pixels. These helpers are unique
|
||||
@@ -311,14 +311,14 @@ called? The answer is, yes it does. This is because many of the
|
||||
{\em standard} events are attached to windows that have the associated
|
||||
{\em standard} method names. I have tried to follow the lead of the
|
||||
C++ classes in this area to determine what is {\em standard} but since
|
||||
that changes from time to time I can make no guarentees, nor will it
|
||||
that changes from time to time I can make no guarantees, nor will it
|
||||
be fully documented. When in doubt, use an EVT\_*** function.
|
||||
\item At lines 17 to 21 notice that there are no saved references to
|
||||
the panel or the static text items that are created. Those of you
|
||||
who know Python might be wondering what happens when Python deletes
|
||||
these objects when they go out of scope. Do they disappear from the GUI? They
|
||||
don't. Remember that in wxPython the Python objects are just shadows of the
|
||||
coresponding C++ objects. Once the C++ windows and controls are
|
||||
corresponding C++ objects. Once the C++ windows and controls are
|
||||
attached to their parents, the parents manage them and delete them
|
||||
when necessary. For this reason, most wxPython objects do not need to
|
||||
have a \_\_del\_\_ method that explicitly causes the C++ object to be
|
||||
|
Reference in New Issue
Block a user