I received some help from _ys_ on this, but as it turned out, as is often the case it only helped us narrow down the problem.
We are writing a VC++ application that is started and monitors/commands hardware, collects/stores data and does some number-crunching. We are also writing a VB HMI (an ActiveX EXE) that is created (when the user desires a UI) from the VC++ client using the CoCreateInstance command above. So our VC++ engine is a COM client and our VB HMI is a COM Server. They communicate through events and properties we've set up on the VB/HMI/Server side, and an event sink on the VC++/Engine/Client side.
With _ys_'s help, the VB server/HMI and C++ client/engine are perfectly independent, on separate threads: after CoCreateInstance I can run a modal dialog box and it locks up the engine but the HMI is free as a bird, which is perfect.
The problem starts when the user tries to start an "analysis" from the HMI. We have written a 'TalkToEngine' event on the VB side (with some message parameters) and implemented an event sink class in our C engine which traps the events (derived from IDispEventSimpleImpl). The HMI can pass a message through this event which causes our event sink to call StartAnalysis. StartAnalysis does a lot of number crunching and sends messages to the HMI.
When StartAnalysis is called from some other location in the VC++ engine, it works fine; the analysis starts and the HMI (if's been instantiated) recevies and displays messages. However, when StartAnalysis is called from the event sink (or from a method called from the event sink, et al.), then the HMI becomes very sluggish, it doesn't respond to mouse events, you occasionally get the "Switch to..." dialog box, until the analysis is complete.
I suppose this is because the call to StartAnalysis is not allowing the Event Sink to complete its processing. Apparently the event sink must run its course and release something (what are the mechanics here?) to allow the two objects to operate independently again. The problem is that I don't know how invoke the correct routines in the engine from the event sink *without* tying up the event sink until those routines are done (which is what appears to be tying up my HMI).
I actually tried rewriting the event sink to set a flag that is picked up by a timer outside of the event sink (inelegant and low-performance) and also starting a new thread to run StartAnalysis (but for some reason the new thread can't talk back to the VB/Server/HMI), but both were problematic. There *has* to be a simpler way to do this.
Thanks very much. High point value because I think this requires some narrow/deep expertise.