wxWidgets/wxPython/samples/embedded
2003-10-02 00:58:06 +00:00
..
.cvsignore
embedded_sample.py
embedded.cpp A huge glob of changes in the 2.4 branch merged over to HEAD 2003-10-02 00:58:06 +00:00
embedded.rc
makefile.unx
makefile.vc
mondrian.ico
mondrian.xpm
README.txt Typo fixes 2002-08-07 21:06:33 +00:00

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 worried
   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.  ;-)