Thanks Jonathan de Boyne Pollard for your msg about WinCancelShutdown,
on Sunday, 11-13-1994!

I have been doing some experimentation and here is what I have found.

1) If I have two threads, each with their own message loop and top
level frame, the thread that gets the WM_QUIT is always the one that is
used to shut down the program, regardless of whether I call
WinCancelShutdown() on that thread or not. So, if I select that frame
in the task list and do a Close or if I select Close from that frame's
system menu, the thread servicing that window will always get the
WM_QUIT regardless. This is in contradiction to what the documentation
says.

2) The only way that any thread ever gets a WM_QUIT seems to be via
one of the above mentioned mechanisms. So it seems that other
background threads (which have a queue only for the ability to
post/send messages) would never get one anyway and so would not have to
worry. If you use Killem or Slay or something of that nature, no
WM_QUITs ever get sent and the message loops never exit.

3) I agree with you about having only one thread with a message loop,
however I know there are apps out there that do what I did in my test
in #1 above and I wanted to see how it works. Also, if one of those
background threads pops up a message box or a dialog (which some do in
our system) then they have implicitly entered a message loop. So that
is still a problem even if only the main thread does the main message
loop. So, if one my threads in the background pops up a message/dialog
box (and it has a system menu), the user could select Close from there.

4) But any way you cut it, there seems to be a major hole in the
documentation for WinCancelShutdown() that needs to be filled. Since
IBM wants everyone to be multithreaded, then they should certainly tell
us exactly how to do it right. My experiments seem to totally
contradict what I have been told and read, so I just want to hear it
from the horse's mouth.

5) 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.

6) What it really comes down to is that the thread that gets the
WM_QUIT has to be the one that is prepared to clean up and exit the
application. If the message loop is on the primary thread and that
thread gets the WM_QUIT, this is not an issue. The primary thread's
return will implicitly close the program. However many systems
(including ours) don't make use of the primary thread because it has a
number of gotchas (the stack is always fully allocated making it
wasteful of memory and, therefore, there is no guard page at teh end of
the stack so that any stack overrun will not be caught and will stomp
on data areas without anyone ever knowing it.)

I am continuing to research the problem and will post the results if I
find anything else out.

___
 X KWQ/2 1.2b X If at first you don't succeed, put out another version (KWQ 1.2).

--- Maximus/2 2.02