"Remy Lebeau (TeamB)" < XXXX@XXXXX.COM > wrote
Let me explain what I need to accomplish and maybe you can suggest a better
way to do it.
1) The in-proc COM server is distributed to arbitrary third party
developers - so it has to use all COM standards.
2) The server is called once (say Foo()) from inside these client
applications and Foo() must start up a background thread (say ThreadX)
inside the server to perform some regular monitoring. It does this moniting
using a waitable timer and WaitForSingleObject(). The monitoring in ThreadX
is done repeatedly until the app exits. Foo returns and the client continues
while ThreadX does its work.
3) When ThreadX's timer fires and it detects a certain condition, it must
fire an IDispatch event (say EventX) to the client app (who of course had
previously connected a sink), passing some parameters, informing the client
that this certain event has ocurred. The client can respond as they like and
the EventX eventually retuns to the COM server. When EventX returns,
ThreadX goes back into the wait.
The waiting logic and event logic all seems to be working fine. I would
simply throw away Synchronize() and fire the event back at the client, but
thats not right. When I try that, I get *BizzArE* results in the client app
which I believe to be because it is not Synchronize()d. An example of this
bizzarre behaviour is: in the event handler in the client I just do a
MessageDlg(), but some times the dialog is so large it fills the entire
screen, other times it contains no caption or text, other times the button
is entirely the wrong size, etc.