Re: Need help solving a threading issue
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:ejcsa3h977j4apng46kb7hjr8ja8thc7on@4ax.com...
There are two issues here, one dealing with thread message queues,
and another dealing with interthread SendMessage, both of which can be
avoided by simply
not creating user-visible HWNDs in a secondary thread.
Hmm, I've created top-level hidden windows in a thread, whereby other
threads call SendMessage(), and Windows does the right thing of switching
context to the thread my window was created on prior to my message handler
being invoked (I strongly believe it does anyway). This seems to work fine.
But then, you specified "user-visible" HWND's. I'm not sure why
user-visible HWND's are different than hidden ones?
It is actually hard to create a dialog as a top-level owned window in MFC,
because it
would have a parent of NULL, but in MFC, if you specify the parent as
NULL, then it
defaults to using the main application window as its parent, and there
isn't really a way
to specify that the parent HWND is NULL, because the only expression the
programmer has is
to specify the parent CWnd* as NULL, which has a different meaning in how
it is
interpreted.
I didn't think of that, thanks. What kinds of issues would there be if a
top-level window is owned by a window of another thread? It's not the same
as a parent-child relationship (e.g. WS_CHILD), is it? Offhand, it seems it
would work, especially if the owner window is disabled (as when you show a
modal dialog in MFC) and couldn't be destroyed while the owned dialog is
displayed....
-- David