]> git.saurik.com Git - wxWidgets.git/blob - wxPython/samples/embedded/README.txt
wxBrushBase between wxBrush and wxGDIObject (class follows wxFontBase model).
[wxWidgets.git] / wxPython / samples / embedded / README.txt
1 This sample shows how to embed wxPython into a wxWidgets application.
2 There are a few little tricks needed to make it work, but once over
3 the hurdle it should work just fine for you. I'll try to describe the
4 build issues here, see the code and comments in embedded.cpp for
5 examples of how to use it.
6
7 1. The most important thing is that your wx application and wxPython
8 must use the same version and the same instance of wxWidgets. That
9 means that you can not statically link your app with wxWidgets, but
10 must use a dynamic library for wxWidgets.
11
12 2. You must ensure that your app and wxPython are using the same
13 wxWidgets DLL. By default on MSW wxPython installs the wxWidgets
14 DLL to a directory not on the PATH, so you may have to do something
15 creative to make that happen. But because of #3 this may not be
16 that big of a problem.
17
18 3. wxPython, your app and wxWidgets must be built with the same flags
19 and settings. This probably means that you will need to rebuild
20 wxPython yourself. I do distribute the setup.h, other headers,
21 import libs and etc. that I use, but you'll need to rebuild
22 everything yourself anyway to get debugger versions so I'm not too
23 worried about it just yet. BTW, on MSW if you do debug builds of
24 your app and wxPython then you will need to have a debug version of
25 Python built too since it expects to have extension modules in
26 files with a _d in the name. If you do a hybrid build then you
27 will be able to use the stock version of Python, but you won't be
28 able to trace through the PYTHON API functions.
29
30 4. I expect that most of these issues will be much more minor on
31 Unix. ;-)
32