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