Глава 26. Создание элемента управления ActiveX

• Создание проекта
• Главный класс модуля OCX-объекта
• Класс OLE-элемента управления
• Класс страницы свойств OLE-элемента управления
• Добавление нового свойства
• Типы свойств
• Добавление свойств
• Добавление нового метода
• Методы автоматизации
• Добавление различных методов
• Добавление нового события
• Типы событий
• Добавление события
• Корректировка страниц свойств
• Связь данных

OLE-элементы управления создаются в проектах специального типа. Каркас приложения подготавливается при помощи инструментального средства MFC ActiveX ControlWizard (OLE ControlWizard), а затем в него добавляется код, определяющий специфику элемента. На втором этапе широко применяется средство ClassWizard.

Средство ControlWizard создаст совокупность файлов, имена которых по умолчанию строятся с использованием имени проекта. К примеру, для проекта Name (все опции которого выбираются по умолчанию), создаются следующие основные файлы (см. Приложение 4 ):

NameCtl.h, NameCtl.сpp - объявляют и реализуют класс CNameCtrl, производный от базового класса COleControl из библиотеки MFC. Он определяет базовые свойства и поведение OCX-объектов.

Name.h, Name.cpp - необходимы для инициализации DLL-файла, содержащего OCX-объект Name Control , его выгрузки и выполнения других инициализационных функций. Они определяют класс CNameApp, производный от COleControlModule. Методы InitInstance() b ExitInstance() этого класса создают экземпляр класса, регистрируют и инициализируют элемент управления.

NamePpg.h, NamePpg.cpp - определяют класс CNameProgPage, задающий базовую страницу свойств элемента управления.

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

Name.rc, Resource.h - файл ресурсов проекта и его заголовочный файл.

Name.odl - содержит исходный код на языке описания объекта (Object Description Language), по которому Visual C++ генерирует доступную для других клиентов OLE Automation библиотеку типа, содержащую интерфейс элемента управления. Odl-файл элемента управления представляет собой исходный текст библиотеки типов элемента управления. Этот файл преобразовывается утилитой Make Type Library (mktypelib.exe) в библиотеку типов (файл с расширением tlb), которая будет в виде ресурса включена в ocx-файл.

Файл Name.h является основным файлом заголовков для элемента управления Name Control , в нем объявляется класс CNameApp. Этот класс является потомком класса COleControlModule , а не класса CWinApp. Это справедливо обычно для всех элементов управления, построенных на основе MFC.

Класс же COleControlModule библиотеки MFC в свою очередь просто является производным от класса CWinApp , в котором для удобства переопределены методы InitInstance и ExitInstance .

Файл Name.cpp - это основной исходный файл для элемента управления Name Control. Функциями этого файла являются: регистрация элемента управления; обеспечение инициализации элемента управления; удаление регистрации элемента управления, когда он больше не нужен.

В этом файле происходит создание глобального объекта класса CNameApp, порожденного от класса ColeControlModul e. В проекте может быть только один объект приложения, т.е. один объект класса, порожденного от COleControlModule .

MFC ActiveX ControlWizard сгенерировал GUID (уникальный идентификатор) для библиотеки типов элемента управления с именем _tlid и принял, что старший номер версии библиотеки равен 1, а младший номер – 0. Эта информация будет записана в реестр во время выполнения макроса INPLEMENT_OLETYPELIB , находящего в NameCtl.cpp.

Файл Name.cpp содержит реализацию методов класса CNameApp. Метод InitInstance отвечает за инициализацию DLL-файла: Он вызывается системой при первой загрузке элемента управления в память. Также этот метод вызывается при создании каждого экземпляра Name Control. В этом методе можно выполнить собственные методы инициализации, однако необходимо всегда в первую очередь вызвать метод InitInstance базового класса COleControlModule .

Метод ExitInstance вызывается непосредственно перед тем, как элемент управления выгружается из памяти, и очищает память, освобождает дескрипторы, удаляет GDI-объекты и т.д:

