Предоставление информации об интерфейсах

← →
Mx © (2005-08-02 17:04) [0]

Задача такова: есть куча интерейсов, которые предоставляет некая библиотека (ActiveX Library). Информацию об этих интерфейсах я выкладываю в виде TLB и пускай себе импортируют куды надо. Проблема вот в чем. Объекты библиотеки должны взаимодейстовать с рядом внешних объектов. Вернее эти внешние объекты и должны подгружть библиотеку. Для них у меня также определен интерфейс, вопрос как его выложить? Делать разные библиотеки типов? Поясню, сторонний пользователь может использовать возможности библиотеки, только реализовав определенный интерфейс. Так вот, как правильно предоставить информацию об этом интерфейсе? Ведь если я запишу ее в ту же TLB, это мне кажется будет некорректно.

Спасибо.

P.S. Объяснил немного мутно, если что задавайте вопросы, поясню.

← →
wal © (2005-08-02 17:35) [1]

Почему некорректно, в самый раз, например объекты с поддержкой событий событийные интерфейсы при себе держат, а не "где-то там", хотя это и не возбраняется. Вообще в библиотеке типов только описание интерфейсов (и не только). По большому счету, он может быть описан где угодно.

С уважением.

← →
just_me (2005-08-02 18:36) [2]

> Делать разные библиотеки типов?
А как же иначе? Библиотека типов есть неотемлемая часть каждой ActiveX Library и хранится в ее ресурсах. Так что если имеются, скажем, 2 ActiveX Library, одна из которых использует другую, библиотеки типов у них отдельные и по другому быть не может. Или все-таки имеется в виду нечто другое? Тогда детализируйте pls.
Кроме того для работы с ActiveX Library не нужно никому давать какие-либо TLB - разработчики клиентов данной ActiveX Library-сервера сами себе сгенерят описания интерфейсов. Они ведь могут писать клиентов на VB или VC

← →
Mx © (2005-08-02 22:27) [3]

Спасибо за ответы. Почему я думаю об одной TLB? Дело в том, что спецификацию обязательных интерфейсов для внешних приложений разрабатываю я. То бишь я должен предоставить её, а вернее предоставить описания интерфейсов, которые необходимо реализовать. Я еще вот за что волнуюсь, данные из библиотеки используются для регистрации серверов в реестре. Если я опишу их у себя, то они будут ссылаться на мою ActiveX Library, хотя предназначены для внешнего использования. Или я не совсем правильно понимаю?

← →
isasa © (2005-08-03 10:23) [4]

>Если я опишу их у себя, то они будут ссылаться на мою ActiveX Library, хотя предназначены для внешнего использования.
regsvr32 <имя файла ATL>
на машине, где необходим ActiveX, исправят положение.

> Библиотека типов есть неотемлемая часть каждой ActiveX Library
> и хранится в ее ресурсах.
Совсем не обязательно.

> Так что если имеются, скажем, 2 ActiveX Library, одна из
> которых использует другую, библиотеки типов у них отдельные
> и по другому быть не может.
Аналогично.

> Почему я думаю об одной TLB? Дело в том, что спецификацию
> обязательных интерфейсов для внешних приложений разрабатываю
> я. То бишь я должен предоставить её, а вернее предоставить
> описания интерфейсов, которые необходимо реализовать.
Расскажу, что есть у меня (как я понял вопрос, проблема аналогична моей, только возникшей пару-тройку лет назад).
И так. Есть некоторое приложение, функциональность которого может расширяться путем подключения плагинов. Причем плагины должны быть в виде СОМ-объекта, поддерживающего определенный интерфейс. В самом приложении тоже создается СОМ-объект, через который и происходит взаимодествие с плагинами. Этот объект поддерживает туеву хучу интерфейсов (причем часть из них реализована в других объектах) и событий.
В результате имеем следующее:
Библиотека типов № раз:
DozaTerminalApp - КоКласс объекта приложения.
IDozaTerminalApp - Интерфейс по умолчанию для DozaTerminalApp, поддерживается в DozaTerminalApp, реализован там же.
IDataModule - Интерфейс доступа к БД, поддерживается в DozaTerminalApp, реализован там же.
IDTIconBar - Интерфейс области уведомлений приложения, поддерживается в DozaTerminalApp, реализован там же.
IDTIcon - Интерфейс иконки в области уведомлений приложения, реализован где-то "в кишках", возвращается после добавления иконки через интерфейс IDTIconBar.
IDTIconEvents - Интерфейс событий иконки области уведомлений, может быть реализован в плагине.
IPump - Информационный интерфейс оборудования, реализован где-то "в кишках", может быть получен через интерфейс IPumpContainer или при возникновении события IPumpContainerEvents.
IPumpContainer - Интерфейс "коллекции" оборудования, поддерживается в DozaTerminalApp, реализован там же.
IPumpContainerEvents - Событийный интерфейс оборудования, может быть реализован в плагине.
IPumpService - Интерфейс управления оборудованием, поддерживается в DozaTerminalApp, реализован там же.
Библиотека типов № два:
DTPluginControl - КоКласс объекта диспетчера плагинов.
IDTPluginControl - Интерфейс по умолчанию для DTPluginControl.
IPluginList - Интерфейс коллекции плагинов, унаследован от IStrings (описанного черт знает где), поддерживается в DTPluginControl, реализован тем же.
IDTPlugin - Интерфейс плагина, должен быль реализован в плагине.
Библиотека типов № три:
IDTReportControl - интерфейс управления системой отчетов
IDTReport - интерфейс отчета. Оба реализованы во внешних модулях (аналогично плагинам).
Библиотека типов № четыре:
DtEventDispatcher - КоКласс диспетчера событий.
IDtEventDispatcher - Интерфейс диспетчера событий. Поддерживается в DozaTerminalApp, реализован в DtEventDispatcher.
IDtEventSrc - Интерфейс источника событий, реализуется где угодно (в месте возникновения события).
IDtEventDst - Интерфейс получателя события, может быть реализован в плагине.

Все четыре библиотеки типов расположены в качестве ресурсов в разных приложениях, реализации интерфейсов раскиданы по разным обьектам, ничто не мешает обьекту из одного приложения реализовывать интерфейс, описанный в другом приложении, или вообще не в приложении, а просто в tlb-файле, если все правильно зарегистрировано в реестре, то проблем никаких не возникает.

С уважением.

Респект!

Предоставление информации об интерфейсах Найти похожие ветки