Board index » cppbuilder » Where do the Events go?

Where do the Events go?


2004-06-16 11:27:14 PM
cppbuilder73
I've created an EventHandler using the TEventDispatcher example that
seems to be everywhere in the Borland news groups. Using a Util
called COMSlicer, I can see the object being instantiated, the
functions FindConnectionPoint, Advise and GetConnectionInterface all
being called with an HRESULT of 0.
I'm sure that the object fires events because I have an example app
written in VC++ that when running, has events firing at sub-second
intervals (when monitored using COMSlicer).
Where should I start looking for bugs, everything seems to be written
according to examples I've seen. Any advise would be greatly
appreciated.
-- Matt
 
 

Re:Where do the Events go?

After some additional head-scratching and research, I'm wondering if
I'm having a threading problem. The COM object developer changed the
COM object from free threading to both. He did this after I
complained that I couldn't create an instance of the interface that is
used to control the Connection Point (it has a start and stop
mechanism). Does Borland default in it's auto-code to a threading
model that would cause problems with a free threaded object?
 

Re:Where do the Events go?

Judging by the overwhelming interest in this thread, I thought I would
finish up what I found just in case it is useful to someone else.
If the COM object you are using is free threaded, you need to call
CoInitializeEx(NULL,COINIT_MULTITHREADED);
This call helps establish the application's primary thread as a MTA
instead of an STA. This is probably obvious to many COMites, but it
took me days to figure out. Don't forget to call CoUninitialize() at
the end of the application.
I made this call in the WinMain(), right before the
Application->Initialize();
Have fun programming all!
XXXX@XXXXX.COM (Matt Kipe) wrote in message news:< XXXX@XXXXX.COM >...
Quote
After some additional head-scratching and research, I'm wondering if
I'm having a threading problem. The COM object developer changed the
COM object from free threading to both. He did this after I
complained that I couldn't create an instance of the interface that is
used to control the Connection Point (it has a start and stop
mechanism). Does Borland default in it's auto-code to a threading
model that would cause problems with a free threaded object?
 

{smallsort}