You can do it, if you use the process handle returned by each
ShellExecute
; then you can use the function
WaitForMultipleObjects
:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms687025%28v=vs.85%29.aspx[
^].
This function call will be a blocking call. Your calling thread would be set to wait state until all three processes are terminated. In this wait state, the calling thread will be switched off and not scheduled back to execution until waken up by some event, such as time out or when the condition (all processes are terminated) is satisfied. This way, the wait will spend zero CPU time, which is good.
As such call is blocking, as a rule of thumb, the calling thread should not be a UI thread. That said, if your application is a Windowed UI application, you will need to create a separate thread where you can do all the blocking calls. If you can reasonably expect that all three child processes can be completed in a very short period of time, you could do it even in a UI thread, but I wouldn't do it.
Moreover, I would avoid using
ShellExecute
and having any separate processes at all. It would be the best to turn them into DLL for in-proc use. You see, the processes are very well isolated; so you have a very limited access of control over a child process from your parent process. You can wait for its termination; if this is a simple console-only process, you can redirect its output to your process and handle it; and that's nearly all you can do. The different processes can effectively collaborate only if they are designed specially to do so, via some IPC mechanisms. I'm sure this is not your case, otherwise you would not ask this question.
—SA