OK, The situation is a little different now.
I have taken the code for the COM interface and moved it into a C# DLL. And
set the Register for COM Interop flag to true. This code, in the exposed
methods, instantiates a class to contain the data, and calls a custom Event.
In a separate C# applicaiton (that has a reference to the DLL) I have a
class that "listens" for the DLL's methods to be called, and then implements
the Event Handler functions for the custom event.
In another separate console application, this time in C++, I have referenced
a copy of the same COM DLL, and gotten the object. It is currently set up as
an inproc server. I take this interface, and call the methods on the COM
object.
When I execute the C# application, it makes the DLL class, sends it to its
listening class, and waits for user input to quit. Just like it should.
Then I start up the C++ console application, it gets a copy of the COM
class, and calls the methods on it. I get a lot of lines of output (one for
each function call) in this concole window, but I get no output from the C#
Event handler code.
Given the above, I believe that COM in the C++ app is instantiating a NEW
class from the DLL (not referencing the one that exists in the C# app
already) and executing its calls, just like it is supposed to for an inproc
server.
Therefore, I believe, in order to get the Event Handlers to work, the DLL
needs to be a local server, so the C++ app can attach to the already existing
class (in the C# process thread) and then when the DLL fires off the events,
the C# app can then handle it.
Does that sound right?
If so, how do I go about making the nice DLL into a Local Server and
registering it appropriately.
Andrew