В файле Name.cpp кроме методов класса CNameApp определены две функции: DllRegisterServer (заносит данные в системный реестр) и DllUnregisterServer (удаляет данные из системного реестра):

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

При вызове функция DllRegisterServer выполняет следующие действия. Сначала она регистрирует библиотеку типов элемента управления посредством вызова функции AfxOleRegisterTypeLib. (Этот этап включает создание и обновление параметров элемента управления в ключе HKEY_CLASSES_ROOTTypeLib. Исходный файл библиотеки типов автоматически генерируется MFC ActiveX ControlWizard. В нем описываются свойства, методы, события элемента управления и специфическая для данного класса информация). Затем функция DllRegisterServer регистрирует все фабрики классов данного приложения в системном реестре посредством метода COleObjectFactoryEx::UpdateRegistryAll . ( Фабрика классов представляет собой COM-объект, реализующий интерфейс IClassFactory и отвечающий за производство COM-серверов заданного типа (CLSID). Библиотеки OLE не могут создавать серверы без участия фабрики классов. Понятие фабрики классов рассматривается при исследовании файла NameCt l.cpp.)

При компиляции элемента управления с использованием Microsoft Developer Studio последнее, что делает программа, - это вызывает функцию DllRegisterServer , что приводит к автоматической регистрации элемента управления на данной машине. Если необходимо инсталлировать элемент управления на другой машине, нужно каким-то образом вызвать его функцию DllRegisterServer . Обычно это делает регистрационная программа, которую необходимо предоставить. Зарегистрировать OCX-объект можно и при помощи утилиты regsvr32.exe, которая обычно находится в каталоге C:WINDOWSSYSTEM.

Функция DllUnregisterServer является дополнением к функции DllRegisterServer . Элементы управления OLE самостоятельно удаляют свою регистрацию. Это значит, что библиотека типов, фабрика классов и информация об элементе может быть автоматически удалена из системного реестра. Функция DllUnregisterServer не вызывается автоматически из Developer Studio. Ее должны вызывать исключительно внешние функции или приложения, которые хотят полностью удалить элемент из системы. Например, эту функцию могла бы вызвать программа деинсталляции.

Макрос AFX_MANAGE_STATE встречается в функциях DllRegisterServer и DllUnregisterServer . Этот макрос необходим некоторым методам управления OLE для выполнения переключения состояния модуля.

Однако при подключении DLL-файлов, использующих библиотеку MFC (как в случае элементов управления OLE), могут возникать проблемы. Каждый элемент управления сохраняет свою информацию о состоянии. Когда поток выполнения “входит” в элемент управления, последний должен сообщить MFC о том, что наступила его очередь выполняться и следует изменить указатель на набор данных о состоянии так, чтобы он указывал на набор данных элемента управления. Элемент управления делает это с помощью макроса AFX_MANAGE_STATE . Такая переадресация должна происходить во всех точках входа в DLL, то есть во всех функциях, экспортируемых библиотекой, поскольку именно там она получает управление.

Поскольку все элементы управления OLE экспортируют функции DllRegisterServer и DllUnregisterServer , тоне удивительно, что первым оператором в теле обеих функций является макрос AFX_MANAGE_STATE. Если не выполнить изменение состояния, результат работы программы может быть непредсказуемым. Наличие такого макроса в функциях, которые не экспортируются, необязательно.

Класс OLE-элемента управления объявлен в файле NameCtl.h и реализуется в файле NameCtl.cpp. Базовый класс элемента управления наследуется от класса COleControl - стандартного базового класса библиотеки MFC, который используется элементами управления OLE. Этот класс, будучи потомком класса CWnd , наследует все функции объекта окна, а также располагает дополнительными, специфическими для OLE функциями, такими как генерация событий и поддержка методов и свойств OLE-элемента управления.

В классе COleControl реализованы все интерфейсы, необходимые для работы элемента управления. Он скрывает детали реализации элемента и имеет понятный, объектно-ориентированный интерфейс, который используется элементами управления при выполнении собственных функций.

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

