Этот способ понятный и применимый, если контрол универсальный и расчитан на использование в рамках произвольных приложений.
А если контрол специализированный и завязан специфические моменты использующего его приложения, то проблема остается. Например, контрол реализует дополнительные интерфейсы стороннего приложения или, в случае Excel "завязан" на непосредственное взаимодействие с объектной моделью Excel (ячейки, листы,...).
Не понятны сами причины невозможности отладки
Дело обстоит совсем странно - существует какая-то непостижимая разница в отношении отладки в среде VB между ActiveX dll и ActiveX Control, хотя по факту они отличаются лишь набором интерфейсов и расширением файлов.
Когда ActiveX Control запущен в VB в режиме отладки, его невозможно инстанциировать как COM-объект.
В OleView класс виден, правда путь к файлу указывает на vb6debug.dll, но при попытке загрузки возникает ошибка class not registered.
Если же тип проекта ActiveX DLL, все работает нормально, никаких проблем с отладкой, причем в режиме отладки регистрация так же перенаправляется на vb6debug.dll, т.е. используется тот же механизм перехвата вызовов.
Единственный контейнер, в котором контрол можно отладить - это IE
Ну очень интересно, чем IE в данном случае отличается от всех других контейнеров и вообще COM-клиентов.
Цитата(skysun @ 9:07:2008, 06:55 )
я бы создал еще один проект специально для отладки в VB. Отладил бы методы и свойства и затем бы юзал его в ехеле.
Когда объединяешь 2 проекта в VB то отладка проходит как обычно
Этот способ понятный и применимый, если контрол универсальный и расчитан на использование в рамках произвольных приложений.
А если контрол специализированный и завязан специфические моменты использующего его приложения, то проблема остается. Например, контрол реализует дополнительные интерфейсы стороннего приложения или, в случае Excel "завязан" на непосредственное взаимодействие с объектной моделью Excel (ячейки, листы,...).
Не понятны сами причины невозможности отладки
Дело обстоит совсем странно - существует какая-то непостижимая разница в отношении отладки в среде VB между ActiveX dll и ActiveX Control, хотя по факту они отличаются лишь набором интерфейсов и расширением файлов.
Когда ActiveX Control запущен в VB в режиме отладки, его невозможно инстанциировать как COM-объект.
В OleView класс виден, правда путь к файлу указывает на vb6debug.dll, но при попытке загрузки возникает ошибка class not registered.
Если же тип проекта ActiveX DLL, все работает нормально, никаких проблем с отладкой, причем в режиме отладки регистрация так же перенаправляется на vb6debug.dll, т.е. используется тот же механизм перехвата вызовов.
Единственный контейнер, в котором контрол можно отладить - это IE
Ну очень интересно, чем IE в данном случае отличается от всех других контейнеров и вообще COM-клиентов.
