I must say that I have tried this approach (at least I believe so, I may be
wrong), though in a simplified, 10 minute quick&dirty solution using only
Win32 API (no MFC) to make things simpler: I created one simple window
(lets call it window A) that would immitate the parrent dialog. Then this
window's WM_CREATE message handler is used to start a new thread with its
own message dispatcher. When this thread starts and before it reaches the
message dispatcher, it creates one simple window (lets call it window B),
with its own wndproc and sets the window A as its parrent. Window B
immitates the ActiveX control. When all this is created, there are two
windows, each in its own thread, with their own wndprocs and message
dispatchers, where the window A is the parrent to the window B. Next, I
have placed a WM_LBUTTONDOWN message handler in window B's wndproc that
performs a lengthy operation (some number crunching) which immitates a call
to ActiveX control's method that does the lengthy operation.
When I actualy click on the window B, the whole the thing freezes until the
lengthy operation completes. So this obiviously is not a right sollution or
analogy.
It may even be necessary to create a child dialog in the
thread so that the parent of the ActiveX control will be in the same
thread as the control. You have to get everything that the control
interacts with into the secondary thread.
Since my q&d sample above does not work, would this be a fix for it? My
understanding of your proposal, mapped to the q&d sample: create another
window (window C) in the second thread, set the window A as its parrent and
window B as its child. Is this correct, or am I now going completely the
wrong way?
TIA
Bila
thread, both threads become involved. This is a common source of
deadlocks. It is a possible reason your q&d solution locked up, since