>Does anyone know why ThreadId is the same for all the instances of a multithreaded object? I can see why ProcessId is the same, but I would think that ThreadId would be different for each instance. If not then how does VFP or the OS track each thread's object properties? There must be some unique handle.
>
>The object is compiled as Multithreaded/MultiUse OLEPUBLIC. I then display the Application.ThreadId for each instance after I do a createObject().
>
>
>Thanks
>
>Costas

Costas,
As Vlad posted, there is a difference between multithreaded COM DLL and multithreaded application.

VFP is a single threaded application. It does not inherently have the ability to create new threads. With the deployment of VFP6 SP3, it was given the ability to be used by multithreaded applications (e.g. IIS, MTS, COM+) and not kill performance.

Multithreaded applications can create separate threads and within those threads, a VFP COM object can be created. Prior to SP3, the COM object would "step on itself" when this occurred. A call into the COM object from one thread could be blocked by an already executing call from a completely separate thread. This is not a good for scaleable middle-tier objects. < s > With the creation of MTDLLs, calls are no longer blocked. Each COM object created is completely compartmentalized in the thread that instantiated it.

Depending on what environment you created the COM objects in, you will get the ProcessID and ThreadID of that process and thread. If you used something like C++, which can spawn new threads, you would be able to get different threads.

HTH.