If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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)

Re: Win32 child control thread

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.

Re: Win32 child control thread

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. :-(

Re: Win32 child control thread

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.

* The Perfect Platform for Game Developers: Android
Developing rich, high performance Android games from the ground up is a daunting task. Intel has provided Android developers with a number of tools that can be leveraged by Android game developers.

* The Best Reasons to Target Windows 8
Learn some of the best reasons why you should seriously consider bringing your Android mobile development expertise to bear on the Windows 8 platform.