]>
Commit | Line | Data |
---|---|---|
1 | \chapter{wxPython Notes}\label{wxPython} | |
2 | \pagenumbering{arabic}% | |
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 | ||
163 | \item At this point you may want to make an alias or symlink, script, | |
164 | batch file, whatever on the PATH that invokes \tt{\$(WXWIN)/utils/wxPython/distrib/build.py} to | |
165 | help simplify matters somewhat. For example, on my Win32 system I have a file named | |
166 | \tt{build}.bat in a directory on the PATH that contains: | |
167 | ||
168 | \tt{python \%WXWIN/utils/wxPython/distrib/build.py \%1 \%2 \%3 \%4 \%5 \%6} | |
169 | ||
170 | \item Change into the \tt{\$(WXWIN)/utils/wxPython/src} directory. | |
171 | ||
172 | \item Type "\tt{build -b}" to build wxPython and "\tt{build -i}" to | |
173 | install it, or "\tt{build -bi}" to do both steps at once. | |
174 | ||
175 | The build.py script actually generates a Makefile based on what it | |
176 | finds on your system and information found in the build.cfg file. | |
177 | If you have troubles building or you want it built or installed in | |
178 | a different way, take a look at the docstring in build.py. You are | |
179 | able to to override many configuration options in a file named | |
180 | build.local. | |
181 | ||
182 | \item To build and install the add-on modules, change to the appropriate | |
183 | directory under \tt{\$(WXWIN)/utils/wxPython/modules} and run the build | |
184 | utility again. | |
185 | ||
186 | \item Change to the \tt{\$(WXWIN)/utils/wxPython/demo} directory. | |
187 | ||
188 | \item Try executing the demo program. For example: | |
189 | ||
190 | \tt{python demo.py} | |
191 | ||
192 | To run it without requiring a console on Win32, you can use the | |
193 | \tt{pythonw.exe} version of Python either from the command line or from a | |
194 | shortcut. | |
195 | \end{enumerate} | |
196 | ||
197 | %---------------------------------------------------------------------- | |
198 | \section{Using wxPython}\label{wxpusing} | |
199 | ||
200 | \wxheading{First things first...} | |
201 | ||
202 | I'm not going to try and teach the Python language here. You can do | |
203 | that at the \urlref{Python Tutorial}{http://www.python.org/doc/tut/tut.html}. | |
204 | I'm also going to assume that you know a bit about wxWindows already, | |
205 | enough to notice the similarities in the classes used. | |
206 | ||
207 | Take a look at the following wxPython program. You can find a similar | |
208 | program in the \tt{wxPython/demo} directory, named \tt{DialogUnits.py}. If your | |
209 | Python and wxPython are properly installed, you should be able to run | |
210 | it by issuing this command: | |
211 | ||
212 | \begin{indented}{1cm} | |
213 | \bftt{python DialogUnits.py} | |
214 | \end{indented} | |
215 | ||
216 | \hrule | |
217 | ||
218 | \begin{verbatim} | |
219 | 001: ## import all of the wxPython GUI package | |
220 | 002: from wxPython.wx import * | |
221 | 003: | |
222 | 004: ## Create a new frame class, derived from the wxPython Frame. | |
223 | 005: class MyFrame(wxFrame): | |
224 | 006: | |
225 | 007: def __init__(self, parent, id, title): | |
226 | 008: # First, call the base class' __init__ method to create the frame | |
227 | 009: wxFrame.__init__(self, parent, id, title, | |
228 | 010: wxPoint(100, 100), wxSize(160, 100)) | |
229 | 011: | |
230 | 012: # Associate some events with methods of this class | |
231 | 013: EVT_SIZE(self, self.OnSize) | |
232 | 014: EVT_MOVE(self, self.OnMove) | |
233 | 015: | |
234 | 016: # Add a panel and some controls to display the size and position | |
235 | 017: panel = wxPanel(self, -1) | |
236 | 018: wxStaticText(panel, -1, "Size:", | |
237 | 019: wxDLG_PNT(panel, wxPoint(4, 4)), wxDefaultSize) | |
238 | 020: wxStaticText(panel, -1, "Pos:", | |
239 | 021: wxDLG_PNT(panel, wxPoint(4, 14)), wxDefaultSize) | |
240 | 022: self.sizeCtrl = wxTextCtrl(panel, -1, "", | |
241 | 023: wxDLG_PNT(panel, wxPoint(24, 4)), | |
242 | 024: wxDLG_SZE(panel, wxSize(36, -1)), | |
243 | 025: wxTE_READONLY) | |
244 | 026: self.posCtrl = wxTextCtrl(panel, -1, "", | |
245 | 027: wxDLG_PNT(panel, wxPoint(24, 14)), | |
246 | 028: wxDLG_SZE(panel, wxSize(36, -1)), | |
247 | 029: wxTE_READONLY) | |
248 | 030: | |
249 | 031: | |
250 | 032: # This method is called automatically when the CLOSE event is | |
251 | 033: # sent to this window | |
252 | 034: def OnCloseWindow(self, event): | |
253 | 035: # tell the window to kill itself | |
254 | 036: self.Destroy() | |
255 | 037: | |
256 | 038: # This method is called by the system when the window is resized, | |
257 | 039: # because of the association above. | |
258 | 040: def OnSize(self, event): | |
259 | 041: size = event.GetSize() | |
260 | 042: self.sizeCtrl.SetValue("%s, %s" % (size.width, size.height)) | |
261 | 043: | |
262 | 044: # tell the event system to continue looking for an event handler, | |
263 | 045: # so the default handler will get called. | |
264 | 046: event.Skip() | |
265 | 047: | |
266 | 048: # This method is called by the system when the window is moved, | |
267 | 049: # because of the association above. | |
268 | 050: def OnMove(self, event): | |
269 | 051: pos = event.GetPosition() | |
270 | 052: self.posCtrl.SetValue("%s, %s" % (pos.x, pos.y)) | |
271 | 053: | |
272 | 054: | |
273 | 055: # Every wxWindows application must have a class derived from wxApp | |
274 | 056: class MyApp(wxApp): | |
275 | 057: | |
276 | 058: # wxWindows calls this method to initialize the application | |
277 | 059: def OnInit(self): | |
278 | 060: | |
279 | 061: # Create an instance of our customized Frame class | |
280 | 062: frame = MyFrame(NULL, -1, "This is a test") | |
281 | 063: frame.Show(true) | |
282 | 064: | |
283 | 065: # Tell wxWindows that this is our main window | |
284 | 066: self.SetTopWindow(frame) | |
285 | 067: | |
286 | 068: # Return a success flag | |
287 | 069: return true | |
288 | 070: | |
289 | 071: | |
290 | 072: app = MyApp(0) # Create an instance of the application class | |
291 | 073: app.MainLoop() # Tell it to start processing events | |
292 | 074: | |
293 | \end{verbatim} | |
294 | \hrule | |
295 | ||
296 | \wxheading{Things to notice} | |
297 | ||
298 | \begin{enumerate}\itemsep=0pt | |
299 | \item At line 2 the wxPython classes, constants, and etc. are imported | |
300 | into the current module's namespace. If you prefer to reduce | |
301 | namespace pollution you can use "\tt{from wxPython import wx}" and | |
302 | then access all the wxPython identifiers through the wx module, for | |
303 | example, "\tt{wx.wxFrame}". | |
304 | ||
305 | \item At line 13 the frame's sizing and moving events are connected to | |
306 | methods of the class. These helper functions are intended to be like | |
307 | the event table macros that wxWindows employs. But since static event | |
308 | tables are impossible with wxPython, we use helpers that are named the | |
309 | same to dynamically build the table. The only real difference is | |
310 | that the first arguemnt to the event helpers is always the window that | |
311 | the event table entry should be added to. | |
312 | ||
313 | \item Notice the use of \tt{wxDLG\_PNT} and \tt{wxDLG\_SZE} in lines 19 | |
314 | - 29 to convert from dialog units to pixels. These helpers are unique | |
315 | to wxPython since Python can't do method overloading like C++. | |
316 | ||
317 | \item There is an \tt{OnCloseWindow} method at line 34 but no call to | |
318 | EVT\_CLOSE to attach the event to the method. Does it really get | |
319 | called? The answer is, yes it does. This is because many of the | |
320 | \em{standard} events are attached to windows that have the associated | |
321 | \em{standard} method names. I have tried to follow the lead of the | |
322 | C++ classes in this area to determine what is \em{standard} but since | |
323 | that changes from time to time I can make no guarentees, nor will it | |
324 | be fully documented. When in doubt, use an EVT\_*** function. | |
325 | ||
326 | \item At lines 17 to 21 notice that there are no saved references to | |
327 | the panel or the static text items that are created. Those of you | |
328 | who know Python might be wondering what happens when Python deletes | |
329 | these objects when they go out of scope. Do they disappear from the GUI? They | |
330 | don't. Remember that in wxPython the Python objects are just shadows of the | |
331 | coresponding C++ objects. Once the C++ windows and controls are | |
332 | attached to their parents, the parents manage them and delete them | |
333 | when necessary. For this reason, most wxPython objects do not need to | |
334 | have a \_\_del\_\_ method that explicitly causes the C++ object to be | |
335 | deleted. If you ever have the need to forcibly delete a window, use | |
336 | the Destroy() method as shown on line 36. | |
337 | ||
338 | \item Just like wxWindows in C++, wxPython apps need to create a class | |
339 | derived from \tt{wxApp} (line 56) that implements a method named | |
340 | \tt{OnInit}, (line 59.) This method should create the application's | |
341 | main window (line 62) and use \tt{wxApp.SetTopWindow()} (line 66) to | |
342 | inform wxWindows about it. | |
343 | ||
344 | \item And finally, at line 72 an instance of the application class is | |
345 | created. At this point wxPython finishes initializing itself, and calls | |
346 | the \tt{OnInit} method to get things started. (The zero parameter here is | |
347 | a flag for functionality that isn't quite implemented yet. Just | |
348 | ignore it for now.) The call to \tt{MainLoop} at line 73 starts the event | |
349 | loop which continues until the application terminates or all the top | |
350 | level windows are closed. | |
351 | \end{enumerate} | |
352 | ||
353 | %---------------------------------------------------------------------- | |
354 | \section{wxWindows classes implemented in wxPython}\label{wxpclasses} | |
355 | ||
356 | The following classes are supported in wxPython. Most provide nearly | |
357 | full implementations of the public interfaces specified in the C++ | |
358 | documentation, others are less so. They will all be brought as close | |
359 | as possible to the C++ spec over time. | |
360 | ||
361 | \begin{itemize}\itemsep=0pt | |
362 | \item \helpref{wxAcceleratorEntry}{wxacceleratorentry} | |
363 | \item \helpref{wxAcceleratorTable}{wxacceleratortable} | |
364 | \item \helpref{wxActivateEvent}{wxactivateevent} | |
365 | \item \helpref{wxBitmapButton}{wxbitmapbutton} | |
366 | \item \helpref{wxBitmap}{wxbitmap} | |
367 | \item wxBMPHandler | |
368 | \item \helpref{wxBoxSizer}{wxboxsizer} | |
369 | \item \helpref{wxBrush}{wxbrush} | |
370 | \item \helpref{wxBusyInfo}{wxbusyinfo} | |
371 | \item \helpref{wxBusyCursor}{wxbusycursor} | |
372 | \item \helpref{wxButton}{wxbutton} | |
373 | \item \helpref{wxCalculateLayoutEvent}{wxcalculatelayoutevent} | |
374 | \item wxCaret | |
375 | \item \helpref{wxCheckBox}{wxcheckbox} | |
376 | \item \helpref{wxCheckListBox}{wxchecklistbox} | |
377 | \item \helpref{wxChoice}{wxchoice} | |
378 | \item \helpref{wxClientDC}{wxclientdc} | |
379 | \item \helpref{wxCloseEvent}{wxcloseevent} | |
380 | \item \helpref{wxColourData}{wxcolourdata} | |
381 | \item \helpref{wxColourDialog}{wxcolourdialog} | |
382 | \item \helpref{wxColour}{wxcolour} | |
383 | \item \helpref{wxComboBox}{wxcombobox} | |
384 | \item \helpref{wxCommandEvent}{wxcommandevent} | |
385 | \item \helpref{wxConfig}{wxconfigbase} | |
386 | \item \helpref{wxControl}{wxcontrol} | |
387 | \item \helpref{wxCursor}{wxcursor} | |
388 | \item \helpref{wxDC}{wxdc} | |
389 | \item \helpref{wxDialog}{wxdialog} | |
390 | \item \helpref{wxDirDialog}{wxdirdialog} | |
391 | \item \helpref{wxDropFilesEvent}{wxdropfilesevent} | |
392 | \item \helpref{wxEraseEvent}{wxeraseevent} | |
393 | \item \helpref{wxEvent}{wxevent} | |
394 | \item \helpref{wxEvtHandler}{wxevthandler} | |
395 | \item \helpref{wxFileDialog}{wxfiledialog} | |
396 | \item \helpref{wxFocusEvent}{wxfocusevent} | |
397 | \item \helpref{wxFontData}{wxfontdata} | |
398 | \item \helpref{wxFontDialog}{wxfontdialog} | |
399 | \item \helpref{wxFont}{wxfont} | |
400 | \item \helpref{wxFrame}{wxframe} | |
401 | \item \helpref{wxGauge}{wxgauge} | |
402 | \item wxGIFHandler | |
403 | \item wxGLCanvas | |
404 | \item wxGridCell | |
405 | \item wxGridEvent | |
406 | \item \helpref{wxGrid}{wxgrid} | |
407 | \item \helpref{wxHtmlCell}{wxhtmlcell} | |
408 | \item \helpref{wxHtmlContainerCell}{wxhtmlcontainercell} | |
409 | \item \helpref{wxHtmlDCRenderer}{wxhtmldcrenderer} | |
410 | \item \helpref{wxHtmlEasyPrinting}{wxhtmleasyprinting} | |
411 | \item \helpref{wxHtmlParser}{wxhtmlparser} | |
412 | \item \helpref{wxHtmlTagHandler}{wxhtmltaghandler} | |
413 | \item \helpref{wxHtmlTag}{wxhtmltag} | |
414 | \item \helpref{wxHtmlWinParser}{wxhtmlwinparser} | |
415 | \item \helpref{wxHtmlPrintout}{wxhtmlprintout} | |
416 | \item \helpref{wxHtmlWinTagHandler}{wxhtmlwintaghandler} | |
417 | \item \helpref{wxHtmlWindow}{wxhtmlwindow} | |
418 | \item wxIconizeEvent | |
419 | \item \helpref{wxIcon}{wxicon} | |
420 | \item \helpref{wxIdleEvent}{wxidleevent} | |
421 | \item \helpref{wxImage}{wximage} | |
422 | \item \helpref{wxImageHandler}{wximagehandler} | |
423 | \item \helpref{wxImageList}{wximagelist} | |
424 | \item \helpref{wxIndividualLayoutConstraint}{wxindividuallayoutconstraint} | |
425 | \item \helpref{wxInitDialogEvent}{wxinitdialogevent} | |
426 | \item \helpref{wxJoystickEvent}{wxjoystickevent} | |
427 | \item wxJPEGHandler | |
428 | \item \helpref{wxKeyEvent}{wxkeyevent} | |
429 | \item \helpref{wxLayoutAlgorithm}{wxlayoutalgorithm} | |
430 | \item \helpref{wxLayoutConstraints}{wxlayoutconstraints} | |
431 | \item \helpref{wxListBox}{wxlistbox} | |
432 | \item \helpref{wxListCtrl}{wxlistctrl} | |
433 | \item \helpref{wxListEvent}{wxlistevent} | |
434 | \item \helpref{wxListItem}{wxlistctrlsetitem} | |
435 | \item \helpref{wxMDIChildFrame}{wxmdichildframe} | |
436 | \item \helpref{wxMDIClientWindow}{wxmdiclientwindow} | |
437 | \item \helpref{wxMDIParentFrame}{wxmdiparentframe} | |
438 | \item \helpref{wxMask}{wxmask} | |
439 | \item wxMaximizeEvent | |
440 | \item \helpref{wxMemoryDC}{wxmemorydc} | |
441 | \item \helpref{wxMenuBar}{wxmenubar} | |
442 | \item \helpref{wxMenuEvent}{wxmenuevent} | |
443 | \item \helpref{wxMenuItem}{wxmenuitem} | |
444 | \item \helpref{wxMenu}{wxmenu} | |
445 | \item \helpref{wxMessageDialog}{wxmessagedialog} | |
446 | \item \helpref{wxMetaFileDC}{wxmetafiledc} | |
447 | \item \helpref{wxMiniFrame}{wxminiframe} | |
448 | \item \helpref{wxMouseEvent}{wxmouseevent} | |
449 | \item \helpref{wxMoveEvent}{wxmoveevent} | |
450 | \item \helpref{wxNotebookEvent}{wxnotebookevent} | |
451 | \item \helpref{wxNotebook}{wxnotebook} | |
452 | \item \helpref{wxPageSetupDialogData}{wxpagesetupdialogdata} | |
453 | \item \helpref{wxPageSetupDialog}{wxpagesetupdialog} | |
454 | \item \helpref{wxPaintDC}{wxpaintdc} | |
455 | \item \helpref{wxPaintEvent}{wxpaintevent} | |
456 | \item \helpref{wxPalette}{wxpalette} | |
457 | \item \helpref{wxPanel}{wxpanel} | |
458 | \item \helpref{wxPen}{wxpen} | |
459 | \item wxPNGHandler | |
460 | \item \helpref{wxPoint}{wxpoint} | |
461 | \item \helpref{wxPostScriptDC}{wxpostscriptdc} | |
462 | \item \helpref{wxPreviewFrame}{wxpreviewframe} | |
463 | \item \helpref{wxPrintData}{wxprintdata} | |
464 | \item \helpref{wxPrintDialogData}{wxprintdialogdata} | |
465 | \item \helpref{wxPrintDialog}{wxprintdialog} | |
466 | \item \helpref{wxPrinter}{wxprinter} | |
467 | \item \helpref{wxPrintPreview}{wxprintpreview} | |
468 | \item \helpref{wxPrinterDC}{wxprinterdc} | |
469 | \item \helpref{wxPrintout}{wxprintout} | |
470 | \item \helpref{wxQueryLayoutInfoEvent}{wxquerylayoutinfoevent} | |
471 | \item \helpref{wxRadioBox}{wxradiobox} | |
472 | \item \helpref{wxRadioButton}{wxradiobutton} | |
473 | \item \helpref{wxRealPoint}{wxrealpoint} | |
474 | \item \helpref{wxRect}{wxrect} | |
475 | \item \helpref{wxRegionIterator}{wxregioniterator} | |
476 | \item \helpref{wxRegion}{wxregion} | |
477 | \item \helpref{wxSashEvent}{wxsashevent} | |
478 | \item \helpref{wxSashLayoutWindow}{wxsashlayoutwindow} | |
479 | \item \helpref{wxSashWindow}{wxsashwindow} | |
480 | \item \helpref{wxScreenDC}{wxscreendc} | |
481 | \item \helpref{wxScrollBar}{wxscrollbar} | |
482 | \item \helpref{wxScrollEvent}{wxscrollevent} | |
483 | \item \helpref{wxScrolledWindow}{wxscrolledwindow} | |
484 | \item \helpref{wxScrollWinEvent}{wxscrollwinevent} | |
485 | \item wxShowEvent | |
486 | \item \helpref{wxSingleChoiceDialog}{wxsinglechoicedialog} | |
487 | \item \helpref{wxSizeEvent}{wxsizeevent} | |
488 | \item \helpref{wxSize}{wxsize} | |
489 | \item \helpref{wxSizer}{wxsizer} | |
490 | \item wxSizerItem | |
491 | \item \helpref{wxSlider}{wxslider} | |
492 | \item \helpref{wxSpinButton}{wxspinbutton} | |
493 | \item wxSpinEvent | |
494 | \item \helpref{wxSplitterWindow}{wxsplitterwindow} | |
495 | \item \helpref{wxStaticBitmap}{wxstaticbitmap} | |
496 | \item \helpref{wxStaticBox}{wxstaticbox} | |
497 | \item \helpref{wxStaticBoxSizer}{wxstaticboxsizer} | |
498 | \item wxStaticLine | |
499 | \item \helpref{wxStaticText}{wxstatictext} | |
500 | \item \helpref{wxStatusBar}{wxstatusbar} | |
501 | \item \helpref{wxSysColourChangedEvent}{wxsyscolourchangedevent} | |
502 | \item \helpref{wxTaskBarIcon}{wxtaskbaricon} | |
503 | \item \helpref{wxTextCtrl}{wxtextctrl} | |
504 | \item \helpref{wxTextEntryDialog}{wxtextentrydialog} | |
505 | \item \helpref{wxTimer}{wxtimer} | |
506 | \item wxToolBarTool | |
507 | \item \helpref{wxToolBar}{wxtoolbar} | |
508 | \item wxToolTip | |
509 | \item \helpref{wxTreeCtrl}{wxtreectrl} | |
510 | \item \helpref{wxTreeEvent}{wxtreeevent} | |
511 | \item \helpref{wxTreeItemData}{wxtreeitemdata} | |
512 | \item wxTreeItemId | |
513 | \item \helpref{wxUpdateUIEvent}{wxupdateuievent} | |
514 | \item \helpref{wxValidator}{wxvalidator} | |
515 | \item \helpref{wxWindowDC}{wxwindowdc} | |
516 | \item \helpref{wxWindow}{wxwindow} | |
517 | ||
518 | ||
519 | ||
520 | \end{itemize} | |
521 | ||
522 | %---------------------------------------------------------------------- | |
523 | \section{Where to go for help}\label{wxphelp} | |
524 | ||
525 | Since wxPython is a blending of multiple technologies, help comes from | |
526 | multiple sources. See | |
527 | \urlref{http://alldunn.com/wxPython}{http://alldunn.com/wxPython} for details on | |
528 | various sources of help, but probably the best source is the | |
529 | wxPython-users mail list. You can view the archive or subscribe by | |
530 | going to | |
531 | ||
532 | \urlref{http://starship.python.net/mailman/listinfo/wxpython-users}{http://starship.python.net/mailman/listinfo/wxpython-users} | |
533 | ||
534 | Or you can send mail directly to the list using this address: | |
535 | ||
536 | wxpython-users@starship.python.net | |
537 |