Hello all,
I don't think VFP 7 will have allow the programmer to write multi-threaded code.
Writing such code is really difficult, debugging it is horrible. I think the average VFP developers are not the right target for this kind of stuff.
Maybe in the (near?) future computer languages will evolve to the level where multi threaded programming will be a easy and trivial, but now is not the case.
Untill then, such solutions like the DLL I posted are easy to write, but they are indeed only 'smoke and mirrors'. The application is multithreaded, but is far from the capabilities desired by the programmers. Wouldn't be nice to have VFP procedures and methods running in they own threads, when desired, with VFP providing the concurent access to objects and resources, locking as needed 'behind the scenes'?
Regarding the DLL I posted, I think the main advantage comes not when running local multi-threaded applications, but when mixed with distributed computing. It allows to instantiate the remote object and call a method on it to launch the processing, without blocking the caller (you client app)! VFP Advisor posted recently another solution to the problem, using timers in EXE servers.
Another point I'd like to make is that MTS (and COM+) is not only multi-threading. What MTS provides is much more, declarative programming to COM objects. You benefit from security, transaction support, multi-threading, just-in-time activation and more simply by declaring you whant them. My DLL is far less capable :)

Regards,
Remus