>
>IOW (just like Craig's suggestion to resort to threading), I'm serving the OS, or have to invent tricks to avoid the customs/tax/excise that the OS levies on the app.
>

You're not "resorting" to anything. That's the correct way to do this type of thing. Long running, CPU intensive tasks aren't meant to be run on the UI thread, because, as you found out, as far as Windows is concerned it appears like your app has hung. You're not serving Windows in this case, you're serving the end user who has to deal with crappy apps that sometimes just stop - they have no idea why or even how to exit it. That's why the OS has taken on this task. If there was some "override" switch every dev. would flip it, which would render the OS mechanism of checking for hung apps ineffective.

It's unfortunate that VFP never had any built-in mechanism to spawn a new thread or process. However, there are a few on VFPX and Rick Strahl also has a set of libraries that can do the same thing.

Since it sounds like you're not interested in that approach, you can also try doing a DOEVENTS FORCE. But that kills performance, unfortunately. Also double-check to make sure _vfp.AutoYield is set to .T. (it should be, by default). I'd also be interested in hearing if having a form w/progress bar helps at all. I'd guess that if you're code is performing a lot of intensive queries, then it may not. If it's mostly VFP code and loops, it may. Let us know what you find.