Класс CNameCtrl переопределяет некоторые методы базового класса: OnDraw, DoPropExchange, OnResetState . Метод OnDraw вызывается операционной системой, когда элемент управления должен быть перерисован.

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

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

Макрос DECLARE_OLECREATE_EX (CNameCtrl) объявляет фабрику классов и метод GetClassID для класса элемента управления. Метод GetClassID (объявляемый в этом макросе) вызывается системой, когда ей необходимо получить CLSID элемента. CLSID используется библиотеками OLE для регистрации, создания элемента управления и т.д.

Фабрика классов представляет собой OLE-объект, который используется для производства экземпляров других объектов. Фабрики классов элемента управления располагаются внутри OCX-файла, вместе с самим элементом. Библиотека MFC сама обеспечивает реализацию фабрики классов (разработчику не нужно о ней беспокоиться). В основном фабрика классов реализована в базовом классе COleObjectFactoryEx . Фактически конструктор фабрики классов для элемента управления просто передает свои параметры базовому классу, в котором скрыты детали реализации.

Инициализация фабрики классов элемента управления и формирование GUID (CLSID) производятся в файле реализации. Эти действия выполняет макрос IMPLEMENT_OLECREATE_EX . В этом макросе реализуется фабрика классов элемента управления и метод GetClassID. Фабрика классов создает экземпляры элемента управления. Метод GetClassID возвращает CLSID элемента всем, кто его запрашивает, например библиотекам OLE.

В объявлении класса присутствует макрос DECLARE_OLETYPELIB (CNameCtrl), который объявляет метод GetTypeLib для класса элемента управления.. Этот макрос должен присутствовать в файле заголовков элемента управления.

Метод GetTypeLib элемента управления реализуется макросом IMPLEMENT_OLETYPELIB в файле реализации класса. Библиотека типов представляет собой файл, содержащий информацию о типе элемента управления, его интерфейсах и элементах автоматизации (к ним относятся свойства, методы и события). Сгенерированный метод GetTypeLib вызывается системой, когда ей нужна информация о библиотеке типов элемента. Эти данные сравниваются с данными из системного реестра, и если обнаруживается совпадение, то информация передается системе .

Элемент управления OLE использует страницы свойств, чтобы дать пользователю возможность просматривать и изменять свойства элемента управления. Страницы свойств реализуются в виде диалоговых окон с закладками (tabs). В макросе DECLARE_PROPPAGEIDS (CNameCtrl) объявляются идентификаторы и методы, используемые этим механизмом.

Макрос DECLARE_OLECTLTYPE (CNameCtrl) объявляет методы, которые обрабатывают информацию о типе элемента и данные флагов MiscStatus.

Информация о типе элемента управления записана в переменной типа const с именем _dwNameOleMisc А макрос IMPLEMENT_OLECTLTYPE в реализации класса определяет два метода элемента управления GetUserTypeNameID и GetMiscStatus . Метод GetUserTypeNameID возвращает идентификатор ресурса строки (константа IDS_Name), содержащей имя типа элемента управления. Метод GetMiscStatus вызывается внешними объектами, например контейнером, для получения информации об элементе управления. Значения, записанные в переменной _dwNameOleMisc, генерируются при создании проекта и являются выбором установок проекта.

Строки файла реализации класса, объявляющие IID_Dname и IID_DNameEvents определяют идентификаторы интерфейсов элемента управления. Первый из них идентифицирует реализацию IDispatch - базовый интерфейс диспетчеризации класса. Этот интерфейс используется клиентами автоматизации для редактирования и просмотра элемента управления и выполнения его методов. Второй идентификатор определяет интерфейс диспетчеризации событий класса. Этот интерфейс используется элементом управления для генерации событий. Оба идентификатора хранятся в системном реестре в ключе HKEY_CLASSES_ROOTInterface.

Класс CNameCtrl c помощью макроса DECLARE_MESSAGE_MAP объявляет привычную уже таблицу сообщений (схему сообщений) класса, при помощи чего сообщает системе, что класс будет обрабатывать сообщения. Сама таблица сообщений объявляется в файле реализации класса.

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

