Amebis/wxWidgets
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

embedded sample's README updates

Browse Source 
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@26567 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Robin Dunn
2004-04-01 19:48:18 +00:00
parent 5059f192cf
commit dcc1aa2382
1 changed files with 15 additions and 15 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
wxPython/samples/embedded/README.txt
View File

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