wxwidgets/samples/dll
Vadim Zeitlin 4f4c5fcfdf Use nullptr instead of NULL in the code and documentation
This is a combination of running clang-tidy with modernize-use-nullptr
check for some ports (GTK, X11, OSX) and manual changes to the ports for
which it couldn't be used easily (MSW, DFB) and also manually updating
the docs.

Also replace NULL with null or nullptr in the comments as this is more
consistent with the use of nullptr in the code and makes it simpler to
grep for the remaining occurrences of NULL itself.

And also use null in the assert messages.

Only a few occurrences of "NULL" are still left in non-C files, mostly
corresponding to unclear comments or string output which it might not be
safe to change.
2022-10-18 01:25:25 +02:00
..
dll.bkl Remove all lines containing cvs/svn "$Id$" keyword. 2013-07-26 16:02:46 +00:00
makefile.gcc Rebake and rerun autoconf after the version update 2022-07-17 17:03:39 +02:00
Makefile.in Rebake and rerun autoconf after the version update 2022-07-17 17:03:39 +02:00
makefile.unx Remove wxGTK1 port and GPE support 2022-10-16 22:01:02 +02:00
makefile.vc Rebake and rerun autoconf after the version update 2022-07-17 17:03:39 +02:00
my_dll.cpp Use nullptr instead of NULL in the code and documentation 2022-10-18 01:25:25 +02:00
my_dll.h Remove all lines containing cvs/svn "$Id$" keyword. 2013-07-26 16:02:46 +00:00
README.txt
sdk_exe.cpp Use nullptr instead of NULL in the code and documentation 2022-10-18 01:25:25 +02:00
wx_exe.cpp Use nullptr instead of NULL in the code and documentation 2022-10-18 01:25:25 +02:00

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).