Сначала схема диспетчеризации в файле реализации имеет одну запись, сделанную при помощи макроса DISP_FUNCTION_ID , который связывает между собой следующие элементы: имя класса; внешнее имя метода; идентификатор (DISPID) метода; метод C++, соответствующий вызову метода автоматизации; список параметров метода (тип VARIANT); тип значения, возвращаемого методом (тип VARIANT). Эта информация необходима системе для того, чтобы направлять вызовы методов автоматизации по правильному пути. Когда контроллер автоматизации вызывает метод при помощи его внешнего имени, такой вызов преобразуется в вызов внутренней функции элемента управления. В основе этого механизма лежит DISPID. Каждому объявленному свойству или методу должен соответствовать свой макрос в схеме диспетчеризации класса.

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

Класс страницы свойств CNamePropPage объявляется в файле NamePpg.h. Этот класс сгенерирован при создании проекта. Он реализует одну пустую страницу свойств. Этот класс является прямым потомком класса COlePropertyPage , базового класса всех страниц свойств.

Класс CNamePropPage является OLE-объектом. Поэтому ему необходима фабрика классов, генерацию которой обеспечивает макрос DECLARE_OLECREATE_EX. Фабрика классов и генерация CLSID для класса страницы свойств реализована в файле NamePpg.cpp при помощи макроса IMPLEMENT_OLECREATE_EX.

Добавление и удаление записей из системного реестра для класса CNamePropPage производится в методе UpdateRegistry фабрики классов. Этот метод фабрики классов регистрирует либо снимает регистрацию класса CNamePropPage. Это делает страницу свойств доступной для всех OLE-серверов и контейнеров .

Элемент управления может предоставлять свои свойства непосредственно по имени либо с помощью специальных методов чтения/записи, называемых методами свойств (properties methods).

Свойства бывают следующих типов: базовые (stock), внешние (ambient), расширенные (extended) и пользовательские (custom).

Базовыми называются свойства, определенные фирмой Microsoft. Это набор характеристик, которые обычно свойственны всем элементам управления независимо от их типа и выполняемых функций (например, цвет фона). Следует отметить, что элемент управления не обязан поддерживать базовые свойства. Любой элемент, который хочет реализовать базовые свойства, может использовать для доступа к ним стандартные имена и DISPID, определенные фирмой Microsoft, а также методы чтения/записи класса COleControl (например, GetBackColor и SetBackColor ). Эти методы могут быть вызваны как из самого элемента управления, так из внешнего объекта с помощью средств автоматизации.

В классе COleControl есть несколько специальных методов, сообщающих элементу об изменении его базовых свойств ( OnBackColorChanged, OnBorderStylerChanged, OnEnabledChanged, OnFontChanged,OnForeColorChanged, OnTextChanged ). Данные методы объявлены виртуальными, поэтому их можно спокойно изменять. Это следует делать в том случае, если элементу необходимо отслеживать изменения базовых свойств и реагировать на них.

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

Расширенными свойствами называются такие свойства, которые контейнер связывает с каждым конкретным элементом управления. Обратим внимание на то, что контейнер сам несет ответственность за эти свойства и “подключает” их к каждому элементу по своему усмотрению. Для того, чтобы контейнер мог связать расширенные свойства с элементом управления, он во время встраивания элемента создает небольшой вспомогательный объект, называемый расширенным элементом управления. Посредством механизма агрегации этот объект принимает все вызовы методов свойств элемента управления, что позволяет ему обрабатывать их прежде, чем они попадут к реальному элементу. По существу, расширенный элемент управления является внешней оболочкой элемента управления OLE.

В процессе проектирования OCX-объекта можно добавлять два вида свойств: базовые и пользовательские . Несколько базовых свойств (другое название - стандартные свойства) определены и поддерживаются в базовом классе COleControl. Это общие свойства, пригодные для большинства проектируемых OLE-элементов управления: Appearance - внешний вид (например, 3-мерный или плоский); BackColor - цвет фона; BorderStyle - тиль рамки; Caption - заголовок элемента; Enabled - состояние доступен/недоступен; Font - шрифт при печати заголовка и других сообщений, связанных с элементом управления; ForeColor - цвет переднего плана; hWnd - маркер (дескриптор) окна; ReadyState - состояние готовности; Text - текст, другое название свойства Caption.

