DR>
  > As far as how many threads get WM_QUITs, only one does. I have read
  > that this thread is picked kind of at random so you need to call
  > WinCancelShutdown() with the second parm TRUE for all of the threads
  > who don't want to every get the WM_QUIT. But that does not seem true
  > for the reasons mentioned above.
DR>

Is it possible that one of your threads gets a WM_QUIT, then closes the app
before the other threads get a chance to read their queues?

 JdBP>   WinSendMsg() is another very poorly documented call.  The

You are correct - the destination thread only processes the message when it
next looks at its queue.  If it is in the middle of processing one message
when you WinSendMsg another to it, your sent message will sit waiting for
the destination thread to get the next message. (WinPeekMsg/WinGetMsg).

Interestingly, the source thread is *not* blocked waiting for a reply!  For
example, it is perfectly legitimate for the second thread to send a message
back to the first while processing a message sent *from* the first!  

Cheers, Graham Perks
perks{at}ibm.net

--- Maximus/2 2.02