Quote Originally Posted by LaVolpe View Post
You can initialize COM onto the thread via OleInitialiize or CoInitialize/Ex. Don't know if that helps or not.
That doesn't help - unless the COM-Class (or -Dll) supports (within its hidden ClassFactory-creation-routine) so called MTAs
(MultiThreaded Apartments) ... VB-generated COM-Dlls do not support this mode - the best you can switch on in our
VB-Compiler (when creating ActiveX-dlls) is "Apartment-Threaded" - which will support at least the creation of COM-
instances on different STAs (within the same Process) - this is due to "legacies" into the (transactional threading)
of DCOM and COM+ hosting-processes, where VB-Classes (VB-generated COM-Dlls) once played a major role.

Such a started STA (which fully initializes its ThreadLocalStorage only, when you e.g. create a VB-Class-instance
on the new Thread in question) runs basically with an "isolated Memory-Allocator", which e.g. creates separate
allocations for all the Public-Variables which are defined in *.bas-Modules inside a given VB-Dll-Project anew -
on each new STA-Thread which sees such a new (first) ClassInstance of a given VB-Dll (one can log that e.g.
with an appropriate ThreadID-writing function in the Dlls Sub Main, which is also jumped into for each STA-thread
anew, on first instantiation of a VBClass from a given Dll on this new given STA-thread...

So the TLS-issues is the main-culprit for the unpredictable behaviour (and crashes) we see, when we want to talk
"across STAs directly" - that's also the reason why we see problems, when VB-defined callbacks are jumped into
from System-APIs which run on different (System-)Threads.

MTAs (which VB doesn't support) are far more robust in this regard - but then you will have to handle Thread-
synchronizing yourself again.

So, to talk across STAs in a safe way, one has to use the System-provided Marshaling-Functions for that:
CoMarshalInterThreadInterfaceInStream -> http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
CoGetInterfaceAndReleaseStream -> http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx
which will ensure a synchronous communication - as well as serialization of any passed Params into complete Data-Copies - with each
Method-call to the other Target-Interface in question.

For a bit more flexibility I've implemented my own Variant-Array-based serialization-routines for the STA-Threading-Support
in vbRichClient5 (which communicates over Pipes, achieving a somewhat better performance than normal COM-marshaling this way).

Olaf