wxWidgets/samples/dll
Kevin Ollivier da8b1d4b3b Rebake from clean wx tree.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@63052 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
2010-01-04 00:45:45 +00:00
..
dll_my_dll.dsp Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
dll_sdk_exe.dsp Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
dll_vc7_my_dll.vcproj Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
dll_vc7_sdk_exe.vcproj Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
dll_vc7_wx_exe.vcproj Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
dll_vc8_my_dll.vcproj Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
dll_vc8_sdk_exe.vcproj Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
dll_vc8_wx_exe.vcproj Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
dll_vc9_my_dll.vcproj Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
dll_vc9_sdk_exe.vcproj Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
dll_vc9_wx_exe.vcproj Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
dll_wx_exe.dsp Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
dll.bkl Explicitly link the SDK application example with user32.lib. 2009-12-09 13:31:46 +00:00
makefile.bcc Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
makefile.gcc Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
Makefile.in Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
makefile.unx
makefile.vc Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
makefile.wat Rebake from clean wx tree. 2010-01-04 00:45:45 +00:00
my_dll.cpp Define MY_DLL_BUILDING symbol for dll sample DLL build. 2009-12-07 03:04:39 +00:00
my_dll.h Use __declspec(dllexport) instead of WXEXPORT in dll sample header. 2009-12-07 16:27:14 +00:00
README.txt
sdk_exe.cpp Add a very simple example of a Win32 application using wx DLL. 2009-12-07 16:27:23 +00:00
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).