>George,
>
>The only issue with the code that I know of is if the mouse is not inside a VFP window then the doevents can't be sped up. The mouse doesn't ever have to actually move. And I certainly didn't want to pull the mouse out of another app into the VFP app (which was happening before I added the mrow and mcol tests *s*). I figured that if the user was working in another app it doesn't matter to them at the time how long the doevents inside VFP takes.
>
>If you have a different take on a problem with it I'd appreciate the feedback.
>
Hi David,

What you say about work in another app is true. I was thinking along the following terms, however, which is kind of related to my own experiences (which I'll share BTW).

Assume you've got a command button that's responds to a keypress (a hot key, if you will). Assume further, that user intiates the action with the key and the mouse is outside the window (imagine a small SDI form launched from a short cut on the desk). Now you've a situation where the user would care how long VFP takes.

I've been working with an OLE automation server (which is slow by itself). It's sending me an unknown number of records, so to let the user know that it was working, I added a spinning disk and threw in a DoEvents so that it would work. Of course, the DoEvents slowed the thing down by more than a factor of 20. While the spinning disk was nice, the performance was unacceptable. That's why I got interested in your solution.

I guess what one could do to work around the "user working in another app" problem would be to make a call to the API to GetForegroundWindow (off the top of my head, but it might be better to use GetActiveWindow), to determine if the VFP app was active, and make sure the mouse was in proper position if it was.

What do think?