wxWidgets/samples/dll
Vadim Zeitlin 51ec29ea5d Always link with expat in monolithic build.
Fix linking errors when using wxXML in sttaic monolithic build: in this case
we must link with expat but it was listed too early, before wxWidgets
libraries using it, in the bakefile-generated makefiles.

Now add it to the end of the linker command line too by including -lexpat in
EXTRALIBS_FOR_BASE which are appended to the linker arguments.

Notice that now -lexpat is linked twice because it is still added by
<wx-lib>xml</wx-lib> in bakefiles, even in monolithic build, but I don't know
how to avoid it and it is harmless anyhow.

Closes #12573.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@70116 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
2011-12-25 13:28:01 +00:00
..
dll_my_dll.dsp
dll_sdk_exe.dsp
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
dll_wx_exe.dsp
dll.bkl
makefile.bcc Always link with expat in monolithic build. 2011-12-25 13:28:01 +00:00
makefile.gcc Always link with expat in monolithic build. 2011-12-25 13:28:01 +00:00
Makefile.in Always link with expat in monolithic build. 2011-12-25 13:28:01 +00:00
makefile.unx
makefile.vc Always link with expat in monolithic build. 2011-12-25 13:28:01 +00:00
makefile.wat Always link with expat in monolithic build. 2011-12-25 13:28:01 +00:00
my_dll.cpp Move wxThreadEvent into wxBase. 2011-06-28 17:24:37 +00:00
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).