>Is it just VFP that hogs processor or do the other Development packages do the same?
>

VFP does not check the thread or Window message queues under certain conditions; notably, in the course of a single statement being executed (for example, a long-running single SQL Select statement that doesn't call any UDFs) or in tight, in-line code that is inherently non-interactive and does not make a call to another outside procedure or method; the net result is that VFP sometimes appears not to be responding to the OS or UI events at times. Other environments often do not exhibit the same behavior under similar circumstances, or may offer asynchronous processing capabilities via callbacks, which are not directly supported by VFP native code (using callbacks generally requires writing something in another language which can publish the memory address of service routines handling results or messages that the client must handle itself, like an enumeration result or a message handler added to the event loop.) VFP code, which is interpretive and non-interruptible, doesn't allow this, so an FLL or ActiveX control is required that can offer the address of a code block that receives and processes the callback, and then raises an event that VFP can deal with when it next checks the event loop, or in the event of an API enumeration, may offer a function, method or collection that can be queried for the result following the API call.

It's a matter of the VFP interpretive environment that makes VFP seem non-responsive; you can force it to respond more quickly to UI events by calling DOEVENTS, ensuring that the AutoYield property is set to .T. unless you have ActiveX controls that require it to be set to .F., calling UDFs in monolithic queries to force VFP to break up the execution and the like; this is all at a cost in terms of overall performance, since these operations slow down VFP in order to check the event queue, make function calls and the like. I find that it's often preferable to fire a second instance of VFP at a low priority in the background to service queries that can wait on completion; this is applicable to many complex reports that, while needed, can run in the background separately (and admittedly, more slowly) while the user continues to run their main application; even better is to have job servers - separate machine(s) which are otherwise idle that can scan a list of pending, non-interactive batch work and run the jobs serially on the idle systems - a good use for the old 64MB PII-300 on the LAN that otherwise would be idle (or better yet, the pointy-haired manager's 256MB, 1GHz PIII because he's out of the office all day for an important meeting...at my old job, my boss noted how very odd it was that the EOM close ran much faster when he wasn't in the office; it couldn't be that he was stressing the LAN heavily running Outlook and Excel. Even if all he does is play a little Solitaire all afternoon.)