Re: Parent and Child in separate UI Threads
On Tue, 27 May 2008 09:29:01 -0700, Denis Adamchuk
<DenisAdamchuk@discussions.microsoft.com> wrote:
We have a workaround for solving a problem with painting in 2 UI threads and
I would be VERY glad if you have any ideas about risks of implementing it.
Say, CSeparateThreadWnd is a CWnd that runs in a separate thread and has a
parent in the main thread. And we do the following:
BOOL CSeparateThreadWnd::PreTranslateMessage(MSG* pMsg)
{
return m_pParentWnd->SendMessage(WM_USER+400,
reinterpret_cast<WPARAM>(pMsg), 0);
}
Surely you're using a real identifier instead of WM_USER+400? Anyway,
basing it on WM_USER is probably not the best choice; for more, see:
Which message numbers belong to whom?
http://blogs.msdn.com/oldnewthing/archive/2003/12/02/55914.aspx
Concerning interthread SendMessage, it should be fine as long as you aren't
holding a mutex across the call that the target thread tries to lock. As I
mentioned earlier, it won't deadlock merely because the target thread tries
to SendMessage back to the first; for more on that, see:
When can a thread receive window messages?
http://blogs.msdn.com/oldnewthing/archive/2004/06/08/150929.aspx
LRESULT CChildView::OnWmUser400(WPARAM i_wParam, LPARAM)
{
return AfxPreTranslateMessage(reinterpret_cast<MSG*>(i_wParam));
}
Is it acceptable?
This is uncharted territory for me and probably most other people.
The fact is MFC has two different Permanent HWND<->CWnd maps for 2 threads
and when PreTranslateMessage() is executed in the second thread it reverses
by a tree child-parent and when finds a parent from the first thread assumes
that CWnd is NULL and aborts further traversing. So we manually throw a
message to the main thread to handle all parent windows operations that were
not done.
It seems like the sort of thing you'd need to do, but MFC walks the window
hierarchy in many other places. Will you need to do this everywhere? I
dunno.
It solves a painting problem but does not solves keyboard layout problem.
I'm not sure what you mean by the latter, but are you using
AttachThreadInput?
We have no chance to make all UI in single thread so have to invent such
solutions.
What you're doing is pretty unusual, so I'd suggest casting as wide a net
as possible. You might also want to post on the codeproject.com forums.
--
Doug Harrison
Visual C++ MVP