Member Variable - реализация свойства предполагает введение в созданный класс элемента управления переменной, видимой в контейнере . Это простейший способ реализации. Однако чаще применяются три следующих, когда наряду с переменной создаются и другие элементы класса;

Member Variable With Notification - наряду с переменной создается специальная функция уведомления . Она автоматически вызывается в каркасе приложения всякий раз при изменении значения свойства, что позволяет элементу управления должным образом отреагировать на изменение своего свойства - например, организовать свою перерисовку;

Set/Get Methods - предполагает защищенный доступ к переменной класса, задающей свойство. Хотя сама переменная будет не видима в контейнере, здесь будут доступны автоматически построенные методы Get и Set . Первый позволяет прочитать значение, второй - задать новое значение свойства. Кроме защищенности свойства, этот способ удобен тем, что позволяет организовывать дополнительные вычисления, например, в методе Set можно произвести проверку, разрещающую или запрещающую изменение свойств;

Parameterized - параметризированная реализация применяется, когда переменная класса должна быть массивом и свойство задается не единственным скалярным значением, а совокупностью значений. Эта реализация предполагает построение методов Get и Set. Автоматически эти методы создаются с параметром, включающим индексы элемента массива.

Тип свойства выбирается из списка “Type” при добавлении нового свойства при помощи средства ClassWizard. В этом списке, как правило, указываются не типы OLE, а совместимые с ними типы, например тип short, который автоматически транслируется в тип I2. Однако в списке “Type” есть и OLE-типы, например, типы BSTR и OLE_COLOR.

• В поле “Class name” необходимо выбрать имя класса элемента управления, производного от COleControl. Напомним, что производные классы наследуют от базового класса его данные и методы. Так все OLE-элементы управления могут использовать открытые для них методы базового класса COleControl.
• При помощи кнопки “Add Property” вызвать диалоговое окно для добавления свойств.
• Для пользовательских свойств в окно комбинированного списка “External Name” ввести его имя, а для базовых - выбрать имя из этого списка.
• В группе “Implementation” для пользовательских свойств включить один из переключателей: “Member Variable” или “Get/Set”. Для базового свойства будет автоматически выбран переключатель “Stock”. Выбор “Member Variable” задает два первых способа реализации свойства. По умолчанию предлагается второй способ с построением функции уведомления. Если отказаться от нее, то реализуется первый способ. Выбор переключателя “Get/Set” задает третий и четвертый способы реализации свойства. Ввод информации в окне “Parameter List” означает выбор параметризированного свойства, и тогда параметры методов Ge t и Set будут включать индексы элемента массива, задающего свойство.
• Из списка “Type” следует выбрать тип свойства. Для базовых свойств тип задается автоматически.
• Задав все характеристики, следует подтвердить создание нового свойства, выбрав кнопку “Ok”.

Для пользовательского свойства, при добавлении которого был включен переключатель “Member Variable” , ClassWizard вставит в файл CNameCtl.h описание переменной класса и заголовок функции уведомления (если не было отказа). Созданная переменная, кстати, будет видима в контейнере , который будет содержать OLE-элемент управления. Остов функции уведомления создается и вставляется в файл CNameCtl.cpp. Тело функции содержит единственный вызов SetModif iedFlag().

Для пользовательского свойства, при добавлении которого был включен переключатель “Get/Set methods” , ClassWizard создаст и добавит в h- и cpp-файлы заголовки и остовы этих методов. В процессе добавления свойств можно отказаться от одного из этих методов, и тогда свойство будет предназначаться “только для чтения” или “только для записи”.

