564747ee85
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@4541 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
536 lines
23 KiB
TeX
536 lines
23 KiB
TeX
\chapter{wxPython Notes}\label{wxPython}
|
|
\pagenumbering{arabic}%
|
|
\setheader{{\it CHAPTER \thechapter}}{}{}{}{}{{\it CHAPTER \thechapter}}%
|
|
\setfooter{\thepage}{}{}{}{}{\thepage}%
|
|
|
|
This addendum is written by Robin Dunn, author of the wxPython wrapper
|
|
|
|
%----------------------------------------------------------------------
|
|
\section{What is wxPython?}\label{wxpwhat}
|
|
|
|
wxPython is a blending of the wxWindows GUI classes and the
|
|
\urlref{Python}{http://www.python.org/} programming language.
|
|
|
|
\wxheading{Python}
|
|
|
|
So what is Python? Go to
|
|
\urlref{http://www.python.org}{http://www.python.org} to learn more,
|
|
but in a nutshell Python is an interpreted,
|
|
interactive, object-oriented programming language. It is often
|
|
compared to Tcl, Perl, Scheme or Java.
|
|
|
|
Python combines remarkable power with very clear syntax. It has
|
|
modules, classes, exceptions, very high level dynamic data types, and
|
|
dynamic typing. There are interfaces to many system calls and
|
|
libraries, and new built-in modules are easily written in C or
|
|
C++. Python is also usable as an extension language for applications
|
|
that need a programmable interface.
|
|
|
|
Python is copyrighted but freely usable and distributable, even for
|
|
commercial use.
|
|
|
|
\wxheading{wxPython}
|
|
|
|
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
|
|
looks, smells, tastes and acts almost the same as the wxFrame class in
|
|
the C++ version.
|
|
|
|
wxPython is very versitile. It can be used to create standalone GUI
|
|
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
|
|
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
|
|
then I ususally 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
|
|
wxWindows apps. With C++ you have to continuously go though the
|
|
edit-compile-link-run cycle, which can be quite time consuming. With
|
|
Python it is only an edit-run cycle. You can easily build an
|
|
application in a few hours with Python that would normally take a few
|
|
days or longer with C++. Converting a wxPython app to a C++/wxWindows app
|
|
should be a straight forward task.
|
|
|
|
%----------------------------------------------------------------------
|
|
\section{Other Python GUIs}\label{wxpother}
|
|
|
|
There are other GUI solutions out there for Python.
|
|
|
|
\wxheading{Tkinter}
|
|
|
|
Tkinter is the defacto standard GUI for Python. It is available
|
|
on nearly every platform that Python and Tcl/TK are. Why Tcl/Tk?
|
|
Well because Tkinter is just a wrapper around Tcl's GUI toolkit, Tk.
|
|
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
|
|
programs.
|
|
|
|
The downside is Tcl. When using Tkinter you actually have two
|
|
separate language interpreters running, the Python interpreter and the
|
|
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
|
|
Feel was possible on non-Motif platforms. This is because Tk
|
|
usually implements its own widgets (controls) even when there are
|
|
native controls available.
|
|
|
|
Tkinter is a pretty low-level toolkit. You have to do a lot of work
|
|
(verbose program code) to do things that would be much simpler with a higher
|
|
level of abstraction.
|
|
|
|
\wxheading{PythonWin}
|
|
|
|
PythonWin is an add-on package for Python for the Win32 platform. It
|
|
includes wrappers for MFC as well as much of the Win32 API. Because
|
|
of its foundation, it is very familiar for programmers who have
|
|
experience with MFC and the Win32 API. It is obviously not compatible
|
|
with other platforms and toolkits. PythonWin is organized as separate
|
|
packages and modules so you can use the pieces you need without having
|
|
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
|
|
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 repetative 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 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}
|
|
|
|
\wxheading{First things first...}
|
|
|
|
I'm not going to try and teach the Python language here. You can do
|
|
that at the \urlref{Python Tutorial}{http://www.python.org/doc/tut/tut.html}.
|
|
I'm also going to assume that you know a bit about wxWindows already,
|
|
enough to notice the similarities in the classes used.
|
|
|
|
Take a look at the following wxPython program. You can find a similar
|
|
program in the \tt{wxPython/demo} directory, named \tt{DialogUnits.py}. If your
|
|
Python and wxPython are properly installed, you should be able to run
|
|
it by issuing this command:
|
|
|
|
\begin{indented}{1cm}
|
|
\bftt{python DialogUnits.py}
|
|
\end{indented}
|
|
|
|
\hrule
|
|
|
|
\begin{verbatim}
|
|
001: ## import all of the wxPython GUI package
|
|
002: from wxPython.wx import *
|
|
003:
|
|
004: ## Create a new frame class, derived from the wxPython Frame.
|
|
005: class MyFrame(wxFrame):
|
|
006:
|
|
007: def __init__(self, parent, id, title):
|
|
008: # First, call the base class' __init__ method to create the frame
|
|
009: wxFrame.__init__(self, parent, id, title,
|
|
010: wxPoint(100, 100), wxSize(160, 100))
|
|
011:
|
|
012: # Associate some events with methods of this class
|
|
013: EVT_SIZE(self, self.OnSize)
|
|
014: EVT_MOVE(self, self.OnMove)
|
|
015:
|
|
016: # Add a panel and some controls to display the size and position
|
|
017: panel = wxPanel(self, -1)
|
|
018: wxStaticText(panel, -1, "Size:",
|
|
019: wxDLG_PNT(panel, wxPoint(4, 4)), wxDefaultSize)
|
|
020: wxStaticText(panel, -1, "Pos:",
|
|
021: wxDLG_PNT(panel, wxPoint(4, 14)), wxDefaultSize)
|
|
022: self.sizeCtrl = wxTextCtrl(panel, -1, "",
|
|
023: wxDLG_PNT(panel, wxPoint(24, 4)),
|
|
024: wxDLG_SZE(panel, wxSize(36, -1)),
|
|
025: wxTE_READONLY)
|
|
026: self.posCtrl = wxTextCtrl(panel, -1, "",
|
|
027: wxDLG_PNT(panel, wxPoint(24, 14)),
|
|
028: wxDLG_SZE(panel, wxSize(36, -1)),
|
|
029: wxTE_READONLY)
|
|
030:
|
|
031:
|
|
032: # This method is called automatically when the CLOSE event is
|
|
033: # sent to this window
|
|
034: def OnCloseWindow(self, event):
|
|
035: # tell the window to kill itself
|
|
036: self.Destroy()
|
|
037:
|
|
038: # This method is called by the system when the window is resized,
|
|
039: # because of the association above.
|
|
040: def OnSize(self, event):
|
|
041: size = event.GetSize()
|
|
042: self.sizeCtrl.SetValue("%s, %s" % (size.width, size.height))
|
|
043:
|
|
044: # tell the event system to continue looking for an event handler,
|
|
045: # so the default handler will get called.
|
|
046: event.Skip()
|
|
047:
|
|
048: # This method is called by the system when the window is moved,
|
|
049: # because of the association above.
|
|
050: def OnMove(self, event):
|
|
051: pos = event.GetPosition()
|
|
052: self.posCtrl.SetValue("%s, %s" % (pos.x, pos.y))
|
|
053:
|
|
054:
|
|
055: # Every wxWindows application must have a class derived from wxApp
|
|
056: class MyApp(wxApp):
|
|
057:
|
|
058: # wxWindows calls this method to initialize the application
|
|
059: def OnInit(self):
|
|
060:
|
|
061: # Create an instance of our customized Frame class
|
|
062: frame = MyFrame(NULL, -1, "This is a test")
|
|
063: frame.Show(true)
|
|
064:
|
|
065: # Tell wxWindows that this is our main window
|
|
066: self.SetTopWindow(frame)
|
|
067:
|
|
068: # Return a success flag
|
|
069: return true
|
|
070:
|
|
071:
|
|
072: app = MyApp(0) # Create an instance of the application class
|
|
073: app.MainLoop() # Tell it to start processing events
|
|
074:
|
|
\end{verbatim}
|
|
\hrule
|
|
|
|
\wxheading{Things to notice}
|
|
|
|
\begin{enumerate}\itemsep=11pt
|
|
\item At line 2 the wxPython classes, constants, and etc. are imported
|
|
into the current module's namespace. If you prefer to reduce
|
|
namespace pollution you can use "\tt{from wxPython import wx}" and
|
|
then access all the wxPython identifiers through the wx module, for
|
|
example, "\tt{wx.wxFrame}".
|
|
\item At line 13 the frame's sizing and moving events are connected to
|
|
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
|
|
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
|
|
to wxPython since Python can't do method overloading like C++.
|
|
\item There is an \tt{OnCloseWindow} method at line 34 but no call to
|
|
EVT\_CLOSE to attach the event to the method. Does it really get
|
|
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
|
|
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
|
|
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
|
|
deleted. If you ever have the need to forcibly delete a window, use
|
|
the Destroy() method as shown on line 36.
|
|
\item Just like wxWindows in C++, wxPython apps need to create a class
|
|
derived from \tt{wxApp} (line 56) that implements a method named
|
|
\tt{OnInit}, (line 59.) This method should create the application's
|
|
main window (line 62) and use \tt{wxApp.SetTopWindow()} (line 66) to
|
|
inform wxWindows about it.
|
|
\item And finally, at line 72 an instance of the application class is
|
|
created. At this point wxPython finishes initializing itself, and calls
|
|
the \tt{OnInit} method to get things started. (The zero parameter here is
|
|
a flag for functionality that isn't quite implemented yet. Just
|
|
ignore it for now.) The call to \tt{MainLoop} at line 73 starts the event
|
|
loop which continues until the application terminates or all the top
|
|
level windows are closed.
|
|
\end{enumerate}
|
|
|
|
%----------------------------------------------------------------------
|
|
\section{wxWindows classes implemented in wxPython}\label{wxpclasses}
|
|
|
|
The following classes are supported in wxPython. Most provide nearly
|
|
full implementations of the public interfaces specified in the C++
|
|
documentation, others are less so. They will all be brought as close
|
|
as possible to the C++ spec over time.
|
|
|
|
\begin{itemize}\itemsep=0pt
|
|
\item \helpref{wxAcceleratorEntry}{wxacceleratorentry}
|
|
\item \helpref{wxAcceleratorTable}{wxacceleratortable}
|
|
\item \helpref{wxActivateEvent}{wxactivateevent}
|
|
\item \helpref{wxBitmap}{wxbitmap}
|
|
\item \helpref{wxBitmapButton}{wxbitmapbutton}
|
|
\item \helpref{wxBitmapDataObject}{wxbitmapdataobject}
|
|
\item wxBMPHandler
|
|
\item \helpref{wxBoxSizer}{wxboxsizer}
|
|
\item \helpref{wxBrush}{wxbrush}
|
|
\item \helpref{wxBusyInfo}{wxbusyinfo}
|
|
\item \helpref{wxBusyCursor}{wxbusycursor}
|
|
\item \helpref{wxButton}{wxbutton}
|
|
\item \helpref{wxCalculateLayoutEvent}{wxcalculatelayoutevent}
|
|
\item wxCaret
|
|
\item \helpref{wxCheckBox}{wxcheckbox}
|
|
\item \helpref{wxCheckListBox}{wxchecklistbox}
|
|
\item \helpref{wxChoice}{wxchoice}
|
|
\item \helpref{wxClientDC}{wxclientdc}
|
|
\item \helpref{wxClipboard}{wxclipboard}
|
|
\item \helpref{wxCloseEvent}{wxcloseevent}
|
|
\item \helpref{wxColourData}{wxcolourdata}
|
|
\item \helpref{wxColourDialog}{wxcolourdialog}
|
|
\item \helpref{wxColour}{wxcolour}
|
|
\item \helpref{wxComboBox}{wxcombobox}
|
|
\item \helpref{wxCommandEvent}{wxcommandevent}
|
|
\item \helpref{wxConfig}{wxconfigbase}
|
|
\item \helpref{wxControl}{wxcontrol}
|
|
\item \helpref{wxCursor}{wxcursor}
|
|
\item \helpref{wxCustomDataObject}{wxcustomdataobject}
|
|
\item \helpref{wxDataFormat}{wxdataformat}
|
|
\item \helpref{wxDataObject}{wxdataobject}
|
|
\item \helpref{wxDataObjectComposite}{wxdataobjectcomposite}
|
|
\item \helpref{wxDataObjectSimple}{wxdataobjectsimple}
|
|
\item \helpref{wxDC}{wxdc}
|
|
\item \helpref{wxDialog}{wxdialog}
|
|
\item \helpref{wxDirDialog}{wxdirdialog}
|
|
\item \helpref{wxDropFilesEvent}{wxdropfilesevent}
|
|
\item \helpref{wxDropSource}{wxdropsource}
|
|
\item \helpref{wxDropTarget}{wxdroptarget}
|
|
\item \helpref{wxEraseEvent}{wxeraseevent}
|
|
\item \helpref{wxEvent}{wxevent}
|
|
\item \helpref{wxEvtHandler}{wxevthandler}
|
|
\item \helpref{wxFileDataObject}{wxfiledataobject}
|
|
\item \helpref{wxFileDialog}{wxfiledialog}
|
|
\item \helpref{wxFileDropTarget}{wxfiledroptarget}
|
|
\item \helpref{wxFocusEvent}{wxfocusevent}
|
|
\item \helpref{wxFontData}{wxfontdata}
|
|
\item \helpref{wxFontDialog}{wxfontdialog}
|
|
\item \helpref{wxFont}{wxfont}
|
|
\item \helpref{wxFrame}{wxframe}
|
|
\item \helpref{wxGauge}{wxgauge}
|
|
\item wxGIFHandler
|
|
\item wxGLCanvas
|
|
\item wxGridCell
|
|
\item wxGridEvent
|
|
\item \helpref{wxGrid}{wxgrid}
|
|
\item \helpref{wxHtmlCell}{wxhtmlcell}
|
|
\item \helpref{wxHtmlContainerCell}{wxhtmlcontainercell}
|
|
\item \helpref{wxHtmlDCRenderer}{wxhtmldcrenderer}
|
|
\item \helpref{wxHtmlEasyPrinting}{wxhtmleasyprinting}
|
|
\item \helpref{wxHtmlParser}{wxhtmlparser}
|
|
\item \helpref{wxHtmlTagHandler}{wxhtmltaghandler}
|
|
\item \helpref{wxHtmlTag}{wxhtmltag}
|
|
\item \helpref{wxHtmlWinParser}{wxhtmlwinparser}
|
|
\item \helpref{wxHtmlPrintout}{wxhtmlprintout}
|
|
\item \helpref{wxHtmlWinTagHandler}{wxhtmlwintaghandler}
|
|
\item \helpref{wxHtmlWindow}{wxhtmlwindow}
|
|
\item wxIconizeEvent
|
|
\item \helpref{wxIcon}{wxicon}
|
|
\item \helpref{wxIdleEvent}{wxidleevent}
|
|
\item \helpref{wxImage}{wximage}
|
|
\item \helpref{wxImageHandler}{wximagehandler}
|
|
\item \helpref{wxImageList}{wximagelist}
|
|
\item \helpref{wxIndividualLayoutConstraint}{wxindividuallayoutconstraint}
|
|
\item \helpref{wxInitDialogEvent}{wxinitdialogevent}
|
|
\item \helpref{wxJoystickEvent}{wxjoystickevent}
|
|
\item wxJPEGHandler
|
|
\item \helpref{wxKeyEvent}{wxkeyevent}
|
|
\item \helpref{wxLayoutAlgorithm}{wxlayoutalgorithm}
|
|
\item \helpref{wxLayoutConstraints}{wxlayoutconstraints}
|
|
\item \helpref{wxListBox}{wxlistbox}
|
|
\item \helpref{wxListCtrl}{wxlistctrl}
|
|
\item \helpref{wxListEvent}{wxlistevent}
|
|
\item \helpref{wxListItem}{wxlistctrlsetitem}
|
|
\item \helpref{wxMDIChildFrame}{wxmdichildframe}
|
|
\item \helpref{wxMDIClientWindow}{wxmdiclientwindow}
|
|
\item \helpref{wxMDIParentFrame}{wxmdiparentframe}
|
|
\item \helpref{wxMask}{wxmask}
|
|
\item wxMaximizeEvent
|
|
\item \helpref{wxMemoryDC}{wxmemorydc}
|
|
\item \helpref{wxMenuBar}{wxmenubar}
|
|
\item \helpref{wxMenuEvent}{wxmenuevent}
|
|
\item \helpref{wxMenuItem}{wxmenuitem}
|
|
\item \helpref{wxMenu}{wxmenu}
|
|
\item \helpref{wxMessageDialog}{wxmessagedialog}
|
|
\item \helpref{wxMetaFileDC}{wxmetafiledc}
|
|
\item \helpref{wxMiniFrame}{wxminiframe}
|
|
\item \helpref{wxMouseEvent}{wxmouseevent}
|
|
\item \helpref{wxMoveEvent}{wxmoveevent}
|
|
\item \helpref{wxNotebookEvent}{wxnotebookevent}
|
|
\item \helpref{wxNotebook}{wxnotebook}
|
|
\item \helpref{wxPageSetupDialogData}{wxpagesetupdialogdata}
|
|
\item \helpref{wxPageSetupDialog}{wxpagesetupdialog}
|
|
\item \helpref{wxPaintDC}{wxpaintdc}
|
|
\item \helpref{wxPaintEvent}{wxpaintevent}
|
|
\item \helpref{wxPalette}{wxpalette}
|
|
\item \helpref{wxPanel}{wxpanel}
|
|
\item \helpref{wxPen}{wxpen}
|
|
\item wxPNGHandler
|
|
\item \helpref{wxPoint}{wxpoint}
|
|
\item \helpref{wxPostScriptDC}{wxpostscriptdc}
|
|
\item \helpref{wxPreviewFrame}{wxpreviewframe}
|
|
\item \helpref{wxPrintData}{wxprintdata}
|
|
\item \helpref{wxPrintDialogData}{wxprintdialogdata}
|
|
\item \helpref{wxPrintDialog}{wxprintdialog}
|
|
\item \helpref{wxPrinter}{wxprinter}
|
|
\item \helpref{wxPrintPreview}{wxprintpreview}
|
|
\item \helpref{wxPrinterDC}{wxprinterdc}
|
|
\item \helpref{wxPrintout}{wxprintout}
|
|
\item \helpref{wxQueryLayoutInfoEvent}{wxquerylayoutinfoevent}
|
|
\item \helpref{wxRadioBox}{wxradiobox}
|
|
\item \helpref{wxRadioButton}{wxradiobutton}
|
|
\item \helpref{wxRealPoint}{wxrealpoint}
|
|
\item \helpref{wxRect}{wxrect}
|
|
\item \helpref{wxRegionIterator}{wxregioniterator}
|
|
\item \helpref{wxRegion}{wxregion}
|
|
\item \helpref{wxSashEvent}{wxsashevent}
|
|
\item \helpref{wxSashLayoutWindow}{wxsashlayoutwindow}
|
|
\item \helpref{wxSashWindow}{wxsashwindow}
|
|
\item \helpref{wxScreenDC}{wxscreendc}
|
|
\item \helpref{wxScrollBar}{wxscrollbar}
|
|
\item \helpref{wxScrollEvent}{wxscrollevent}
|
|
\item \helpref{wxScrolledWindow}{wxscrolledwindow}
|
|
\item \helpref{wxScrollWinEvent}{wxscrollwinevent}
|
|
\item wxShowEvent
|
|
\item \helpref{wxSingleChoiceDialog}{wxsinglechoicedialog}
|
|
\item \helpref{wxSizeEvent}{wxsizeevent}
|
|
\item \helpref{wxSize}{wxsize}
|
|
\item \helpref{wxSizer}{wxsizer}
|
|
\item wxSizerItem
|
|
\item \helpref{wxSlider}{wxslider}
|
|
\item \helpref{wxSpinButton}{wxspinbutton}
|
|
\item wxSpinEvent
|
|
\item \helpref{wxSplitterWindow}{wxsplitterwindow}
|
|
\item \helpref{wxStaticBitmap}{wxstaticbitmap}
|
|
\item \helpref{wxStaticBox}{wxstaticbox}
|
|
\item \helpref{wxStaticBoxSizer}{wxstaticboxsizer}
|
|
\item \helpref{wxStaticLine}{wxstaticline}
|
|
\item \helpref{wxStaticText}{wxstatictext}
|
|
\item \helpref{wxStatusBar}{wxstatusbar}
|
|
\item \helpref{wxSysColourChangedEvent}{wxsyscolourchangedevent}
|
|
\item \helpref{wxTaskBarIcon}{wxtaskbaricon}
|
|
\item \helpref{wxTextCtrl}{wxtextctrl}
|
|
\item \helpref{wxTextDataObject}{wxtextdataobject}
|
|
\item \helpref{wxTextDropTarget}{wxtextdroptarget}
|
|
\item \helpref{wxTextEntryDialog}{wxtextentrydialog}
|
|
\item \helpref{wxTimer}{wxtimer}
|
|
\item wxToolBarTool
|
|
\item \helpref{wxToolBar}{wxtoolbar}
|
|
\item wxToolTip
|
|
\item \helpref{wxTreeCtrl}{wxtreectrl}
|
|
\item \helpref{wxTreeEvent}{wxtreeevent}
|
|
\item \helpref{wxTreeItemData}{wxtreeitemdata}
|
|
\item wxTreeItemId
|
|
\item \helpref{wxUpdateUIEvent}{wxupdateuievent}
|
|
\item \helpref{wxValidator}{wxvalidator}
|
|
\item \helpref{wxWindowDC}{wxwindowdc}
|
|
\item \helpref{wxWindow}{wxwindow}
|
|
\end{itemize}
|
|
|
|
%----------------------------------------------------------------------
|
|
\section{Where to go for help}\label{wxphelp}
|
|
|
|
Since wxPython is a blending of multiple technologies, help comes from
|
|
multiple sources. See
|
|
\urlref{http://alldunn.com/wxPython}{http://alldunn.com/wxPython} for details on
|
|
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://starship.python.net/mailman/listinfo/wxpython-users}{http://starship.python.net/mailman/listinfo/wxpython-users}
|
|
|
|
Or you can send mail directly to the list using this address:
|
|
|
|
wxpython-users@starship.python.net
|
|
|