My initial request was here to give you an idea of how I did this.
Replacing ActiveX C ++ component with .NET implementation?
The C ++ ActiveX control that I am replacing uses COM events. When one of the VB6 client applications (VB6, I believe that depends.exe tells me that it uses msvbvm60.dll ) creates an instance and uses my replacement, it is not logged for any of the events, and, unfortunately, the way It works, consists in the fact that after the completion of a certain method call, the client application does nothing until a fire occurs.
The same application works fine with the implementation of the C ++ control.
I tried to get the TypeLib generated with tlbexp.exe , as close as possible to the C ++ version, how can I do this, and with the exception of the properties implemented by propget and propput (it seems this is the way tlbexp does this) and one property OLE_HANDLE, interface declarations and coclass look almost identical, and important things, for example, regardless of whether its interface is based on IDispatch, etc. the same.
One problem with TypeLib replacement that I noticed is that I can’t get tlbexp.exe to export one of the coclass interface properties as OLE_HANDLE , it just ends up long in the TLB generated from the assembly (this TypeLib in the TLB refers to registry). Could this cause problems with eventing?
Note. . My ActiveX control inherits from System.Windows.Forms.Control and installs MiscStatus of 131457 in the coclass registry entry, as suggested by http://ondotnet.com/pub/a/dotnet/2003/01/20/winformshosting.html , reason that the thing that I am replacing was an honest asset of ActiveX, and I could not get these existing clients to successfully instantiate the object without any code changes until I inherited from WinForms management.
I hope this is not an inheritance that clogs events in this case.
I tried the approach, when my class declares public events with the same name as the interface specified by ComSourceInterfaces , this works 100% from a C # application that uses AxHost, events are fired.
I also tried instead to implement IConnectionPointContainer and all the supporting interfaces on my replacement control, and this works 100% of the C # application, but in the VB application it never tries Advise() set the connection point of the client receiver interface for the call, it only calls Unadvise() with an invalid cookie value of 0.
Any ideas on debugging this?