ec091c9f2b
CPPFLAGS, CFLAGS, CXXFLAGS and LDFLAGS are supposed to be under user-control and putting configure-determined options in them broke something as simple as running "make CXXFLAGS=-Wno-some-extra-warning" because this overrode the CXXFLAGS set by configure and required for build. Improve this by using WX_*FLAGS in the generated makefile and leaving the user-controlled FLAGS alone. This is still not ideal as running "configure CFLAGS=-DFOO" and then "make CFLAGS=-DBAR" will define both FOO and BAR, as configure copies CFLAGS to WX_CFLAGS, and so setting it on make command line won't override it, as it should, but this should be a much more rare and also much less severe problem, so we should be able to live with it for now. Normally this commit shouldn't result in any user-visible changes, i.e. it shouldn't break any previously working scenarios and only make some previously broken ones work. |
||
|---|---|---|
| .. | ||
| dll.bkl | ||
| dll_vc7_my_dll.vcproj | ||
| dll_vc7_sdk_exe.vcproj | ||
| dll_vc7_wx_exe.vcproj | ||
| dll_vc8_my_dll.vcproj | ||
| dll_vc8_sdk_exe.vcproj | ||
| dll_vc8_wx_exe.vcproj | ||
| dll_vc9_my_dll.vcproj | ||
| dll_vc9_sdk_exe.vcproj | ||
| dll_vc9_wx_exe.vcproj | ||
| makefile.bcc | ||
| makefile.gcc | ||
| Makefile.in | ||
| makefile.unx | ||
| makefile.vc | ||
| my_dll.cpp | ||
| my_dll.h | ||
| README.txt | ||
| sdk_exe.cpp | ||
| wx_exe.cpp | ||
This Windows-specific sample demonstrates how to use wxWidgets-based UI from
within a foreign host application that may be written in any toolkit
(including wxWidgets).
For this to work, you have to overcome two obstacles:
(1) wx's event loop in the DLL must not conflict with the host app's loop
(2) if the host app is written in wx, its copy of wx must not conflict
with the DLL's one
Number (1) is dealt with by running DLL's event loop in a thread of its own.
DLL's wx library will consider this thread to be the "main thread".
The simplest way to solve number (2) is to share the wxWidgets library between
the DLL and the host, in the form of wxWidgets DLLs build. But this requires
both the host and the DLL to be compiled against exactly same wx version,
which is often impractical.
So we do something else here: the DLL is compiled against *static* build of
wx. This way none of its symbols or variables will leak into the host app.
Win32 runtime conflicts are eliminated by using DLL's HINSTANCE instead of
host app's one and by using unique window class names (automatically done
since wx-2.9).