There are lots of ways that you can run multi-threaded FoxPro code, but they all require some sort of wrapper - typically via COM - to provide the callback mechanism from the multi-threaded code.

You can also call into external multi-threaded code from FoxPro. So you can call out to .NET code that spawns new threads and those threads can then fire back information to FoxPro either using events or even something as simple as object references that are passed in and called from the multi-threaded code. If you're familiar with .NET this is a great option for interacting with multi-threaded code.

For example, Web Connection includes a ThreadRunner class that includes both C++ and .NET components that provide a wrapper around this mechanism. The Fox code calls out to Win32 or .NET to spin up a new thread and you pass in an object via COM. This library is geared towards an event based flow that has start/progress/complete/cancel/fail events that can be fired and received back at the FoxPro caller along with the ability to wait for all events to complete which is the most common scenario for async/multi-threaded code.

In this scenario, you basically provide an object that is passes to the multi-threading handle (.NET or Win32) which then fires events back as needed. There's even a generic component that can execute a PRG file directly from a multi-threaded call. It's not difficult to do this and a library can wrap this fairly easily. Typically COM is used to provide the connector that can then call back into FoxPro and execute Fox code. However, the easiest way is to just pass an object into a pipeline that can then fire events back into FoxPro to message. For me I've been using .NET objects to do this and it works great.

THere are of course other libraries that do similar things - the most popular being ParellelFox which is a more generic choice. ThreadRunner is more useful for Web and Async execution scenarios.

Either way - there are lots of ways to do this with FoxPro.

OTOH, if you are really in need of multi-threaded code, maybe it's time to investigate other technologies that can run multi-threaded code without extra components and acrobatics to work around FoxPro limitations :-)

+++ Rick ---



>As I understand it, the whole point of multithreading - well, one of the points - is to allow different processors or cores to share the workload. I am not sure how you implement multithreading in Visual FoxPro, though, since it doesn't have any built-in multithreading capability. At least, none that is exposed to the programmer.