GC> Not specifed after a cursory glance at the Messages and Message Queues 
 GC> section.  It does, however, note that the default 
 GC> queue is "usually large enough to hold all input 
 GC> messages even if the user types or moves the mouse 
 GC> very quickly.  If the operating system message queue 
 GC> does run out of space, the system *ignores* the most 
 GC> recent keyboard input (usually by beeping to indicate

This was very naive,  since that is not the only source of messages
--WinPostMsg and WinPostQueueMsg are the other sources.  Many programs use
these apis to post messages amongst their own threads -- and do not check
the return value of WinPostMsg -- so they behave badly when the queue is
full (Borland/Watcom ide's are a good example).

The solution is a larger default queue (fixpak 17 uses 3000) and/or better
programmers.  Here is a simple wrapper for WinPostMsg that will fix the
problem (as long as it is used between threads,  not for posting to the
same thread (which is not often done)):

 /*
  * PostMsg() -- just like WinPostMsg(),  but checks to see
  * if the queue was full
  */
 static void PostMsg(HWND h, ULONG msg, MPARAM mp1, MPARAM mp2)
 {
     while(!WinPostMsg(h, msg, mp1, mp2)){
         DosSleep(1);
     }
 }


--- Maximus/2 3.00