Управляющие элементы ActiveX

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

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

Точка зрения конечног о пользователя

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

Все чаще и чаще то, что пользователь видит единым целым, на самом деле является контейнером с управляющими элементами ActiveX. Контейнер управляющих элементов подобен контейнеру составных документов OLE, но поддерживает несколько дополнительных интерфейсов для работы с управляющими элементами ActiveX. Каждый управляющий элемент подключен к контейнеру и обычно представляет свой собственный пользовательский интерфейс как внедренный объект, поддерживающий активизацию "на месте". Например, кнопка на экране может быть пользовательским интерфейсом некоего управляющего элемента ActiveX. Щелкая ее и взаимодействуя с исполняющимся в результате кодом, пользователь фактически активизирует элемент управления ActiveX. To, что пользователь видит как одно приложение, представляющее один интегрированный пользовательский интерфейс, на самом деле - контейнер управляющих элементов, полный различных дискретных управляющих элементов ActiveX, каждый из которых выполняет часть общей работы.

Точка зрения разработчика п риложения

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

Чтобы при создании приложения использовать управляющие элементы, разработчик вначале должен принять решение относительно их контейнера . В числе популярных инструментов создания контейнеров Microsoft Visual Basic и Developer Studio и множество других средств третьих фирм. Кроме того, в качестве контейнера можно использовать средство просмотра WWW, при этом управляющий элемент должен быть встроен в HTML-файл.

Затем следует решить, какие управлющие элементы ActiveX включить для обеспечения предполгаемых функциональных возможностей . В состав Visual Basic и Developer Studio входит множество управляющих элементов, так что программист без труда найдет нужный. Если нет, то проблему решит большой и быстро растущий рынок управляющих элементов ActiveX третьих фирм, где представлена продукция сотен компаний.

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

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

В дополнение к своим свойствам управляющий элемент обычно определяет набор событий (events). Посылка и прием этих событий осуществляется с помощью механизма на основе СОМ, но как именно это происходит, для разработчика, собирающего данное приложение, значения не имеет.

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

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

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

Точка зрения создателя управляющего эле мента

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

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

• обеспечение пользовательского интерфейса;
• обеспечение вызова методов управляющего элемента контейнером;
• посылка событий контейнеру;
• получение информации о свойствах среды контейнера и обеспечение доступа к свойствам управляющего элемента и их модификации.

Использование готовых компонентов и элементов управления

Developer Studio позволяет в полной мере взаимодействовать с миром OLE-объектов и реализовывать все виды работ с OLE-объектами. Рассмотрим подробнее использование элементов управления ActiveX. Их поведение и использование аналогичны элементам управления Windows. Можно использовать как готовый, созданный кем-либо OLE-элемент управления, так и создавать собственные для последующего его использования в других приложениях.

Галерея компонентов и элементов управления

Сначала рассмотрим способ хранения OCX-объектов - своего рода библиотеку, где можно найти подходящий для определенных целей объект. Такой библиотекой является галерея компонентов и элементов управления (Component and Controls Gallery) - вид визуальной библиотеки, использующей классификацию хранимых в ней программных компонентов, которые можно задействовать в приложениях, разработанных в среде Visual C++. Компоненты хранятся по категориям. Например, OLE-элементы управления хранятся в категории Registered ActiveX Control (OLE-Controls). В качестве компонентов выступают классы (возможно вместе с необходимыми ресурсами), элементы управления ActiveX (OCX) , а также сложные компоненты . Компоненты можно включать в создаваемое приложение и использовать по своему усмотрению.

Некоторые компоненты, расположенные на странице компонент Microsoft, дублируют возможности приложения, которыми можно управлять в ходе создания приложения средствами MFC AppWizard. Поэтому, например, если во время начального создания проекта приложения не было указано, что приложение будет работать с сокетами Windows, то вместо кропотливого исправления проекта вручную можно просто добавить в него компонент Windows Sockets.

При работе с галереей можно создать собственную категорию, переименовать ее, добавлять или перемещать компоненты из одной категории в другую. При удалении компонента из галереи файлы, содержащие его, не удаляются. Их удаление при необходимости проводится вручную

Компонент можно добавить в галерею четырьмя способами:

Основное назначение галереи компонентов в том, что она позволяет вставлять в новый проект хранящиеся в нем компоненты. Рассмотрим общую схему добавления компонентов в проект, уделяя основное внимание вставке OLE-элемента управления:

• открыть проект, в который необходимо добавить компонент;
• войти в галерею, выбрать нужную категорию и компонент;
• при помощи кнопки 'Insert' добавить компонент в проект. В зависимости от типа компонента предварительно может появиться окно с дополнительной информацией. Для OLE-элемента управления будет выведено окно, где указаны классы, которые будут добавлены в проект для обеспечения взаимодействия проекта и добавляемого элемента управления

Когда в проект добавляется OLE-элемент управления (OCX-объект), галерея компонентов выполняет следующие действия: проводит регистрацию незарегистрированного элемента управления в базе данных Windows для OLE-элементов управления; добавляет инструментальную кнопку, соответствующую данному элементу, в панель инструментов редактора диалога (так что наряду с кнопками элементов управления Windows, на панели инструментов появится новая кнопка, задающая OLE-элемент управления; добавляет в проект классы, определяющие свойства и поведение OLE-элемента управления.

Испол ьзование управляющих элементов в приложении

Чтобы использовать в проекте уже созданные OLE-элементы управления, необходимо понимать, как создать проект, допускающий встраивание OCX-объектов, и как добавить в проект эти элементы.

Первая задача решается остаточно просто. Чтобы проект мог использовать OLE-элементы управления, на шаге работы AppWizard, где речь идет о поддержки OLE, следует включить флажок 'OLE controls'. Это же свойство можно добавить и в уже созданный, работающий проект. Для этого в начало работы метода InitInstance() главного класса приложения следует вписать вызов AfxEnableControlContainer(). В файл stdafx.h включить строку #include <afxdisp.h>.

О том как добавлять OCX-объекты в проект приложения, было рассказано в пункте 'Вставка компонентов в проект приложения'.

Предположим, что создан проект, допускающий использование OCX-объектов, а в галерее компонентов выбраны подходящие OLE-элементы управления, добавленные в проект. Возникает ряд вопросов: как использовать эти объекты и ведут ли они себя так же, как и обычные элементы управления Windows?

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

При проектировании диалогового окна в нем, кроме обычных элементов управления, размещаются и OLE-элементы управления. Для них точно также открывается страница свойств, и на этапе проектирования можно задать нужные значения тех или иных свойств элемента. Средство ClassWizard позволяет связать элемент управления с объектом соответствующего класса (который добавляется в проект при встраивании OCX-элемента), а также создать обработчики сообщений для OLE-элемента управления точно так же как и для обычных элементов управления. Итак, работать с OCX-объектами можно точно так же как и с обычными элементами управления Windows.