]>
Commit | Line | Data |
---|---|---|
1 | \chapter{wxPython Notes}\label{wxPython} | |
2 | ||
3 | \setheader{{\it CHAPTER \thechapter}}{}{}{}{}{{\it CHAPTER \thechapter}}% | |
4 | \setfooter{\thepage}{}{}{}{}{\thepage}% | |
5 | ||
6 | This addendum is written by Robin Dunn, author of the wxPython wrapper | |
7 | ||
8 | %---------------------------------------------------------------------- | |
9 | \section{What is wxPython?}\label{wxpwhat} | |
10 | ||
11 | wxPython is a blending of the wxWindows GUI classes and the | |
12 | \urlref{Python}{http://www.python.org/} programming language. | |
13 | ||
14 | \wxheading{Python} | |
15 | ||
16 | So what is Python? Go to | |
17 | \urlref{http://www.python.org}{http://www.python.org} to learn more, | |
18 | but in a nutshell Python is an interpreted, | |
19 | interactive, object-oriented programming language. It is often | |
20 | compared to Tcl, Perl, Scheme or Java. | |
21 | ||
22 | Python combines remarkable power with very clear syntax. It has | |
23 | modules, classes, exceptions, very high level dynamic data types, and | |
24 | dynamic typing. There are interfaces to many system calls and | |
25 | libraries, and new built-in modules are easily written in C or | |
26 | C++. Python is also usable as an extension language for applications | |
27 | that need a programmable interface. | |
28 | ||
29 | Python is copyrighted but freely usable and distributable, even for | |
30 | commercial use. | |
31 | ||
32 | \wxheading{wxPython} | |
33 | ||
34 | wxPython is a Python package that can be imported at runtime that | |
35 | includes a collection of Python modules and an extension module | |
36 | (native code). It provides a series of Python classes that mirror (or | |
37 | shadow) many of the wxWindows GUI classes. This extension module | |
38 | attempts to mirror the class heiarchy of wxWindows as closely as | |
39 | possble. This means that there is a wxFrame class in wxPython that | |
40 | looks, smells, tastes and acts almost the same as the wxFrame class in | |
41 | the C++ version. | |
42 | ||
43 | wxPython is very versitile. It can be used to create standalone GUI | |
44 | applications, or in situations where Python is embedded in a C++ | |
45 | application as an internal scripting or macro language. | |
46 | ||
47 | Currently wxPython is available for Win32 platforms and the GTK | |
48 | toolkit (wxGTK) on most Unix/X-windows platforms. The effort to | |
49 | enable wxPython for wxMotif will begin shortly. See \helpref{Building Python}{wxpbuild} for | |
50 | details about getting wxPython working for you. | |
51 | ||
52 | %---------------------------------------------------------------------- | |
53 | \section{Why use wxPython?}\label{wxpwhy} | |
54 | ||
55 | So why would you want to use wxPython over just C++ and wxWindows? | |
56 | Personally I prefer using Python for everything. I only use C++ when | |
57 | I absolutely have to eek more performance out of an algorithm, and even | |
58 | then I ususally code it as an extension module and leave the majority | |
59 | of the program in Python. | |
60 | ||
61 | Another good thing to use wxPython for is quick prototyping of your | |
62 | wxWindows apps. With C++ you have to continuously go though the | |
63 | edit-compile-link-run cycle, which can be quite time consuming. With | |
64 | Python it is only an edit-run cycle. You can easily build an | |
65 | application in a few hours with Python that would normally take a few | |
66 | days or longer with C++. Converting a wxPython app to a C++/wxWindows app | |
67 | should be a straight forward task. | |
68 | ||
69 | %---------------------------------------------------------------------- | |
70 | \section{Other Python GUIs}\label{wxpother} | |
71 | ||
72 | There are other GUI solutions out there for Python. | |
73 | ||
74 | \wxheading{Tkinter} | |
75 | ||
76 | Tkinter is the defacto standard GUI for Python. It is available | |
77 | on nearly every platform that Python and Tcl/TK are. Why Tcl/Tk? | |
78 | Well because Tkinter is just a wrapper around Tcl's GUI toolkit, Tk. | |
79 | This has its upsides and its downsides... | |
80 | ||
81 | The upside is that Tk is a pretty versatile toolkit. It can be made | |
82 | to do a lot of things in a lot of different environments. It is fairly | |
83 | easy to create new widgets and use them interchangably in your | |
84 | programs. | |
85 | ||
86 | The downside is Tcl. When using Tkinter you actually have two | |
87 | separate language interpreters running, the Python interpreter and the | |
88 | Tcl interpreter for the GUI. Since the guts of Tcl is mostly about | |
89 | string processing, it is fairly slow as well. (Not too bad on a fast | |
90 | Pentium II, but you really notice the difference on slower machines.) | |
91 | ||
92 | It wasn't until the lastest version of Tcl/Tk that native Look and | |
93 | Feel was possible on non-Motif platforms. This is because Tk | |
94 | usually implements its own widgets (controls) even when there are | |
95 | native controls available. | |
96 | ||
97 | Tkinter is a pretty low-level toolkit. You have to do a lot of work | |
98 | (verbose program code) to do things that would be much simpler with a higher | |
99 | level of abstraction. | |
100 | ||
101 | \wxheading{PythonWin} | |
102 | ||
103 | PythonWin is an add-on package for Python for the Win32 platform. It | |
104 | includes wrappers for MFC as well as much of the Win32 API. Because | |
105 | of its foundation, it is very familiar for programmers who have | |
106 | experience with MFC and the Win32 API. It is obviously not compatible | |
107 | with other platforms and toolkits. PythonWin is organized as separate | |
108 | packages and modules so you can use the pieces you need without having | |
109 | to use the GUI portions. | |
110 | ||
111 | \wxheading{Others} | |
112 | ||
113 | There are quite a few other GUI modules available for Python, some in | |
114 | active use, some that havn't been updated for ages. Most are simple | |
115 | wrappers around some C or C++ toolkit or another, and most are not | |
116 | cross-platform compatible. See \urlref{this link}{http://www.python.org/download/Contributed.html\#Graphics} | |
117 | for a listing of a few of them. | |
118 | ||
119 | %---------------------------------------------------------------------- | |
120 | \section{Building wxPython}\label{wxpbuild} | |
121 | ||
122 | I used SWIG (\urlref{http://www.swig.org}{http://www.swig.org}) to | |
123 | to create the source code for the | |
124 | extension module. This enabled me to only have to deal with a small | |
125 | amount of code and only have to bother with the exceptional issues. | |
126 | SWIG takes care of the rest and generates all the repetative code for | |
127 | me. You don't need SWIG to build the extension module as all the | |
128 | generated C++ code is included under the src directory. | |
129 | ||
130 | I added a few minor features to SWIG to control some of the code | |
131 | generation. If you want to play around with this you will need to get | |
132 | a recent version of SWIG from their CVS or from a daily build. See | |
133 | \urlref{http://www.swig.org/}{http://www.swig.org/} for details. | |
134 | ||
135 | wxPython is organized as a Python package. This means that the | |
136 | directory containing the results of the build process should be a | |
137 | subdirectory of a directory on the {\tt PYTHONPATH}. (And preferably should | |
138 | be named wxPython.) You can control where the build process will dump | |
139 | wxPython by setting the {\tt TARGETDIR} variable for the build utility (see | |
140 | below). | |
141 | ||
142 | \begin{enumerate}\itemsep=0pt | |
143 | \item Build wxWindows as described in its BuildCVS.txt file. For Unix | |
144 | systems I run configure with these flags: | |
145 | ||
146 | \begin{verbatim} | |
147 | --with-gtk | |
148 | --with-libjpeg | |
149 | --without-odbc | |
150 | --enable-unicode=no | |
151 | --enable-threads=yes | |
152 | --enable-socket=yes | |
153 | --enable-static=no | |
154 | --enable-shared=yes | |
155 | --disable-std_iostreams | |
156 | \end{verbatim} | |
157 | ||
158 | You can use whatever flags you want, but I know these work. | |
159 | ||
160 | For Win32 systems I use Visual C++ 6.0, but 5.0 should work also. The | |
161 | build utility currently does not support any other Win32 compilers. | |
162 | \item At this point you may want to make an alias or symlink, script, | |
163 | batch file, whatever on the PATH that invokes {\tt \$(WXWIN)/utils/wxPython/distrib/build.py} to | |
164 | help simplify matters somewhat. For example, on my Win32 system I have a file named | |
165 | {\tt build}.bat in a directory on the PATH that contains: | |
166 | ||
167 | {\tt python \%WXWIN/utils/wxPython/distrib/build.py \%1 \%2 \%3 \%4 \%5 \%6} | |
168 | \item Change into the {\tt \$(WXWIN)/utils/wxPython/src} directory. | |
169 | \item Type "{\tt build -b}" to build wxPython and "{\tt build -i}" to | |
170 | install it, or "{\tt build -bi}" to do both steps at once. | |
171 | ||
172 | The build.py script actually generates a Makefile based on what it | |
173 | finds on your system and information found in the build.cfg file. | |
174 | If you have troubles building or you want it built or installed in | |
175 | a different way, take a look at the docstring in build.py. You are | |
176 | able to to override many configuration options in a file named | |
177 | build.local. | |
178 | \item To build and install the add-on modules, change to the appropriate | |
179 | directory under {\tt \$(WXWIN)/utils/wxPython/modules} and run the build | |
180 | utility again. | |
181 | \item Change to the {\tt \$(WXWIN)/utils/wxPython/demo} directory. | |
182 | \item Try executing the demo program. For example: | |
183 | ||
184 | {\tt python demo.py} | |
185 | ||
186 | To run it without requiring a console on Win32, you can use the | |
187 | {\tt pythonw.exe} version of Python either from the command line or from a | |
188 | shortcut. | |
189 | \end{enumerate} | |
190 | ||
191 | %---------------------------------------------------------------------- | |
192 | \section{Using wxPython}\label{wxpusing} | |
193 | ||
194 | \wxheading{First things first...} | |
195 | ||
196 | I'm not going to try and teach the Python language here. You can do | |
197 | that at the \urlref{Python Tutorial}{http://www.python.org/doc/tut/tut.html}. | |
198 | I'm also going to assume that you know a bit about wxWindows already, | |
199 | enough to notice the similarities in the classes used. | |
200 | ||
201 | Take a look at the following wxPython program. You can find a similar | |
202 | program in the {\tt wxPython/demo} directory, named {\tt DialogUnits.py}. If your | |
203 | Python and wxPython are properly installed, you should be able to run | |
204 | it by issuing this command: | |
205 | ||
206 | \begin{indented}{1cm} | |
207 | {\bf\tt python DialogUnits.py} | |
208 | \end{indented} | |
209 | ||
210 | \hrule | |
211 | ||
212 | \begin{verbatim} | |
213 | 001: ## import all of the wxPython GUI package | |
214 | 002: from wxPython.wx import * | |
215 | 003: | |
216 | 004: ## Create a new frame class, derived from the wxPython Frame. | |
217 | 005: class MyFrame(wxFrame): | |
218 | 006: | |
219 | 007: def __init__(self, parent, id, title): | |
220 | 008: # First, call the base class' __init__ method to create the frame | |
221 | 009: wxFrame.__init__(self, parent, id, title, | |
222 | 010: wxPoint(100, 100), wxSize(160, 100)) | |
223 | 011: | |
224 | 012: # Associate some events with methods of this class | |
225 | 013: EVT_SIZE(self, self.OnSize) | |
226 | 014: EVT_MOVE(self, self.OnMove) | |
227 | 015: | |
228 | 016: # Add a panel and some controls to display the size and position | |
229 | 017: panel = wxPanel(self, -1) | |
230 | 018: wxStaticText(panel, -1, "Size:", | |
231 | 019: wxDLG_PNT(panel, wxPoint(4, 4)), wxDefaultSize) | |
232 | 020: wxStaticText(panel, -1, "Pos:", | |
233 | 021: wxDLG_PNT(panel, wxPoint(4, 14)), wxDefaultSize) | |
234 | 022: self.sizeCtrl = wxTextCtrl(panel, -1, "", | |
235 | 023: wxDLG_PNT(panel, wxPoint(24, 4)), | |
236 | 024: wxDLG_SZE(panel, wxSize(36, -1)), | |
237 | 025: wxTE_READONLY) | |
238 | 026: self.posCtrl = wxTextCtrl(panel, -1, "", | |
239 | 027: wxDLG_PNT(panel, wxPoint(24, 14)), | |
240 | 028: wxDLG_SZE(panel, wxSize(36, -1)), | |
241 | 029: wxTE_READONLY) | |
242 | 030: | |
243 | 031: | |
244 | 032: # This method is called automatically when the CLOSE event is | |
245 | 033: # sent to this window | |
246 | 034: def OnCloseWindow(self, event): | |
247 | 035: # tell the window to kill itself | |
248 | 036: self.Destroy() | |
249 | 037: | |
250 | 038: # This method is called by the system when the window is resized, | |
251 | 039: # because of the association above. | |
252 | 040: def OnSize(self, event): | |
253 | 041: size = event.GetSize() | |
254 | 042: self.sizeCtrl.SetValue("%s, %s" % (size.width, size.height)) | |
255 | 043: | |
256 | 044: # tell the event system to continue looking for an event handler, | |
257 | 045: # so the default handler will get called. | |
258 | 046: event.Skip() | |
259 | 047: | |
260 | 048: # This method is called by the system when the window is moved, | |
261 | 049: # because of the association above. | |
262 | 050: def OnMove(self, event): | |
263 | 051: pos = event.GetPosition() | |
264 | 052: self.posCtrl.SetValue("%s, %s" % (pos.x, pos.y)) | |
265 | 053: | |
266 | 054: | |
267 | 055: # Every wxWindows application must have a class derived from wxApp | |
268 | 056: class MyApp(wxApp): | |
269 | 057: | |
270 | 058: # wxWindows calls this method to initialize the application | |
271 | 059: def OnInit(self): | |
272 | 060: | |
273 | 061: # Create an instance of our customized Frame class | |
274 | 062: frame = MyFrame(NULL, -1, "This is a test") | |
275 | 063: frame.Show(true) | |
276 | 064: | |
277 | 065: # Tell wxWindows that this is our main window | |
278 | 066: self.SetTopWindow(frame) | |
279 | 067: | |
280 | 068: # Return a success flag | |
281 | 069: return true | |
282 | 070: | |
283 | 071: | |
284 | 072: app = MyApp(0) # Create an instance of the application class | |
285 | 073: app.MainLoop() # Tell it to start processing events | |
286 | 074: | |
287 | \end{verbatim} | |
288 | \hrule | |
289 | ||
290 | \wxheading{Things to notice} | |
291 | ||
292 | \begin{enumerate}\itemsep=11pt | |
293 | \item At line 2 the wxPython classes, constants, and etc. are imported | |
294 | into the current module's namespace. If you prefer to reduce | |
295 | namespace pollution you can use "{\tt from wxPython import wx}" and | |
296 | then access all the wxPython identifiers through the wx module, for | |
297 | example, "{\tt wx.wxFrame}". | |
298 | \item At line 13 the frame's sizing and moving events are connected to | |
299 | methods of the class. These helper functions are intended to be like | |
300 | the event table macros that wxWindows employs. But since static event | |
301 | tables are impossible with wxPython, we use helpers that are named the | |
302 | same to dynamically build the table. The only real difference is | |
303 | that the first arguemnt to the event helpers is always the window that | |
304 | the event table entry should be added to. | |
305 | \item Notice the use of {\tt wxDLG\_PNT} and {\tt wxDLG\_SZE} in lines 19 | |
306 | - 29 to convert from dialog units to pixels. These helpers are unique | |
307 | to wxPython since Python can't do method overloading like C++. | |
308 | \item There is an {\tt OnCloseWindow} method at line 34 but no call to | |
309 | EVT\_CLOSE to attach the event to the method. Does it really get | |
310 | called? The answer is, yes it does. This is because many of the | |
311 | {\em standard} events are attached to windows that have the associated | |
312 | {\em standard} method names. I have tried to follow the lead of the | |
313 | C++ classes in this area to determine what is {\em standard} but since | |
314 | that changes from time to time I can make no guarentees, nor will it | |
315 | be fully documented. When in doubt, use an EVT\_*** function. | |
316 | \item At lines 17 to 21 notice that there are no saved references to | |
317 | the panel or the static text items that are created. Those of you | |
318 | who know Python might be wondering what happens when Python deletes | |
319 | these objects when they go out of scope. Do they disappear from the GUI? They | |
320 | don't. Remember that in wxPython the Python objects are just shadows of the | |
321 | coresponding C++ objects. Once the C++ windows and controls are | |
322 | attached to their parents, the parents manage them and delete them | |
323 | when necessary. For this reason, most wxPython objects do not need to | |
324 | have a \_\_del\_\_ method that explicitly causes the C++ object to be | |
325 | deleted. If you ever have the need to forcibly delete a window, use | |
326 | the Destroy() method as shown on line 36. | |
327 | \item Just like wxWindows in C++, wxPython apps need to create a class | |
328 | derived from {\tt wxApp} (line 56) that implements a method named | |
329 | {\tt OnInit}, (line 59.) This method should create the application's | |
330 | main window (line 62) and use {\tt wxApp.SetTopWindow()} (line 66) to | |
331 | inform wxWindows about it. | |
332 | \item And finally, at line 72 an instance of the application class is | |
333 | created. At this point wxPython finishes initializing itself, and calls | |
334 | the {\tt OnInit} method to get things started. (The zero parameter here is | |
335 | a flag for functionality that isn't quite implemented yet. Just | |
336 | ignore it for now.) The call to {\tt MainLoop} at line 73 starts the event | |
337 | loop which continues until the application terminates or all the top | |
338 | level windows are closed. | |
339 | \end{enumerate} | |
340 | ||
341 | %---------------------------------------------------------------------- | |
342 | \section{wxWindows classes implemented in wxPython}\label{wxpclasses} | |
343 | ||
344 | The following classes are supported in wxPython. Most provide nearly | |
345 | full implementations of the public interfaces specified in the C++ | |
346 | documentation, others are less so. They will all be brought as close | |
347 | as possible to the C++ spec over time. | |
348 | ||
349 | \begin{itemize}\itemsep=0pt | |
350 | \item \helpref{wxAcceleratorEntry}{wxacceleratorentry} | |
351 | \item \helpref{wxAcceleratorTable}{wxacceleratortable} | |
352 | \item \helpref{wxActivateEvent}{wxactivateevent} | |
353 | \item \helpref{wxBitmap}{wxbitmap} | |
354 | \item \helpref{wxBitmapButton}{wxbitmapbutton} | |
355 | \item \helpref{wxBitmapDataObject}{wxbitmapdataobject} | |
356 | \item wxBMPHandler | |
357 | \item \helpref{wxBoxSizer}{wxboxsizer} | |
358 | \item \helpref{wxBrush}{wxbrush} | |
359 | \item \helpref{wxBusyInfo}{wxbusyinfo} | |
360 | \item \helpref{wxBusyCursor}{wxbusycursor} | |
361 | \item \helpref{wxButton}{wxbutton} | |
362 | \item \helpref{wxCalculateLayoutEvent}{wxcalculatelayoutevent} | |
363 | \item wxCaret | |
364 | \item \helpref{wxCheckBox}{wxcheckbox} | |
365 | \item \helpref{wxCheckListBox}{wxchecklistbox} | |
366 | \item \helpref{wxChoice}{wxchoice} | |
367 | \item \helpref{wxClientDC}{wxclientdc} | |
368 | \item \helpref{wxClipboard}{wxclipboard} | |
369 | \item \helpref{wxCloseEvent}{wxcloseevent} | |
370 | \item \helpref{wxColourData}{wxcolourdata} | |
371 | \item \helpref{wxColourDialog}{wxcolourdialog} | |
372 | \item \helpref{wxColour}{wxcolour} | |
373 | \item \helpref{wxComboBox}{wxcombobox} | |
374 | \item \helpref{wxCommandEvent}{wxcommandevent} | |
375 | \item \helpref{wxConfig}{wxconfigbase} | |
376 | \item \helpref{wxControl}{wxcontrol} | |
377 | \item \helpref{wxCursor}{wxcursor} | |
378 | \item \helpref{wxCustomDataObject}{wxcustomdataobject} | |
379 | \item \helpref{wxDataFormat}{wxdataformat} | |
380 | \item \helpref{wxDataObject}{wxdataobject} | |
381 | \item \helpref{wxDataObjectComposite}{wxdataobjectcomposite} | |
382 | \item \helpref{wxDataObjectSimple}{wxdataobjectsimple} | |
383 | \item \helpref{wxDC}{wxdc} | |
384 | \item \helpref{wxDialog}{wxdialog} | |
385 | \item \helpref{wxDirDialog}{wxdirdialog} | |
386 | \item \helpref{wxDropFilesEvent}{wxdropfilesevent} | |
387 | \item \helpref{wxDropSource}{wxdropsource} | |
388 | \item \helpref{wxDropTarget}{wxdroptarget} | |
389 | \item \helpref{wxEraseEvent}{wxeraseevent} | |
390 | \item \helpref{wxEvent}{wxevent} | |
391 | \item \helpref{wxEvtHandler}{wxevthandler} | |
392 | \item \helpref{wxFileDataObject}{wxfiledataobject} | |
393 | \item \helpref{wxFileDialog}{wxfiledialog} | |
394 | \item \helpref{wxFileDropTarget}{wxfiledroptarget} | |
395 | \item \helpref{wxFocusEvent}{wxfocusevent} | |
396 | \item \helpref{wxFontData}{wxfontdata} | |
397 | \item \helpref{wxFontDialog}{wxfontdialog} | |
398 | \item \helpref{wxFont}{wxfont} | |
399 | \item \helpref{wxFrame}{wxframe} | |
400 | \item \helpref{wxGauge}{wxgauge} | |
401 | \item wxGIFHandler | |
402 | \item wxGLCanvas | |
403 | \item wxGridCell | |
404 | \item wxGridEvent | |
405 | \item \helpref{wxGrid}{wxgrid} | |
406 | \item \helpref{wxHtmlCell}{wxhtmlcell} | |
407 | \item \helpref{wxHtmlContainerCell}{wxhtmlcontainercell} | |
408 | \item \helpref{wxHtmlDCRenderer}{wxhtmldcrenderer} | |
409 | \item \helpref{wxHtmlEasyPrinting}{wxhtmleasyprinting} | |
410 | \item \helpref{wxHtmlParser}{wxhtmlparser} | |
411 | \item \helpref{wxHtmlTagHandler}{wxhtmltaghandler} | |
412 | \item \helpref{wxHtmlTag}{wxhtmltag} | |
413 | \item \helpref{wxHtmlWinParser}{wxhtmlwinparser} | |
414 | \item \helpref{wxHtmlPrintout}{wxhtmlprintout} | |
415 | \item \helpref{wxHtmlWinTagHandler}{wxhtmlwintaghandler} | |
416 | \item \helpref{wxHtmlWindow}{wxhtmlwindow} | |
417 | \item wxIconizeEvent | |
418 | \item \helpref{wxIcon}{wxicon} | |
419 | \item \helpref{wxIdleEvent}{wxidleevent} | |
420 | \item \helpref{wxImage}{wximage} | |
421 | \item \helpref{wxImageHandler}{wximagehandler} | |
422 | \item \helpref{wxImageList}{wximagelist} | |
423 | \item \helpref{wxIndividualLayoutConstraint}{wxindividuallayoutconstraint} | |
424 | \item \helpref{wxInitDialogEvent}{wxinitdialogevent} | |
425 | \item \helpref{wxJoystickEvent}{wxjoystickevent} | |
426 | \item wxJPEGHandler | |
427 | \item \helpref{wxKeyEvent}{wxkeyevent} | |
428 | \item \helpref{wxLayoutAlgorithm}{wxlayoutalgorithm} | |
429 | \item \helpref{wxLayoutConstraints}{wxlayoutconstraints} | |
430 | \item \helpref{wxListBox}{wxlistbox} | |
431 | \item \helpref{wxListCtrl}{wxlistctrl} | |
432 | \item \helpref{wxListEvent}{wxlistevent} | |
433 | \item \helpref{wxListItem}{wxlistctrlsetitem} | |
434 | \item \helpref{wxMDIChildFrame}{wxmdichildframe} | |
435 | \item \helpref{wxMDIClientWindow}{wxmdiclientwindow} | |
436 | \item \helpref{wxMDIParentFrame}{wxmdiparentframe} | |
437 | \item \helpref{wxMask}{wxmask} | |
438 | \item wxMaximizeEvent | |
439 | \item \helpref{wxMemoryDC}{wxmemorydc} | |
440 | \item \helpref{wxMenuBar}{wxmenubar} | |
441 | \item \helpref{wxMenuEvent}{wxmenuevent} | |
442 | \item \helpref{wxMenuItem}{wxmenuitem} | |
443 | \item \helpref{wxMenu}{wxmenu} | |
444 | \item \helpref{wxMessageDialog}{wxmessagedialog} | |
445 | \item \helpref{wxMetaFileDC}{wxmetafiledc} | |
446 | \item \helpref{wxMiniFrame}{wxminiframe} | |
447 | \item \helpref{wxMouseEvent}{wxmouseevent} | |
448 | \item \helpref{wxMoveEvent}{wxmoveevent} | |
449 | \item \helpref{wxNotebookEvent}{wxnotebookevent} | |
450 | \item \helpref{wxNotebook}{wxnotebook} | |
451 | \item \helpref{wxPageSetupDialogData}{wxpagesetupdialogdata} | |
452 | \item \helpref{wxPageSetupDialog}{wxpagesetupdialog} | |
453 | \item \helpref{wxPaintDC}{wxpaintdc} | |
454 | \item \helpref{wxPaintEvent}{wxpaintevent} | |
455 | \item \helpref{wxPalette}{wxpalette} | |
456 | \item \helpref{wxPanel}{wxpanel} | |
457 | \item \helpref{wxPen}{wxpen} | |
458 | \item wxPNGHandler | |
459 | \item \helpref{wxPoint}{wxpoint} | |
460 | \item \helpref{wxPostScriptDC}{wxpostscriptdc} | |
461 | \item \helpref{wxPreviewFrame}{wxpreviewframe} | |
462 | \item \helpref{wxPrintData}{wxprintdata} | |
463 | \item \helpref{wxPrintDialogData}{wxprintdialogdata} | |
464 | \item \helpref{wxPrintDialog}{wxprintdialog} | |
465 | \item \helpref{wxPrinter}{wxprinter} | |
466 | \item \helpref{wxPrintPreview}{wxprintpreview} | |
467 | \item \helpref{wxPrinterDC}{wxprinterdc} | |
468 | \item \helpref{wxPrintout}{wxprintout} | |
469 | \item \helpref{wxQueryLayoutInfoEvent}{wxquerylayoutinfoevent} | |
470 | \item \helpref{wxRadioBox}{wxradiobox} | |
471 | \item \helpref{wxRadioButton}{wxradiobutton} | |
472 | \item \helpref{wxRealPoint}{wxrealpoint} | |
473 | \item \helpref{wxRect}{wxrect} | |
474 | \item \helpref{wxRegionIterator}{wxregioniterator} | |
475 | \item \helpref{wxRegion}{wxregion} | |
476 | \item \helpref{wxSashEvent}{wxsashevent} | |
477 | \item \helpref{wxSashLayoutWindow}{wxsashlayoutwindow} | |
478 | \item \helpref{wxSashWindow}{wxsashwindow} | |
479 | \item \helpref{wxScreenDC}{wxscreendc} | |
480 | \item \helpref{wxScrollBar}{wxscrollbar} | |
481 | \item \helpref{wxScrollEvent}{wxscrollevent} | |
482 | \item \helpref{wxScrolledWindow}{wxscrolledwindow} | |
483 | \item \helpref{wxScrollWinEvent}{wxscrollwinevent} | |
484 | \item wxShowEvent | |
485 | \item \helpref{wxSingleChoiceDialog}{wxsinglechoicedialog} | |
486 | \item \helpref{wxSizeEvent}{wxsizeevent} | |
487 | \item \helpref{wxSize}{wxsize} | |
488 | \item \helpref{wxSizer}{wxsizer} | |
489 | \item wxSizerItem | |
490 | \item \helpref{wxSlider}{wxslider} | |
491 | \item \helpref{wxSpinButton}{wxspinbutton} | |
492 | \item wxSpinEvent | |
493 | \item \helpref{wxSplitterWindow}{wxsplitterwindow} | |
494 | \item \helpref{wxStaticBitmap}{wxstaticbitmap} | |
495 | \item \helpref{wxStaticBox}{wxstaticbox} | |
496 | \item \helpref{wxStaticBoxSizer}{wxstaticboxsizer} | |
497 | \item \helpref{wxStaticLine}{wxstaticline} | |
498 | \item \helpref{wxStaticText}{wxstatictext} | |
499 | \item \helpref{wxStatusBar}{wxstatusbar} | |
500 | \item \helpref{wxSysColourChangedEvent}{wxsyscolourchangedevent} | |
501 | \item \helpref{wxTaskBarIcon}{wxtaskbaricon} | |
502 | \item \helpref{wxTextCtrl}{wxtextctrl} | |
503 | \item \helpref{wxTextDataObject}{wxtextdataobject} | |
504 | \item \helpref{wxTextDropTarget}{wxtextdroptarget} | |
505 | \item \helpref{wxTextEntryDialog}{wxtextentrydialog} | |
506 | \item \helpref{wxTimer}{wxtimer} | |
507 | \item wxToolBarTool | |
508 | \item \helpref{wxToolBar}{wxtoolbar} | |
509 | \item wxToolTip | |
510 | \item \helpref{wxTreeCtrl}{wxtreectrl} | |
511 | \item \helpref{wxTreeEvent}{wxtreeevent} | |
512 | \item \helpref{wxTreeItemData}{wxtreeitemdata} | |
513 | \item wxTreeItemId | |
514 | \item \helpref{wxUpdateUIEvent}{wxupdateuievent} | |
515 | \item \helpref{wxValidator}{wxvalidator} | |
516 | \item \helpref{wxWindowDC}{wxwindowdc} | |
517 | \item \helpref{wxWindow}{wxwindow} | |
518 | \end{itemize} | |
519 | ||
520 | %---------------------------------------------------------------------- | |
521 | \section{Where to go for help}\label{wxphelp} | |
522 | ||
523 | Since wxPython is a blending of multiple technologies, help comes from | |
524 | multiple sources. See | |
525 | \urlref{http://alldunn.com/wxPython}{http://alldunn.com/wxPython} for details on | |
526 | various sources of help, but probably the best source is the | |
527 | wxPython-users mail list. You can view the archive or subscribe by | |
528 | going to | |
529 | ||
530 | \urlref{http://starship.python.net/mailman/listinfo/wxpython-users}{http://starship.python.net/mailman/listinfo/wxpython-users} | |
531 | ||
532 | Or you can send mail directly to the list using this address: | |
533 | ||
534 | wxpython-users@starship.python.net | |
535 |