Мой оригинальный запрос был здесь, чтобы дать вам представление о том, как я реализовал.
Замена компонента ActiveX C ++ на реализацию .NET?
Элемент управления C ++ ActiveX, который я заменяю, использует события COM. Когда одно из клиентских приложений VB6 (я полагаю, VB6, поскольку depends.exe говорит мне, что оно использует msvbvm60.dll) создает и использует мою замену, оно не регистрируется ни для одного из событий, и, к сожалению, работает так, что после вызов определенного метода завершен, клиентское приложение ничего не делает, пока не сработает событие.
Это же приложение прекрасно работает с реализацией элемента управления C ++.
Я попытался сделать так, чтобы TypeLib, сгенерированный tlbexp.exe, был настолько близок к идентичной версии C ++, насколько я могу, и за исключением свойств, реализуемых с помощью propget и propput (похоже, это способ tlbexp делает это) и одно свойство OLE_HANDLE, интерфейсы и объявления классного класса выглядят практически идентичными, и важные вещи, такие как, является ли его интерфейс на основе IDispatch и т. д., одинаковы.
Одна проблема с заменой TypeLib, которую я заметил, заключается в том, что я не могу заставить tlbexp.exe экспортировать одно из свойств в интерфейсе coclass как OLE_HANDLE, оно просто оказывается длинным в TLB, сгенерированном из сборки (на этот TLB ссылается запись TypeLib в реестре). Может ли это вызвать проблемы с обработкой событий?
Примечание: Мой заменяющий элемент управления ActiveX наследуется от System.Windows.Forms.Control и устанавливает MiscStatus из 131457 в записях реестра coclass, как предложено http://ondotnet.com/pub/a/dotnet/2003/01/20/winformshosting.html,, причина в том, что вещь Я заменил честный и добрый элемент управления ActiveX, и я не мог заставить эти существующие клиенты успешно создать экземпляр моего объекта без каких-либо изменений кода, пока я не унаследовал от элемента управления WinForms.
Я надеюсь, что это не наследование, которое испортит события в этом случае.
Я пробовал подход, в котором мой coclass объявляет публичные события с тем же именем, что и интерфейс, указанный в ComSourceInterfaces, это работает на 100% из приложения C #, использующего AxHost, события запускаются.
Я также попытался вместо этого внедрить IConnectionPointContainer и все поддерживающие интерфейсы на моем контроле замены, и это работает на 100% из приложения C #, но в приложении VB фактически никогда не пытается Advise() точка подключения клиентский интерфейс приемника для вызова, он вызывает только Unadvise() с недопустимым значением cookie 0.
Есть идеи, как это отладить?