Fixed the bugs preventing wxPython from being embedded in a wxWindows

app, and added a sample showing how to do it.


git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@15329 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

wxPython/samples/embedded/README.txt

@@ -0,0 +1,32 @@
+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.  ;-)
+