33 lines
1.6 KiB
Plaintext
33 lines
1.6 KiB
Plaintext
|
This sample shows how to embed wxPython into a wxWindows application.
|
||
|
|
There are a few little tricks needed to make it work, but once over
|
||
|
|
the hurdle it should work just fine for you. I'll try to describe the
|
||
|
|
build issues here, see the code and comments in embedded.cpp for
|
||
|
|
examples of how to use it.
|
||
|
|
|
||
|
|
1. The most important thing is that your wx application and wxPython
|
||
|
|
must use the same version and the same instance of wxWindows. That
|
||
|
|
means that you can not statically link your app with wxWindows, but
|
||
|
|
must use a dynamic library for wxWindows.
|
||
|
|
|
||
|
|
2. You must ensure that your app and wxPython are using the same
|
||
|
|
wxWindows DLL. By default on MSW wxPython installs the wxWindows
|
||
|
|
DLL to a directory not on the PATH, so you may have to do something
|
||
|
|
creative to make that happen. But because of #3 this may not be
|
||
|
|
that big of a problem.
|
||
|
|
|
||
|
|
3. wxPython, your app and wxWindows must be built with the same flags
|
||
|
|
and settings. This probably means that you will need to rebuild
|
||
|
|
wxPython yourself. It may be possible for me to distribute the
|
||
|
|
setup.h and etc. that I use, but you'll need to rebuild everything
|
||
|
|
yourself anyway to get debugger versions so I'm not too wrried
|
||
|
|
about it just yet. BTW, on MSW if you do a FINAL=0 build (full
|
||
|
|
debug version) then you will need to have a debug version of Python
|
||
|
|
built too since it expects to have extension modules in files with
|
||
|
|
a _d in the name. If you do a FINAL=hybrid build then you will be
|
||
|
|
able to use the stock version of Python, but you won't be able to
|
||
|
|
trace through the PYTHON API functions.
|
||
|
|
|
||
|
|
4. I expect that most of these issues will be much more minor on
|
||
|
|
Unix. ;-)
|
||
|
|
|