| | 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 | |
projects / wxWidgets.git / blame_incremental