7.6.3.2 Базовые интерфейсы контейнеров управляющих элементов ActiveX.

Для элементов управления ActiveX можно выделить следующие основные задачи:

• регистрация элемента управления;

• реализация пользовательского интерфейса и визуализация;

• предоставление своих методов и свойств приложению;

• оповещение приложения о возникающих событиях;

• получение информации о свойствах приложения.

Перечисленные выше задачи решаются за счет того, что любые элементы управления AcitveX предоставляют стандартные интерфейсы. Эти интерфейсы способны поддерживать объекты СОМ в заданном состоянии и эффективно взаимодействовать с приложением, использующим элемент.

Приложение, имеющее в своем составе компоненты ActiveX и умеющее их использовать, называется контейнером элементов управления. Пользователи работают со многими программами и даже не подозревают, что эти приложения являются полноценными контейнерами ActiveX. К ним, например, можно отнести Microsoft Internet Explorer, Microsoft Visual Basic, Microsoft Word, Delphi и многие другие. Типовая структура контейнера элементов управления представлена на рис. 7.2.

П одобно тому, как элементы управления ActiveX не обязаны поддерживать все стандартные интерфейсы, контейнеры также не должны обеспечивать возможность применения любого компонента ActiveX. Если приложение способно реализовать лишь малую часть возможностей компонента ActiveX, например его визуализацию и реакцию на действия пользователя, то оно уже является контейнером. Перечень базовых интерфейсов для контейнеров ActiveX представлен на рис. 7.2, а описание наиболее часто использующихся в них интерфейсов – в табл. 7.3.

Для того чтобы элемент управления ActiveX мог быть использован каким-либо приложением, он должен быть зарегистрирован на данном компьютере. При установке элементы управления ActiveX заносят сведения о себе в системный реестр.

Свои функции контейнеры также реализуют, предоставляя методы стандартных интерфейсов.

Таблица 7.3. Базовые интерфейсы элементов для контейнеров ActiveX
Интерфейс	Описание
IAdviseSink	Дает возможность контейнеру отслеживать изменения в элементах управления, связанных документах и т. д.
IOleClientSite	Предоставляет присоединенным объектам информацию о ресурсах контейнера
lOleDocumentSite	Применяется для активизации документов OLE
IOlelnPlaceSite	Управляет взаимодействием между контейнером и сайтом своего элемента управления
IOleUIObjInfo	Предоставляет информацию об элементах управления контейнера для использования в диалоговых окнах настройки свойств контейнера

Предоставление методов. Все стандартные интерфейсы контейнеров и компонентов ActiveX являются интерфейсами диспетчеризации и происходят от IDispatch. Соответственно любые вызовы методов элементов управления из контейнера выполняются методом Invoke интерфейса IDispatch. Таким образом, контейнер использует только интерфейс IDispatch и ничего кроме.

Для получения информации о методах диспинтерфейсов контейнер обращается к библиотеке типов, предоставляемой элементом управления.

События. Реагируя на действия пользователя, элемент управления ActiveX посылает контейнеру информацию о событиях, предоставляя тому возможность реагировать на них. При возникновении события элемент управления просто-напросто вызывает необходимый метод контейнера. В этом случае контейнер предоставляет свои интерфейсы, а элемент действует как клиент. Чтобы эта простая схема заработала, элемент управления должен иметь ссылку на интерфейс контейнера.

Каждому событию элемент управления должен поставить в соответствие метод интерфейса контейнера. Набор таких методов называется исходящим интерфейсом. Любые же обычные интерфейсы называются входящими. Однако в этом случае полный, хорошо написанный контейнер должен иметь методы на все случае жизни, для любых типов компонентов. Очевидно, что такой способ реализации был бы крайне неэффективен.

Следовательно, элементы управления ActiveX обязаны предоставить контейнеру библиотеку типов с описанием интерфейсов - как входящих, так и исходящих. Получив информацию о своих методах, используемых элементом ActiveX в исходящих интерфейсах, контейнер должен динамически создать реализацию метода IDispatch.invoke, поддерживающую эти методы.

Свойства. Поскольку элементы управления ActiveX используют диспинтерфейсы, они могут использовать свойства интерфейсов. Для свойства могут быть определены два метода - метод чтения и метод записи. Эти методы, так же как и любые другие методы диспинтерфейсов, вызываются методом IDispatch.Invoke.

Страницы свойств. Для стандартизации визуального представления свойств элементов управления ActiveX в них реализованы страницы свойств. Страницы свойств представляют собой совокупность объектов, умеющих отображать значения свойств элемента управления в виде диалогового окна с многостраничным блокнотом.

Если элемент управления поддерживает интерфейс iSpecifyPropertyPages, то при помощи единственного метода GetPages этого интерфейса контейнер может узнать о свойствах, предоставляемых элементом. После этого контейнер специально для отображения страницы свойств создает объект-рамку. Затем объект-рамка создает объекты-вкладки свойств. Каждый такой объект будет соответствовать одной странице блокнота диалогового окна страниц свойств.

Объект-рамка и объект-вкладка взаимодействуют друг с другом при помощи пары интерфейсов: первый предоставляет интерфейс iPropertyPageSite, а второй - интерфейс IPropertyPage.

Если пользователь изменил значение свойства в диалоговом окне страниц свойств, соответствующий объект-вкладка обеспечивает передачу нового значения элементу управления.

Лицензирование. Для элементов управления ActiveX, также как и для обычных приложений, остро стоит проблема незаконного использования. Снять остроту этой проблемы и призвано лицензирование.

При создании элемента управления для него генерируется лицензионный ключ, который сохраняется в файле с расширением LIC. Это статический способ создания ключа.

Если же элемент управления загружается из Internet, то для него создается пакетный файл лицензионного ключа (расширение LPK). Ссылка на такой файл должна быть включена в соответствующую страницу HTML. При открытии страницы браузер загружает пакетный файл, получает ключ и сравнивает его с имеющимся. Такой метод лицензирования называется динамическим.

При создании экземпляра элемента управления контейнер проверяет наличие лицензии на использование этого элемента на данной машине при помощи методов интерфейса iclassFactory2.

Метод GetLicinfo проверяет наличие глобальной лицензии. Если она есть, то все в порядке и элемент создается обычным образом. Если нет, контейнер обязан вызвать метод createinstanceLic, в который в качестве параметра должен передаваться номер лицензии. Фабрика класса элемента управления проверяет лицензионный ключ и в случае успеха создает экземпляр компонента.

Для того чтобы получить лицензионный ключ, используемый в вышеописанном методе, контейнер должен вызвать еще один метод - RequestLicKey, который возвращает искомый ключ (если он, конечно, есть).