Kind of, but not really.
See
It may not become very clear what all this means, but it boils down to this: Usage of multi threaded DLLs you can build in VFP only can provide (limited) multithreading for other clients than VFP itself.
Corrrection: It's not the client using the COM server playing the major role, it's the type of multithreading that's provided by the COM server that makes it unuseful for parallel execution of multiple tasks from one client: The kind of nonblocking multithreaded execution that is provided is for this situation: You have one instance of a COM server that's defined in the VFP MTDLL, two clients can call methods of this same instance. So, first of all, two clients can use the same object, and when this would be from a single threaded DLL two clients calling methods of the COM server object would block each other or the COM server would make one client wait, i.e. one client calls some method and while the COM server executes that method anything else will be queued and run sequentially afterwards. If the COM server object is from an MTDLL one client calls Method1, another client can call the same Method1 or Method2 at the same time from the same COM server instance, this is enabled. No more, no less.
Multithreding in the sense of calling something and copntinue running own process code in parallel within VFP alway requires some hack, not just a COM server that's from a DLL which was compied as MTDLL. The most famous hack once was given by Calvin Hsia in a blog article that I don't find anymore, now. Another hack providing thread creation is in Christian Ehlscheidts
with the CreateThreadObject function provided in the vfp2c32.fll
I once wrote thread184-1820019 and you know that as you were the first responder asking for what to use multiprocessing. Seems you're now at a point you know what to use it for. Notice I also pointed out the same Rick Strahl article about VFP multithreading. So there's nothing new to this.
If you still wonder why MTDLL is not allowing multithreading just think about what VFP does in a line using a comserver object - [tt]result = comserver.method(parameters)[/tt] - well, it waits. It doesn't help that this COM server can now still run other clients calls in parallel, it's not running in parallel for you, not because it can't, but because you - the main VFP EXE Process making the call, waits for that call to come back. It doesn't change if the method has no RETURN or you make the call using the syntax prepending an equal sign.
Chriss
