I am trying to use a 3rd party API that interacts with the hardware drivers
for a telephony "voice board" (a device similar to a voice modem). The API
allows me to pass the address of a callback function to receive notification
of hardware events (ringing, hangup, etc.)

Unfortunately, the 3rd party API creates a worker thread that does the actual
hardware monitoring and, when an event occurs, calls the callback function.
This violates COM threading rules and yields an unstable application. Specifically
the callback function cannot make any complex function calls, reference any
COM object, any VB global object, or any function in an outside library accessed
via a declare statement.

I have tried having the 3rd party DLL call back to a C++ DLL that I wrote,
which in-turn calls back to the VB function. Unfortunately the call is still
in the context of the worker thread and not in the context of the VB thread,
so again sparks fly.

I have tried having the callback set a timer that in turn calls the VB callback
(or have the callback set a timer that calls another function within the
VB app) neither of which work. In both cases the SetTimer function (written
in my C++ DLL and accessed via a type library) appears to work properly (returns
a timer handle) but the timer never fires (or it never fires on my VB thread???).

I realize that the "proper" way to do this is to handle the callback as a
COM appartment and use the COM inter-thread marshalling (proxy/stub) techniques
to call the function on it's proper thread. However, since the worker thread
is created by the 3rd party API and not directly by me, I don't see how this
can be done. (And honestly, without a good example I don't think I have
the C++ skills to do this.)

Any suggestions would be greatly appreciated.

Steven Sokol

P.S. Please remove the 'nospam' from my email address if you wish to email
me directly. Thanks - S.