My original query was here, to give you an idea of how I did the implementation.
Replacing a C++ ActiveX component with a .NET implementation?
The C++ ActiveX control I am replacing uses COM events. When one of the VB6 client applications (VB6 I believe, as depends.exe tells me it uses msvbvm60.dll) instantiates and uses my replacement, it does not register for any of the events, and unfortunately, the way it works is that after a particular method call has completed, the client application does nothing until an event fires.
This same application works fine with the C++ implementation of the control.
I have tried to get the TypeLib generated by tlbexp.exe to be as close to identical as the C++ version as I can make it, and with the exception of properties being implemented with propget and propput (seems to be the way tlbexp does it) and one OLE_HANDLE property, the interfaces and coclass declarations look virtually identical, and the important things like whether or not its an IDispatch based interface, etc, are the same.
One issue with the replacement TypeLib that I have noticed is that I cannot get tlbexp.exe to export one of the properties on the coclass interface as OLE_HANDLE, it just ends up being a long in the TLB generated from the assembly (this TLB is referenced by the TypeLib entry in the registry). Could this cause issues with eventing?
Note: My replacement ActiveX control inherits from System.Windows.Forms.Control, and sets MiscStatus of 131457 on the coclass registry entries as suggested by http://ondotnet.com/pub/a/dotnet/2003/01/20/winformshosting.html, the reason being that the thing I am replacing was an honest to goodness ActiveX control, and I could not get these existing clients to instantiate my object successfully without any code changes at all until I inherited from WinForms control.
I'm hoping its not this inheritance that is screwing up events in this instance.
I have tried the approach where my coclass declares public events with the same name as the interface specified by ComSourceInterfaces, this works 100% from a C# app that uses AxHost, events are triggered.
I have also tried instead to implement IConnectionPointContainer and all supporting interfaces on my replacement control, and this works 100% from a C# app, but in the VB app, it never actually attempts to Advise() the connection point of the client sink interface to call, it only calls Unadvise() with an invalid cookie value of 0.
Any ideas how to debug this?
