Now I think I see where you're coming from with this. You're not (at least it doesn't appear so) saying we should have multithreading in VFP. What you want is a MS "certified" way of being able to utilize MTDLLs from the VFP environment. You mentioned VFPCOM and that's where I think the light came on. You want an extra tool (like VFPCOM) to act as the moderator and you would just hook into this object instead of using Remus's tool.

I'm sorry if my poor command of the English language obscured what I was asking for, and you are almost 100% right.

I think we should have multithreading in VFP, but until that being done (if ever), a MS "certified" way to use MTDLLs from the VFP environment will be the best second thing.

In the meantime, surely, Remus's dll is my way to go along with the way you suggested early, although Remus's solution looks easier as it is doing all the work.

>I think Mike said it in another thread, Remus already did it. I don't understand C++ enough to say whether he did it the best way or not. I don't know how many techniques there are to spawn and track threads or if one is better than another. Who is to say MS could do it better?

Well, they have access to the guts of the product and they are very talented people. My hat is off for Calvin, Randy and the whole team.
>
>FWIW, I do know that his utility was "highly" publicized when he wrote it. He posted here and on the MS newsgroups so anyone frequenting those places (and that's alot) know about it if they had an interest in multithreading.
>
I was not aware of that, thanks for your message.