Следующая важная часть работы ClassWizard - формирование раздела DISPATCH_MAP (раздела схемы диспетчеризации) в файле NameCtl.cpp. Для каждого пользовательского или базового свойства добавляется соответствующий макрос. Для базовых свойств добавляется один из макросов с префиксом DISP_STOCKPROP_ в соответствии с задаваемым базовым свойством. Для пользовательских свойств добавляемый макрос зависит от способа реализации свойства. Каждому из четырех способов реализации соответствует свой макрос: DISP_PROPERTY(), DISP _PROPERTY_NOTIFY(), DISP_PROPERTY_EX(), DISP_PROPERTY_PARAM(). Параметрами макросов являются имя класса и свойства, тип свойства, и, в зависимости от типа макроса, имена переменной класса и функции уведомления или имена Get и Set методов.

В классе CNameCtrl построен остов метода DoDropExchange - аналог метода DoDataExchange класса диалоговых окон. Этот метод вызывается всякий раз, когда OLE-элемент управления создается, читается или записывается в файл на диск. В ее тело для каждого свойства можно добавить вызов метода с префиксом PX (Propertiy eXchange) - аналог DDX-метода.

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

Методы реализуются в виде обычных методов C++. Ограничением является лишь то, что типы параметров и возвращаемых значений должны поддерживать механизм транспортировки (marshaling). Следует помнить, что смысл автоматизации заключается в том, что она позволяет одной программе управлять работой другой программы. Чтобы обеспечить поддержку автоматизации , следует использовать типы семейства VARIANT (VT_xxx).

Методы автоматизации делятся на две основные категории: базовые и пользовательские. Фирма Microsoft определила и реализовала ряд базовых методов автоматизации. Refresh (заставляет элемент перерисовать себя), DoClick (имитирует щелчок мышью на элементе управления) и AboutBox() (отображает на экране модальное диалоговое окно “About” элемента управления). Все эти методы имеют отрицательные DISPID.

События можно разделить на несколько видов: базовые события (stock events); события-запросы (request events); события-предупреждения (before events); события-следствия (after events); события-директивы (do events). Независимо от вида, все события различаются по имени и идентификатору (DISPID). Для каждой группы событий действуют свои соглашения о правилах присвоения имен, последовательности вызовов и т.п. Однако, по существу, все события одинаковы. Все они генерируются (или порождается) элементом управления и через точку соединения попадают в контейнер. Получив событие, контейнер реагирует на него по своему усмотрению.

Так же как и у базовых свойств, у базовых событий есть заранее определенные имена и идентификаторы (DISPID). Приведем список всех базовых событий (их смысл понятен из названия): Click, DblClick, KeyDown, KeyPress, KeyUp, MouseDown, MouseMove, MouseUp, Error . В классе COleControl для генерации событий существуют методы, предназначенные для генерации всех базовых событий, их имена начинаются с Fire (например, FireClick ). Для генерации пользовательских событий применяется методв FireEvent . (Пользовательскими называются события, которые сам программист добавляет к элементу управления. Они отличаются от базовых свойств тем, что класс ColeControl не генерирует их автоматически и не имеет стандартных методов оповещения, которые позволяют отслеживать их возникновение).

В классе ColeControl имеется ряд методов оповещения , вызываемых библиотекой MFC при генерации базовых событий: OnClick, OnKeyDownEvent, OnKeyPressEvent, OnKeyUpEvent . Эти методы являются виртуальными, поэтому элемент управления также может перехватывать события и самостоятельно их обрабатывать.

По умолчанию, последним параметром методов, генерирующих события-запросы, является ссылочная переменная типа CancelBoolean (тип данных, определенный в OLE). Эта переменная традиционно имеет имя Cancel , а ее значение указывает, должен ли элемент управления отвергнуть запрошенное действие (Cancel=TRUE) или выполнить его (Cancel=FALSE).

