>Nadya,
>
>I think you should reconsider Ed's message (After all he did use my proposal to speed up DOEVENTS ;-) )
>
>

IF CHRSAW() OR MDOWN()
>   DOEVENTS
>ENDIF

Actually, I got this from Dave Frankenbach a while before you proposed it; it works in most cases. Another approach is to call the API to check all the Windows virtual keys using a buffer to detect changes:

DECLARE SHORT GetKeyboardState IN USER32 STRING @ lpKeyState 
cKeyboardAtRest = REPL(CHR(0),256)
cKeyboardStateNow = cKeyboardAtRest
=GetKeyboardState(@cKeyboardAtRest)
*
*  In loop
*
=GetKeyboardState(@cKeyboardStateNow)
IF cKeyboardStateNow # cKeyboardAtRest
   *  Something happened
   DOEVENTS
   =GetKeyboardState(@cKeyboardAtRest)
ENDIF

I suspect it has less overhead than calling CHRSAW() and MDOWN() - it traps all the virtual keys, not just keystrokes that translate to characters; you can trap pressing Alt, Shift, Ctrl as well, down and up changes.

>
>Seriously, You can use this mechanism in a progressbarclass to check if the cancel button is actived (Either by its howkey, Enter or Mouseclick). If it is, set a Processcanceled property to .t., hide the progresbar and check for Processcanceled in the calling routine and abort it of neccesary.
>
>Besides it gives the user the ability to click (because users want to click everything by nature) for cancel, it has some other interesting side effects:
>
>1. You can move the progresbar during the process, like in many other (multi threaded ?) windows programs
>2. During this long process, you can even start other (smaller) routines, forms, activating menubars etc, giving your application a bit of a multitasking look.
>
>Walter,