>>I have in interesting scenario happening that I need enlightenment concerning Windows processing.
>>
>>I have an application ( in VB ) that can open another copy of itself via ShellExecute(). In this app I have a menu option "Exit All". This option loops thru all windows shutting down the open copies of the app using SendMessage() with the WM_CLOSE parameter. It skips the window the function was called from, thus not sending itself a WM_CLOSE command, then shuts itself down normally.
>>
>>This all works fine as long as the Exit All is executed from the copy of the app that opened all the other copies. If Exit All is executed from one of the running copies started up by the "master", it shuts down apps until ( I guess ) it gets to the "master". Then it locks up.
>>
>>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?
>>
>>Thnaks,
>Hi Bill,
>
>Is the call to ShellExecute() passing the calling form's window handle? If so, see if passing 0 to it makes a difference.

Oops. Sorry George. Looked too fast. I was setting the value of the variable holding the calling handle to 0 as you had asked. Perhaps I should send the Desktop handle?

Bill