]>
Commit | Line | Data |
---|---|---|
1 | ||
2 | This Windows-specific sample demonstrates how to use wxWidgets-based UI from | |
3 | within a foreign host application that may be written in any toolkit | |
4 | (including wxWidgets). | |
5 | ||
6 | For this to work, you have to overcome two obstacles: | |
7 | ||
8 | ||
9 | (1) wx's event loop in the DLL must not conflict with the host app's loop | |
10 | (2) if the host app is written in wx, its copy of wx must not conflict | |
11 | with the DLL's one | |
12 | ||
13 | ||
14 | Number (1) is dealt with by running DLL's event loop in a thread of its own. | |
15 | DLL's wx library will consider this thread to be the "main thread". | |
16 | ||
17 | The simplest way to solve number (2) is to share the wxWidgets library between | |
18 | the DLL and the host, in the form of wxWidgets DLLs build. But this requires | |
19 | both the host and the DLL to be compiled against exactly same wx version, | |
20 | which is often impractical. | |
21 | ||
22 | So we do something else here: the DLL is compiled against *static* build of | |
23 | wx. This way none of its symbols or variables will leak into the host app. | |
24 | Win32 runtime conflicts are eliminated by using DLL's HINSTANCE instead of | |
25 | host app's one and by using unique window class names (automatically done | |
26 | since wx-2.9). |