]>
Commit | Line | Data |
---|---|---|
1 | This sample shows how to embed wxPython into a wxWindows 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 wxWindows. That | |
9 | means that you can not statically link your app with wxWindows, but | |
10 | must use a dynamic library for wxWindows. | |
11 | ||
12 | 2. You must ensure that your app and wxPython are using the same | |
13 | wxWindows DLL. By default on MSW wxPython installs the wxWindows | |
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 wxWindows must be built with the same flags | |
19 | and settings. This probably means that you will need to rebuild | |
20 | wxPython yourself. It may be possible for me to distribute the | |
21 | setup.h and etc. that I use, but you'll need to rebuild everything | |
22 | yourself anyway to get debugger versions so I'm not too worried | |
23 | about it just yet. BTW, on MSW if you do a FINAL=0 build (full | |
24 | debug version) then you will need to have a debug version of Python | |
25 | built too since it expects to have extension modules in files with | |
26 | a _d in the name. If you do a FINAL=hybrid build then you will be | |
27 | able to use the stock version of Python, but you won't be able to | |
28 | 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 |