In a nusthsell you don't want to be a "CPU hog" by having busy-wait loops (i.e. tight loops where you're checking for a specific set of condition -- e.g. readiness for data from device or process). Of you're in a situation where you're in some loop waiting for something, you might as well relinquish the remaining part of the timeslice. This might actually speed things up, since it could very well allow the other process that you're waiting for to complete as it gets more CPU cycles to complete its task. Admittedly I've been guilty of a fair amount of badly-behaving code like that back in the PC/MS-DOS days. That was mainly since you'd only have one program running at any time (and in the case where you'd launched a different program, in most cases i'd be a blocking call -- so your program would always sleep and not get resume running until the called program ran to completion), and more often than not, you had actual hardware (that operated independent of the main CPU) like UART to handle various tasks (nowadays in Windows many devices ave been virtualized as software -- so it's *very* important you don't "starve" them and cause the system to come to a grinding halt).

>>Hi Thomas,
>>
>>Thanks for the explanation - now making sense to me. I am indeed now using createobject() to create an instance of an Excel/Word object (as per suggestion here by Cetin). For the most part, I have made this a global change in the app so that other processes launched do not clobber something already running.
>>
>>So to summarize what you have said, use DOEVENTS so that if a COM object is still working away at something, even when control is returned to VFP, DOEVENTS forces VFP to wait until the COM object is finished. Is that correct? If it is correct, then I suspect some of the larger templates being loaded are not always fully instantiated when control is returned to VFP and then when my next bit of code goes to query an object (like the .Sheets collection that I am seeing), then my code crashes.
>
>COM objects run independently of the VFP process. If you go to task manager after creating an "excel.application", for example, you'll see a new instance of excel.exe running. When you tell the excel object to quit, that excel.exe will go away. This is true regardless of whether or not the excel window is physically visible or not.
>
>What COM does is provide an interface API and protocol to allow VFP to communicate with the other app (so they both speak the same language, even if VFP was written in C and Excel was written in VB). As such, VFP continuing on in its own program flow after having made an asynchronous call to Excel (where you tell the COM object to do something and it returns immediately but the actual fulfillment of the request may take several seconds, such as in IE and loading a web page) is completely independent. The two are not related. VFP pausing then, issuing DOEVENTS, or calling the WIN32API Sleep() function, none of it matters. The remote excel.exe is running its own code internally, and is largely unaware of what's taking place in VFP.
>
>However, one thing adding DOEVENTS will do is keep your app from showing "Not Responding" after five seconds of waiting.
>
>>Second question, does DOEVENTS wait for all Windows processes or just the COM object(s) that have been opened from inside VFP? I suspect the latter as there would always be tons of Windows events firing?
>
>Windows is a message-based system. It communicates from the OS out to every user app via messages. It sends out messages to each running program they can know what's going on in the system.
>
>Some messages are keystrokes, mouse moves, but it also sends out messages about changed power level states, or when a new device driver is installed, or uninstalled, or if a USB device has been connected, disconnected, etc. There are also user messages which signal back and forth that are specific between apps, such as if I created a DLL and it needed to send a message back to the VFP HWND, you could BINDEVENT() in VFP to intercept that message.
>
>What COM does is provide an explicit point-to-point communication between your app and the instantiated COM app. It loads a stub into your own process to handle this side of that communication. Your app then call into the logical COM object which is just that stub. It packages up your message to forwards it to the remote process via whatever protocol it's using. This is why COM is often so slow on mass changes or updates (like trying to update a spreadsheet by going cell-to-cell and populating data). Each request to do something on the remote object is a full two-way communication protocol exchange between processes, and whereas this all happens very fast (milliseconds), it's not nearly as fast as a single app communicating with itself (nanoseconds to microseconds).
>
>So, all that DOEVENTS does is read the current system's message queue (it's own queue) in its own process. It's trying to read mouse events, keystrokes, timer ticks, along with any custom messages sent from other processes in the system that are communicating with your HWNDs, ready to respond to your movement, to signal Enter() events, Leave() events, mouse and keyboard events, etc. But for the COM object you've instantiated, I don't believe it has any callbacks that would be handled by DOEVENTS. I think it would take a special COM object to have such an exchange.
>
>Nonetheless, it's still a good idea to use DOEVENTS, and even DOEVENTS FORCE, in loops where you're waiting, because it keeps your app from showing up "Not Responding" if it happened to take more than several seconds to complete in the remote COM process.
>
>>Albert
>>
>>>>>sprinkle in Doevents...
>>>>What does DOEVENTS actually do - or why would I sprinkle this in? Help file seems to indicate it just stops until all windows events are finished.
>>>
>>>You did not describe what COM setup you use, so first guess was createobject( "excel.application"), which creates out-of-process COM. Another option could be loading a vfp COM.dll from Excel and setting up a bridge, so that inside vfp the callers structure can be traversed - but that would happen inside the same process.
>>>
>>>COM sometimes returns from a method call when internal processing is still at work - best example probably is Internet Explorer/WebBrowser, where calling program has to explicitly wait, until .ReadyState of the COM object signals that all necessary work building DOM tree of HTML is done, before error-free access to DOM subobjects is possible. Such asynch working is the exception, but sprinkling in doEvents or short sleep periods give the COM object the chance to finish creating "heavier" structures - and running into error is hint enough for me to try if such asynch working is responsible for the error state even if I am not given explicit property to check or event to trigger further action from COM-model.
>>>
>>>Such asynch processing might be introduced by the specific sheet/code via own COM objects. Another possible source, when out-of-process is used: createobject() ONLY guarantees creating a new/unshared process for the asked-for COM object. At any time later this COM component might be hijacked by another process wielding getobject().
>>>
>>>Again - all the above more in the region of "possible" not "probable" in environments with COM habits I consider well-reasoned ;-)