fixed typo in a couple method names for wxPython, also some changes in
the wxPython chapter that have been sitting on my disk for some time... git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@9599 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
parent
cf273c6718
commit
c9f00eebab
@ -178,7 +178,7 @@ centered relative to the screen anyhow.
|
||||
|
||||
\func{void}{CentreOnParent}{\param{int}{ direction = wxBOTH}}
|
||||
|
||||
Centres the window on its parent. This is a more readable synonym for
|
||||
Centres the window on its parent. This is a more readable synonym for
|
||||
\helpref{Centre}{wxwindowcentre}.
|
||||
|
||||
\wxheading{Parameters}
|
||||
@ -190,7 +190,7 @@ or {\tt wxBOTH}.}
|
||||
|
||||
This methods provides for a way to center top level windows over their
|
||||
parents instead of the entire screen. If there is no parent or if the
|
||||
window is not a top level window, then behaviour is the same as
|
||||
window is not a top level window, then behaviour is the same as
|
||||
\helpref{wxWindow::Centre}{wxwindowcentre}.
|
||||
|
||||
\wxheading{See also}
|
||||
@ -511,7 +511,7 @@ Returns a reference to the list of the window's children.
|
||||
|
||||
\constfunc{virtual void}{GetClientSize}{\param{int* }{width}, \param{int* }{height}}
|
||||
|
||||
\perlnote{In wxPerl this method takes no parameter and returns
|
||||
\perlnote{In wxPerl this method takes no parameter and returns
|
||||
a 2-element list {\tt ( width, height )}.}
|
||||
|
||||
\constfunc{virtual wxSize}{GetClientSize}{\void}
|
||||
@ -528,8 +528,8 @@ area which may be drawn on by the programmer, excluding title bar, border etc.
|
||||
\pythonnote{In place of a single overloaded method name, wxPython
|
||||
implements the following methods:\par
|
||||
\indented{2cm}{\begin{twocollist}
|
||||
\twocolitem{{\bf wxGetClientSizeTuple()}}{Returns a 2-tuple of (width, height)}
|
||||
\twocolitem{{\bf wxGetClientSize()}}{Returns a wxSize object}
|
||||
\twocolitem{{\bf GetClientSizeTuple()}}{Returns a 2-tuple of (width, height)}
|
||||
\twocolitem{{\bf GetClientSize()}}{Returns a wxSize object}
|
||||
\end{twocollist}}
|
||||
}
|
||||
|
||||
@ -547,7 +547,7 @@ Returns the associated drop target, which may be NULL.
|
||||
|
||||
\wxheading{See also}
|
||||
|
||||
\helpref{wxWindow::SetDropTarget}{wxwindowsetdroptarget},
|
||||
\helpref{wxWindow::SetDropTarget}{wxwindowsetdroptarget},
|
||||
\helpref{Drag and drop overview}{wxdndoverview}
|
||||
|
||||
\membersection{wxWindow::GetEventHandler}\label{wxwindowgeteventhandler}
|
||||
@ -1047,7 +1047,7 @@ Note that the ASCII values do not have explicit key codes: they are passed as AS
|
||||
values.
|
||||
|
||||
Note that not all keypresses can be intercepted this way. If you wish to intercept modifier
|
||||
keypresses, then you will need to use \helpref{wxWindow::OnKeyDown}{wxwindowonkeydown} or
|
||||
keypresses, then you will need to use \helpref{wxWindow::OnKeyDown}{wxwindowonkeydown} or
|
||||
\helpref{wxWindow::OnKeyUp}{wxwindowonkeyup}.
|
||||
|
||||
Most, but not all, windows allow keypresses to be intercepted.
|
||||
@ -1084,7 +1084,7 @@ values.
|
||||
|
||||
This function is only relevant to top-level windows (frames and dialogs), and under
|
||||
Windows only. Under GTK the normal EVT\_CHAR\_ event has the functionality, i.e.
|
||||
you can intercepts it and if you don't call \helpref{wxEvent::Skip}{wxeventskip}
|
||||
you can intercepts it and if you don't call \helpref{wxEvent::Skip}{wxeventskip}
|
||||
the window won't get the event.
|
||||
|
||||
\wxheading{See also}
|
||||
@ -1247,7 +1247,7 @@ use the EVT\_KEY\_DOWN macro in an event table definition. Your {\bf OnKeyDown}
|
||||
default function to achieve default keypress functionality.
|
||||
|
||||
Note that not all keypresses can be intercepted this way. If you wish to intercept special
|
||||
keys, such as shift, control, and function keys, then you will need to use \helpref{wxWindow::OnKeyDown}{wxwindowonkeydown} or
|
||||
keys, such as shift, control, and function keys, then you will need to use \helpref{wxWindow::OnKeyDown}{wxwindowonkeydown} or
|
||||
\helpref{wxWindow::OnKeyUp}{wxwindowonkeyup}.
|
||||
|
||||
Most, but not all, windows allow keypresses to be intercepted.
|
||||
@ -1276,7 +1276,7 @@ use the EVT\_KEY\_UP macro in an event table definition. Your {\bf OnKeyUp} hand
|
||||
default function to achieve default keypress functionality.
|
||||
|
||||
Note that not all keypresses can be intercepted this way. If you wish to intercept special
|
||||
keys, such as shift, control, and function keys, then you will need to use \helpref{wxWindow::OnKeyDown}{wxwindowonkeydown} or
|
||||
keys, such as shift, control, and function keys, then you will need to use \helpref{wxWindow::OnKeyDown}{wxwindowonkeydown} or
|
||||
\helpref{wxWindow::OnKeyUp}{wxwindowonkeyup}.
|
||||
|
||||
Most, but not all, windows allow key up events to be intercepted.
|
||||
@ -1806,8 +1806,8 @@ Sets the accelerator table for this window. See \helpref{wxAcceleratorTable}{wxa
|
||||
\func{void}{SetAutoLayout}{\param{bool}{ autoLayout}}
|
||||
|
||||
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
|
||||
be called automatically when the window is resized. Use in connection with
|
||||
\helpref{wxWindow::SetSizer}{wxwindowsetsizer} and
|
||||
\helpref{wxWindow::SetConstraints}{wxwindowsetconstraints} for laying out subwindows.
|
||||
|
||||
\wxheading{Parameters}
|
||||
@ -1936,7 +1936,7 @@ If the window already has a drop target, it is deleted.
|
||||
|
||||
\wxheading{See also}
|
||||
|
||||
\helpref{wxWindow::GetDropTarget}{wxwindowgetdroptarget},
|
||||
\helpref{wxWindow::GetDropTarget}{wxwindowgetdroptarget},
|
||||
\helpref{Drag and drop overview}{wxdndoverview}
|
||||
|
||||
\membersection{wxWindow::SetEventHandler}\label{wxwindowseteventhandler}
|
||||
@ -2372,9 +2372,9 @@ create a new validator of this type.
|
||||
|
||||
\func{void}{SetToolTip}{\param{wxToolTip* }{tip}}
|
||||
|
||||
Attach a tooltip to the window.
|
||||
Attach a tooltip to the window.
|
||||
|
||||
See also: \helpref{GetToolTip}{wxwindowgettooltip},
|
||||
See also: \helpref{GetToolTip}{wxwindowgettooltip},
|
||||
\helpref{wxToolTip}{wxtooltip}
|
||||
|
||||
|
||||
|
@ -35,7 +35,7 @@ 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 hierarchy of wxWindows as closely as
|
||||
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.
|
||||
@ -45,16 +45,16 @@ applications, or in situations where Python is embedded in a C++
|
||||
application as an internal scripting or macro language.
|
||||
|
||||
Currently wxPython is available for Win32 platforms and the GTK
|
||||
toolkit (wxGTK) on most Unix/X-windows platforms. The effort to
|
||||
enable wxPython for wxMotif will begin shortly. See \helpref{Building Python}{wxpbuild} for
|
||||
toolkit (wxGTK) on most Unix/X-windows platforms. See the wxPython
|
||||
website \urlref{http://wxPython.org/}{http://wxPython.org/} for
|
||||
details about getting wxPython working for you.
|
||||
|
||||
%----------------------------------------------------------------------
|
||||
\section{Why use wxPython?}\label{wxpwhy}
|
||||
|
||||
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
|
||||
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 usually code it as an extension module and leave the majority
|
||||
of the program in Python.
|
||||
|
||||
@ -116,77 +116,6 @@ 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.
|
||||
|
||||
%----------------------------------------------------------------------
|
||||
\section{Building wxPython}\label{wxpbuild}
|
||||
|
||||
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 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.
|
||||
|
||||
I added a few minor features to SWIG to control some of the code
|
||||
generation. If you want to play around with this you will need to get
|
||||
a recent version of SWIG from their CVS or from a daily build. See
|
||||
\urlref{http://www.swig.org/}{http://www.swig.org/} for details.
|
||||
|
||||
wxPython is organized as a Python package. This means that the
|
||||
directory containing the results of the build process should be a
|
||||
subdirectory of a directory on the {\tt PYTHONPATH}. (And preferably should
|
||||
be named wxPython.) You can control where the build process will dump
|
||||
wxPython by setting the {\tt TARGETDIR} variable for the build utility (see
|
||||
below).
|
||||
|
||||
\begin{enumerate}\itemsep=0pt
|
||||
\item Build wxWindows as described in its BuildCVS.txt file. For Unix
|
||||
systems I run configure with these flags:
|
||||
|
||||
\begin{verbatim}
|
||||
--with-gtk
|
||||
--with-libjpeg
|
||||
--without-odbc
|
||||
--enable-unicode=no
|
||||
--enable-threads=yes
|
||||
--enable-socket=yes
|
||||
--enable-static=no
|
||||
--enable-shared=yes
|
||||
--disable-std_iostreams
|
||||
\end{verbatim}
|
||||
|
||||
You can use whatever flags you want, but I know these work.
|
||||
|
||||
For Win32 systems I use Visual C++ 6.0, but 5.0 should work also. The
|
||||
build utility currently does not support any other Win32 compilers.
|
||||
\item At this point you may want to make an alias or symlink, script,
|
||||
batch file, whatever on the PATH that invokes {\tt \$(WXWIN)/utils/wxPython/distrib/build.py} to
|
||||
help simplify matters somewhat. For example, on my Win32 system I have a file named
|
||||
{\tt build}.bat in a directory on the PATH that contains:
|
||||
|
||||
{\tt python \%WXWIN/utils/wxPython/distrib/build.py \%1 \%2 \%3 \%4 \%5 \%6}
|
||||
\item Change into the {\tt \$(WXWIN)/utils/wxPython/src} directory.
|
||||
\item Type "{\tt build -b}" to build wxPython and "{\tt build -i}" to
|
||||
install it, or "{\tt build -bi}" to do both steps at once.
|
||||
|
||||
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 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
|
||||
utility again.
|
||||
\item Change to the {\tt \$(WXWIN)/utils/wxPython/demo} directory.
|
||||
\item Try executing the demo program. For example:
|
||||
|
||||
{\tt python demo.py}
|
||||
|
||||
To run it without requiring a console on Win32, you can use the
|
||||
{\tt pythonw.exe} version of Python either from the command line or from a
|
||||
shortcut.
|
||||
\end{enumerate}
|
||||
|
||||
%----------------------------------------------------------------------
|
||||
\section{Using wxPython}\label{wxpusing}
|
||||
@ -397,11 +326,14 @@ as possible to the C++ spec over time.
|
||||
\item \helpref{wxFileDataObject}{wxfiledataobject}
|
||||
\item \helpref{wxFileDialog}{wxfiledialog}
|
||||
\item \helpref{wxFileDropTarget}{wxfiledroptarget}
|
||||
\item \helpref{wxFileSystem}{wxfilesystem}
|
||||
\item \helpref{wxFileSystemHandler}{wxfilesystemhandler}
|
||||
\item \helpref{wxFocusEvent}{wxfocusevent}
|
||||
\item \helpref{wxFontData}{wxfontdata}
|
||||
\item \helpref{wxFontDialog}{wxfontdialog}
|
||||
\item \helpref{wxFont}{wxfont}
|
||||
\item \helpref{wxFrame}{wxframe}
|
||||
\item \helpref{wxFSFile}{wxfsfile}
|
||||
\item \helpref{wxGauge}{wxgauge}
|
||||
\item wxGIFHandler
|
||||
\item wxGLCanvas
|
||||
@ -429,6 +361,8 @@ as possible to the C++ spec over time.
|
||||
\item \helpref{wxImageList}{wximagelist}
|
||||
\item \helpref{wxIndividualLayoutConstraint}{wxindividuallayoutconstraint}
|
||||
\item \helpref{wxInitDialogEvent}{wxinitdialogevent}
|
||||
\item \helpref{wxInputStream}{wxinputstream}
|
||||
\item \helpref{wxInternetFSHandler}{wxinternetfshandler}
|
||||
\item \helpref{wxJoystickEvent}{wxjoystickevent}
|
||||
\item wxJPEGHandler
|
||||
\item \helpref{wxKeyEvent}{wxkeyevent}
|
||||
@ -438,12 +372,13 @@ as possible to the C++ spec over time.
|
||||
\item \helpref{wxListCtrl}{wxlistctrl}
|
||||
\item \helpref{wxListEvent}{wxlistevent}
|
||||
\item \helpref{wxListItem}{wxlistctrlsetitem}
|
||||
\item \helpref{wxMask}{wxmask}
|
||||
\item wxMaximizeEvent
|
||||
\item \helpref{wxMDIChildFrame}{wxmdichildframe}
|
||||
\item \helpref{wxMDIClientWindow}{wxmdiclientwindow}
|
||||
\item \helpref{wxMDIParentFrame}{wxmdiparentframe}
|
||||
\item \helpref{wxMask}{wxmask}
|
||||
\item wxMaximizeEvent
|
||||
\item \helpref{wxMemoryDC}{wxmemorydc}
|
||||
\item \helpref{wxMemoryFSHandler}{wxmemoryfshandler}
|
||||
\item \helpref{wxMenuBar}{wxmenubar}
|
||||
\item \helpref{wxMenuEvent}{wxmenuevent}
|
||||
\item \helpref{wxMenuItem}{wxmenuitem}
|
||||
@ -473,6 +408,7 @@ as possible to the C++ spec over time.
|
||||
\item \helpref{wxPrintPreview}{wxprintpreview}
|
||||
\item \helpref{wxPrinterDC}{wxprinterdc}
|
||||
\item \helpref{wxPrintout}{wxprintout}
|
||||
\item \helpref{wxProcess}{wxprocess}
|
||||
\item \helpref{wxQueryLayoutInfoEvent}{wxquerylayoutinfoevent}
|
||||
\item \helpref{wxRadioBox}{wxradiobox}
|
||||
\item \helpref{wxRadioButton}{wxradiobutton}
|
||||
@ -525,6 +461,7 @@ as possible to the C++ spec over time.
|
||||
\item \helpref{wxValidator}{wxvalidator}
|
||||
\item \helpref{wxWindowDC}{wxwindowdc}
|
||||
\item \helpref{wxWindow}{wxwindow}
|
||||
\item \helpref{wxZipFSHandler}{wxzipfshandler}
|
||||
\end{itemize}
|
||||
|
||||
%----------------------------------------------------------------------
|
||||
@ -537,10 +474,10 @@ various sources of help, but probably the best source is the
|
||||
wxPython-users mail list. You can view the archive or subscribe by
|
||||
going to
|
||||
|
||||
\urlref{http://wxwindows.org/mailman/listinfo/wxpython-users}{http://wxwindows.org/mailman/listinfo/wxpython-users}
|
||||
\urlref{http://lists.sourceforge.net/mailman/listinfo/wxpython-users}{http://lists.sourceforge.net/mailman/listinfo/wxpython-users}
|
||||
|
||||
Or you can send mail directly to the list using this address:
|
||||
|
||||
wxpython-users@wxwindows.org
|
||||
wxpython-users@lists.sourceforge.net
|
||||
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user