>Hi Bill,
>>I can get around this by only allowing the "master" app to "Exit All", but I'm not well versed in Windows processes architecture and I would like to understand what is happening here. When ShellExecute() is executed, does the "master" application process "own" the started processes or something like that? Thus causing a "loop" of a process trying to shut itself down thru another process? If not, then what is happening?
>
>While I don't have an idea, what's happening, why don't you try a different approach. Any application should know whether it's the master application, or a second instance. If the user selects "Exit all" in a child application send a message to the parent instance. I don't know much about VB, but I think you can intercept windows messages. If not send the message that selects the "Exit all" menu item in the master application. When the master application receives this message, it closes down all applications including the one that requested the shut down and terminates itself.
>
>BTW, SendMessage() waits for the result from the destination application. This might cause problems here, so try PostMessage() instead.
>
>Christof

For those interested, I decided to post what (little) results I have learned on this issue. I decided to take Ed Rauh's advice and did some reading in Ch. 14 of the volume he cited and also read carefully the descriptions of SendMessage() and PostMessage() on the MSDN CD's.

Even after reading the information about processes and threads in Appleman's book, I'm still scratching my head somewhat over these items in relation to the issue that was facing me. I.e. I still don't quite understand what's happening inside the OS ( as if anybody really could :-) ).

However there are two pertinant statements made in the SendMessage() description that seem to have bearing on this particular scenario:

"The function calls the window procedure for the specified window and does not return until the window procedure has processed the message. The PostMessage function, in contrast, posts a message to a thread's message queue and returns immediately." ( as Christof pointed out in his reply )

Also:

"If the specified window was created by the calling thread, the window procedure is called immediately as a subroutine. If the specified window was created by a different thread, the system switches to that thread and calls the appropriate window procedure. Messages sent between threads are processed only when the receiving thread executes message retrieval code. The sending thread is blocked until the receiving thread processes the message."

Based on these statements I decided to use PostMessage() in place of SendMessage() to shut down the running instances. This seems to be working in all combinations of app instances running regardless of which instance started which other instance(s) and which instance initiated the "Exit All" procedure.

The following scenarios are the ones in which I saw the problem:

Instance A launches Instance B; Instance A launches Instance C, etc. Then Instance B or lower ( i.e. C, D, etc. ) executes the "Exit All" procedure and the instances hang. In this scenario, if A executes the "Exit All" procedure, all instances close properly.

Instance A launches Instance B, etc. A lower instance ( i.e. B, C, etc. ) launch further instances ( e.g. B->M, B->N, C->O, etc. ) Then any instance, including A executes the "Exit All" procedure and the instances hang.

I am concluding that there is some relationship between the "processes" or "threads" that are launched and the launching "process" or "thread" which, under the right conditions, produces some sort of "feedback" between the "processes/threads" which prevents one of the instances from completing it's shutdown and thus SendMessage() does not complete in the calling "Exit All" instance which thus hangs both instances and stops the whole process. Using PostMessage() seems to allow each instance to independently shut itself down without notifying the "calling" process/thread of its completion thus allowing each process/thread to continue on its merry way.

I would appreciate any feedback on any of this as I would like to understand what is actually happening here and as I noted a lot of this is conclusions I am making in a near vacuum ( hopefully not between my ears :-) ).

Thanks,
Bill