Как отладить, почему приложение VB6, использующее мой элемент управления .NET ActiveX, не регистрируется для событий? - PullRequest
1 голос
/ 19 июля 2010

Мой оригинальный запрос был здесь, чтобы дать вам представление о том, как я реализовал.

Замена компонента 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.

Есть идеи, как это отладить?

...