Win32 child control thread

I created a dialog with a child control, child control has it's own thread and message pump, and it has the dialog window set as the parent.
Is this a bad idea?

I already noticed I cannot wait on the window creation from the main dialog thread, because when the child thread calls CreateWindowEx with my dialog hwnd as the parent, it must invoke the main dialogs message loop, because I get deadlock.
As long as I don't do that, everything seems to work ok.
Do child windows post or send messages to their parents which could potentially cause me more deadlocks? (If I am going to use sendmessage to contact my child control this could cause problems)

In general, keep all the UI in the same thread. Use worker threads to manipulate the data in the background and synchronize with the main UI thread as appropriate.

Keep in mind that using sendmessage between the worker and ui thread is a synchronous operation which kind of defeats the purpose of having the worker thread.

Quote:

---

Originally Posted by 12oclocker

I created a dialog with a child control, child control has it's own thread and message pump, and it has the dialog window set as the parent.
Is this a bad idea?

---

Yes, it is.
In addition to what Arjay already wrote you could look as this essay: Using Worker Threads

Problem is I need the child control to do it's DC operations in it's own thread, or it freezes the main dialog every X ms.
I'm updating images very frequently in the child control, and it is causing problems because the images are very large.
Even if I calculate everything except the DC operations in a separate thread, it still causes noticeable lag in the main dialog when I stretch the DIB to the DC for the child window.
I noticed windows VMR7 VMR9 video does use a separate thread for it's video rendering, and it can be a child window, so it must be allowed in some cases.

I wrote test code yesterday, and it works, with one caveat, I must use the CS_OWNDC style in the child window which is running in it's own thread. If I don't, I sometimes get strange painting problems when I resize the main dialog.

I've also tried making the window not a child, and having it imposed on top the main dialog by moving it when the main dialog moves, but this causes overlapping issues as the dialog disappears behind the main dialog when the main dialog is clicked, and using topmost of the custom video window causes it to be on top of all application windows, not just the main dialog, which is a problem.

If a window has no parent, I have never had a problem putting it in it's own thread, so long as you don't have it and the main dialog invoke each other's messages pump's or wait on each other (which would cause deadlock)

I've just never had to do this with a child window before, does a child control use SendMessage to talk to it's parent, or does it use PostMessage? Does it talk to the parent if it has it's own message loop? or are we dealing with a one way communication from parent to child? not sure of the inner workings. If it's one way from parent to child, I should have no problems.

I got an idea, I think I will use LWA_COLORKEY and SetLayeredWindowAttributes for the main dialog, and create a child control static box with a specific color I want to be transparent, then I will have my custom video window Not have a parent, run in it's own thread, and be border-less, I will then move the custom video window around with the main dialog, and keep it under the transparent area. Id rather not go to this trouble though, child in it's own thread would be much easier, but I'm not sure if that child will ever use sendmessage to contact it's parent, if it does, I will have deadlock.

--update on idea, can't click through the transparent color area as expected, it works if I specify dialog color as transparent, but if I override WM_PAINT for dialog, and paint a pink rect in it somewhere, then use LWA_COLORKEY and SetLayeredWindowAttributes to make pink transparent, I can no longer click through to area behind the transparent section, must be something with manually painting the color does not allow clicking through. :-(

just found something interesting...
if(InSendMessage()){ReplyMessage(TRUE);}
http://msdn.microsoft.com/en-us/library/ms810439.aspx

very old article, but if I did need two threads to sendmessage back and forth, you can call the above code right after getting your variable, and before sending a message back to the other thread, so deadlock will not occur... it basically releases the messagepump of the message sender right away with your specified return value, and then the thread which received the message can continue to process whatever it wants without blocking the sender thread.

I'm leaning towards the solution in #4, a child window with it's own thread.
I clean up the child window thread after the main dialog loop is exited, since it's safe to wait for the thread object there, since the main dialog message loop is no longer running. controlling the child thread with post-messages, I see no deadlock issues which could occur.