Why does WaitForSingleObject get in the way of dialog initialisation?

Question

1.00/5 (1 vote)

See more:

For purposes of 64 bit compatibility, I've wrapped a third party DLL as a 32bit single-dialog-based MFC app. I then spawn that app and wait for it to finish in my main process, using the file that it produces.

This all works fine. To make it behave in a more integrated fashion I'm passing in the class name of my main window, so the sub-app can find it and use it as a parent for the dialog. This also works if I run the sub-app separately (with the correct command line).

However, when I spawn the child process from my main app and WaitForSingleObject the dialog is never displayed, like it got into the wait loop first. I do need to wait for my sub-app to finish, so anyone know how I can parent it properly?

Posted 22-Oct-15 18:19pm

Kyudos

Add a Solution

Comments

George Jonsson 23-Oct-15 1:07am

Have you tried to start the dialog using a thread?

2 solutions

Solution 1

I cannot see your code, but who told you that your WaitForSingleObject should not get in the way of your execution. It blocks any thread, no matter what it is. First of all, it looks like you don't understand what it does. There is no any "wait loops". Let me tell you: the attempts to wait something in a loop, which is called "spin wait", is the shame. Sometimes you have to do it and this is not your fault, but then its certainly due to the fault of some software or even hardware you are using

Now, the thread is blocked by putting it in a sleep state, without any loops. It means that it is switched off (preempted by the system) and marked "sleeping", never scheduled back to execution until it is waken up, which is happened on several conditions, first of all, signaled state of the object, and then timeout, and other thing. Importantly, nothing reads the condition. The OS works in an even-oriented manner, and then it wakes up the process, that is, removes sleep state and switches to this thread.

You need to figure out yourself why your dialog (or anything else) is blocked. Usually, simple logic helps, but there are complex cases with complicated multiple-point deadlock chain; and usually this is the case when you have to redesign your code in a fundamental way and simplify threading seriously. If it happens as a result of a bug, such bugs can be extremely hard to detect, so code redesign is the most feasible approach.

—SA

Posted 22-Oct-15 20:50pm

Sergey Alexandrovich Kryukov

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Kyudos · Accepted Answer · 2015-10-26T10:37:00

So it seems setting the dialog parent to the waiting app window was the problem, which I can kind of understand. I achieved what I wanted by finding the parent window from the class name, and passing the window to the dialog - but not to CDialog (so no parent is set). I then just used CenterWindow with the parent CWnd.