A lot of places where you need a DoEvents you can also use
WAIT WINDOW TIMEOUT .05.

VFP only needs a UI event to catch up with Windows events. Also, sometimes
Sleep() will work especially if you're waiting for ActiveX controls to fire
their events.

I think the workaround with Mouse probably defeat the purpose of DoEvents().
The whole point of it is to have DoEvents clear the event queue. When you
mouse around like that you're faking out the queue, but may cause it
to not execute the queued events io nthe first place - the whole reason
for using DoEvents in the first place. Be careful with that.

+++ Rick ---


>>This is a copy of a FAQ I just posted:
>>
>>Calling DoEvents() has always been horribly slow in VFP. While reporting another issue with Hong-Chee Tan at Microsoft he found that moving the mouse around alters the test code I sent him. So this fact gives a workaround to speed DoEvents back up using a MOUSE command. Try this code for example:
>>
>>

* doevtest.prg
>>lparameter llMouse
>>
>>local x, i
>>
>>x = seconds()
>>
>>for i = 1 to 100
>>   if ( llMouse )
>>      mouse at mrow(), mcol()
>>   endif
>>   doevents()
>>endfor
>>
>>activate window "debug output"
>>debugout seconds() - x

>>
>>Run it with and without a .t. argument and see the difference in execution times 26 vs 0.5 seconds on a P2-300 Win95 class machine.
>
>That's really interesting Frank. So we can create a library Function called DoEventsFast() which does what you do above and replace any calls in our code.
>Do you foresee any downside? Eg I have a busy web server app, like the UT app actually, that does a Doevents() every 2 seconds - this is on a powerful NT Server - so it'll be interesting what effect it has.
>Thanks