Re: ATL threading problem using client COM interface
Edward Diener <eddielee_no_spam_here@tropicsoft.com> wrote:
Igor Tandetnik wrote:
Don't do that. You can't draw on a window from a thread other than
the one that created it. Post a message to it, and have the handler
of that message do the drawing. Better still, update internal data
structures appropriately, and call InvalidateRect. Eventually,
WM_PAINT message will arrive: draw in response to that (which you
have to do anyway).
Agreed. I think I have to call UpdateWindow after InvalidateRect to
generate a WM_PAINT message.
You don't strictly _have_ to. InvalidateRect marks the window as
"dirty", and WM_PAINT will arrive eventually, once all other messages
are processed and the message queue is empty (WM_PAINT is a low-priority
message, above only WM_TIMER if I recall correctly). UpdateWindow simply
forces WM_PAINT to be sent right away.
Again, post a message, let the main thread do the closing.
To get my window to update while my thread is running in the
background it looks like my main thread, after starting my worker
thread, needs to continue looping doing MsgWaitForMultipleObjectsEx
/ GetMessage / DispatchMessage until the worker thread is done.
Your main thread is an STA thread, isn't it? Your client should already
be running a message pump on an STA thread.
Or are you saying you are currently not returning from the method call
until the worker thread finishes? If so, then I don't see the point of
the worker thread in the first place. What _is_ your main thread
currently doing while the worker is running?
--
With best wishes,
Igor Tandetnik
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925