Во время события-запроса происходит следующее. OLE-элемент-управления устанавливает значение переменной Cancel в FALSE, тем самым давая знать контейнеру, что он должен что-то сделать. Элемент управления генерирует событие, вызывая соответствующий метод автоматизации в формате Request <Action> , где <Action> - запрошенное действие. Контейнер, в зависимости от запроса и текущего состояния системы, устанавливает значение параметра Cancel в TRUE (заставляя элемент управления отменить действие) или FALSE (разрешая элементу управления выполнить действие). Когда метод, сгенерировавший событие, завершается, OLE-элемент управления проверяет значение параметра Cancel и предпринимает соответствующие действия.

В соответствии с соглашением, имена методов, генерирующих события-предупреждения, имеют следующий вид: Before <Action>, где <Action> - действие, которое собирается предпринять элемент управления OLE (например, метод BeforeClose()).

Имена методов, генерирующих события-директивы, должны соответствовать следующему соглашению: Do <Action>. Последним параметром методов, генерирующих события-директивы, является булева переменная EnableDefault . Элемент управления устанавливает ее значение в TRUE и вызывает метод. Получив событие, контейнер может в ответ предпринять некоторые действия. Затем он устанавливает значение переменной EnableDefault в TRUE или FALSE, в зависимости от того, хочет ли он, чтобы элемент управления продолжил обработку события. Когда метод генерации сообщения завершается, элемент управления проверяет параметр EnableDefault. Если он равен TRUE, элемент управления вызывает стандартную реализацию метода, а если FALSE, то не вызывает ее.

При автоматической генерации элемента управления ControlWizard автоматически генерирует одну пустую страницу свойств. Станицы свойств реализуются при помощи класса C++, порожденного от класса COlePropertyPage. Класс COlePropertyPage порожден от класса CDialog и содержит набор функций для взаимодействия с элементом управления.

Страницы свойств бывают двух типов: страницы базовых свойств (stock property pages) и пользовательские страницы свойств (custom property pages).

	BEGIN_PROPPAGEIDS(CNameCtrl, 2)
		PROPPAGEID(CNamePropPage::guid)
		PROPPAGEID(CLSID_CColorPropPage)
	END_PROPPAGEIDS(CNameCtrl)

Для создания новой пользовательской страницы необходимо создать диалоговую панель (отвечающую ранее перечисленным требованиям) и подключить к ней новый класс, реализующий ее работу. Для создания класса страницы свойств используется ClassWizard. При его помощи необходимо создать новый класс, наследуемый от базового класса COlePropertyPage (не СPropertyPage), и включить его в проект элемента управления. Классы, порожденные от COlePropertyPage , наследуют от него CLSID и фабрику классов, сгенерированные MFC. Затем следует добавить идентификатор новой страницы свойств в таблицу страниц элемента управления, не забыв при этом изменить общее число страниц.

Для корректировки пользовательской страницы свойств нужно работать с соответствующей диалоговой панелью, отвечающей именно за эту страницу. Например, ControlWizard сгенерировал для элемента управления Name Control одну пользовательскую страницу свойств “General ”, за которую отвечает диалоговая панель с идентификатором IDD_PROPPAGE_NAME. Можно добавить в нее стандартные элементы управления для манипуляций с теми или иными свойствами OLE- элемента управления. Для реализации этих действий следует присоединить к стандартным полям диалоговой панели страницы свойств переменные (подобно тому, как это делается для обычных диалогов), отметив при этом внешние имена свойств OCX-объекта, за которые отвечают эти переменные.

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

Теперь свойство получило потенциальную возможность уведомление контейнера о своих изменениях. Реализовать эту возможность и превратить связываемое свойство в связанное (bound) свойство можно в процессе работы элемента управления в контейнере. Для этого нужно вызвать один из двух методов BoundPropertyChanged или BoundPropertyRequestEdit . Вызываются эти функции либо в методе Set, либо в функции уведомления.

Связывание называется оптимистическим (optimistic data binding), если вызывается метод BoundPropertyChanged . При этом изменение свойства всегда выполняются, и контейнер только уведомляется о нем. Если вызывается метод BoundPropertyRequestEdit , связывание назывется пессимистическим (pessimistic data binding). Для этого типа связывания изменение значения свойства производится, если только результат вызова функции TRUE, что означает разрешение контейнера на изменение значения.