Child / Parent windows not in same thread

[Maja]

Hi
I am making mfc regular dll that will be loaded in third-party exe. I
need to show window in which I continuously draw with DirectX. The
window will be shown as child window in one of the windows of the main
application. The drawing should take place when the application is
idle. Since I dont have source code of the main application and can't
change its main message loop so I can insert some of my drawing code ,
I came up with the following solution :

Draw on second thread. Create child window on second thread and start
message loop there, create DirectX device on the second thread with
the child window as hwnd.
Problem : I was reading around this newsgroup that I can get in
deadlock problems cause with this solution I will have parent window
which is created in main thread, and child window ( in which the
drawing will be done) in different thread. As I understand the
deadlock can happen because inter-thread SendMessage calls which are
implicit because of the parent/child relationships of my windows.

But, if I can be sure that both the message loops of the main thread
and my second thread are alive, and I don't hold any locks , I can get
away without this deadlocks problems ? or no

[ScottMcP [MVP]]

Post by Maja
But, if I can be sure that both the message loops of the main thread
and my second thread are alive, and I don't hold any locks , I can get
away without this deadlocks problems ? or no

It would probably work if, as you say, both the message loops are alive. But it's not good enough for your thread to hold no locks. The main thread also has to hold no locks.

[Maja]

Post by ScottMcP [MVP]

But,  if I can be sure that both the message loops of the main thread
and my second thread are alive, and I don't hold any locks , I can get
away without this deadlocks problems ? or no

It would probably work if, as you say, both the message loops are alive. But it's not good enough for your thread to hold no locks. The main thread also has to hold no locks.

Thank you for quick reply
One more question

Now after I think more , maybe I can't be that sure, so I am in a
doubt if I should do this thread thing at all.

I found the following post

http://groups.google.com/group/microsoft.public.win32.programmer.ole/browse_thread/thread/f4d67cb4d0b085c0/8f463a49544f48fc?lnk=gst&q=Validity+of+creating+a+child+window+in+a+separate+process#8f463a49544f48fc
which suggests that creating the window as WS_POPUP instead as
WS_CHILD is more secure, so if this is true does it mean that no
chance for deadlocks exists ?

[ScottMcP [MVP]]

Post by Maja

Post by ScottMcP [MVP]

But,  if I can be sure that both the message loops of the main thread
and my second thread are alive, and I don't hold any locks , I can get
away without this deadlocks problems ? or no

It would probably work if, as you say, both the message loops are alive. But it's not good enough for your thread to hold no locks. The main thread also has to hold no locks.

Thank you for quick reply
One more question
Now after I think more , maybe I can't be that sure, so I am in a
doubt if I should do this thread thing at all.
I found the following post
http://groups.google.com/group/microsoft.public.win32.programmer.ole/browse_thread/thread/f4d67cb4d0b085c0/8f463a49544f48fc?lnk=gst&q=Validity+of+creating+a+child+window+in+a+separate+process#8f463a49544f48fc
which suggests that creating the window as WS_POPUP instead as
WS_CHILD is more secure, so if this is true does it mean that no
chance for deadlocks exists ?

Using WS_POPUP, and passing NULL as the hwndParent, will make sure that your window will not have a parent/child relationship with the main thread windows. However, you are still subject to possible deadlocks if you SendMessage to any window created in another thread.

The combination of WS_POPUP and never using SendMessage to the other thread should make you safe from deadlocks. (And it is OK to use PostMessage to the other thread.)

[Maja]

Post by Maja

Post by ScottMcP [MVP]

But,  if I can be sure that both the message loops of the main thread
and my second thread are alive, and I don't hold any locks , I can get
away without this deadlocks problems ? or no

It would probably work if, as you say, both the message loops are alive. But it's not good enough for your thread to hold no locks. The main thread also has to hold no locks.

Thank you for quick reply
One more question
Now after I think more , maybe  I can't be that sure, so I am in a
doubt if I should do this thread thing at all.
 I found the following post
http://groups.google.com/group/microsoft.public.win32.programmer.ole/...
which suggests that creating the window as WS_POPUP instead as
WS_CHILD is more secure, so if this is true does it mean that no
chance for deadlocks exists ?

Using WS_POPUP, and passing NULL as the hwndParent, will make sure that your window will not have a parent/child relationship with the main thread windows.  However, you are still subject to possible deadlocks if you SendMessage to any window created in another thread.
The combination of WS_POPUP and never using SendMessage to the other thread should make you safe from deadlocks.  (And it is OK to use PostMessage to the other thread.)
Using WS_POPUP, and passing NULL as the hwndParent, will make sure that your window will not have a parent/child relationship with the main thread windows. However, you are still subject to possible deadlocks if you SendMessage to any window created in another thread.

But if I pass NULL as the as the hwndParent that defeats my purpose
cause the window will not display as I want. For example if I minimize
the main application window, my window still is shown . So I need at
least to create WS_POPUP window and specify the main window wnd as
owner.

Also I thought if this is so unsafe and error prone than how Internet
Explorer for example can open embed window of Adobe Reader document,
i.e how is that done to be safe ?

[Farnsworth]

Post by Maja
Since I dont have source code of the main application and can't
change its main message loop so I can insert some of my drawing code ,

Yes you can, by subclassing the window you want by calling
SetWindowLongPtr(GWLP_WNDPROC) or SetClassLongPtr(GCLP_WNDPROC).

[Maja]

Post by Maja
Since I dont have source code of the main application and can't
change its main message loop so I can insert some of my drawing code ,

**** Yes you can, by subclassing the window you want by calling
**** SetWindowLongPtr(GWLP_WNDPROC) or SetClassLongPtr(GCLP_WNDPROC).

Yes but I need to write the rendering code only if there are not
messages in message queue of the main window, i.e something like
OnIdle event.
I don't see how can I accomplish that with subclassing with
GWLP_WNDPROC.

[Farnsworth]

Post by Maja

Post by Maja
Since I dont have source code of the main application and can't
change its main message loop so I can insert some of my drawing

**** Yes you can, by subclassing the window you want by calling
**** SetWindowLongPtr(GWLP_WNDPROC) or SetClassLongPtr(GCLP_WNDPROC).
Yes but I need to write the rendering code only if there are not
messages in message queue of the main window, i.e something like
OnIdle event.
I don't see how can I accomplish that with subclassing with
GWLP_WNDPROC.

One other option you have is SetWindowsHookEx(WH_FOREGROUNDIDLE), but I am
not sure if it's suitable in your case.