>Hi Rick,
>
>Thanks for the great response. Couple of follow-up questions:
>
>
>>Windows will still send events to VFP, but when suspended VFP doesn't process the message queue, so you'll get those "Not Responding" messages in the title bar. It's why it's best to Sleep(10) in a loop with DO EVENTS for a 100 count to sleep for 1000, so that it will still process messages and you won't see the Not Responding.
>
>I am thinking on the above the one section should say:
>
>"It's why it's best to Sleep(10) in a loop with DO EVENTS for a 100 count [than to do a single] sleep for 1000"
>Did I get that right?

Correct.

>Secondly, even though there have been lots of responses here regarding DOEVENTS, I still have not got a good summary in mind on what this does. The online help says "Executes all pending Windows events" only. I read the description in kilo-fox and it seems to be used when setting .AutoYield to .F. to an embedded ActiveX control on a form (or that is one of their examples). Since I am running the COM Excel object asynchronously, what would issuing DOEVENTs in my code actually do?

Windows communicates with running programs via a message queue. Programs can run without a message queue, but it's not typical. The message queue is basically like an event in VFP's object. A KeyPress event or MouseMove event. Whenever the mouse moves across the form, we receive a signal in that event. Or whenever a key is pressed or released, we receive those events.

Those events are translated from information Windows is sending vfp9.exe. Windows sends every mouse movement over a window owned by a process when that process has focus. The way it does that is by preparing a message:

Here are some common messages:

Left mouse button has been pressed down (MouseDown):
https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-lbuttondown

Left mouse button has been released (MouseUp):
https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-lbuttonup

A key has been pressed down (KeyDown):
https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-keydown

A key has been released (KeyUp):
https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-keyup

Windows sends these messages and hundreds more based on what's happening in the system. When the Internet connection goes offline or online there's a notification sent out. When the video mode changes. When certain devices are plugged in or unplugged. When a new CD or DVD or Blu-ray disc is inserted or ejected, etc.

Countless messages. These all go into a queue and are handled in the order received.

DOEVENTS processes those messages.

During a normal READ EVENTS operation, Windows is handling the events automatically. But during lots of heavy processing without any UI, there's nothing polling that queue to remove messages from it and process them. So, when you manually insert DOEVENTS or DOEVENTS FORCE into your code, it will force VFP to read some of those messages and process them. VFP doesn't process all of them, but is judicious, and only processes some so as to not impact performance too much

So the loop:

DECLARE Sleep IN WIN32API INTEGER nMilliseconds

* Wait 1/2 second:
lnStart = SECONDS()
DO WHILE ABS(SECONDS() - lnStart) < 0.5
    DOEVENTS FORCE
    Sleep(10)
ENDDO

This loop will begin a loop for up to 1/2 second. It will check every 10 milliseconds plus whatever time it takes to process any messages waiting in the queue. It will prevent the Not Responding messages from showing (had you needed to wait longer).

Contrast that with this:

DECLARE Sleep IN WIN32API INTEGER nMilliseconds

* Wait 1/2 second:
Sleep(500)

The second one will wait, but nothing will be processed in the message queue during that time, so Windows may think it's stalling out and indicate it's not responding.

Polite apps, friendly apps, well-considerate apps, will always seek to keep the messages flowing, and to tell the OS the app is still alive. It works well with users. It works well with other apps. It works well all the way around.

Hope this helps.