Рассмотрим более предметно схему генерации и обработки событий, принятую в CA-Visual Objects.

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

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

при выборе пользователем из меню какого либо варианта (независимо от того, осуществлен выбор с помощью клавиатуры или мышки);

при “нажатии” пользователем с помощью мышки кнопки, изображенной на панели управления окна;

при нажатии пользователем клавиш-акселераторов;

при “нажатии” пользователем командной кнопки, изображенной в рабочей области окна.

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

Определяется идентификатор события (который назначается разработчиком в виде одного из свойств всем объектам, способным генерировать командные события).

Вначале в программе ищется подкласс окон, имя которого совпадает с идентификатором командного события. Если такой подкласс определен разработчиком, то автоматически создается и отображается на экране новое окно данного подкласса.

Если такого подкласса нет, диспетчер пытается найти подкласс отчетов с тем же именем.

Если и такого подкласса нет, диспетчер приступает к поиску метода с аналогичным именем для окна, которому принадлежит данный управляющий элемент.

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

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

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

Поясним сказанное на примере. Допустим, пользователь работает в дочернем окне “Расходная накладная: корректировка" приложения “Корпорация SuperStocks: запасы и взаиморасчеты" (рис.1.16). Разработчик присвоил подклассу таких окон имя DocsOut. Предположим также, что в процессе корректировки отображаемой в дочернем окне накладной ему потребовалось уточнить содержание картотеки учета товарно-материальных ценностей. Для этого он в меню “Файлы” выбирает вариант “Картотека". Пусть разработчик данного приложения связал этот вариант с командным событием Cards. В этом случае диспетчер приложения вначале попытается отыскать в работающей программе описание оконного подкласса с тем же именем. Если разработчик предусмотрел подкласс таких окон, то система времени исполнения автоматически создает экземпляр этого окна, отображает его поверх окна “Расходная накладная: корректировка”и делает активным (рис.1.17). Новое окно с названием “Картотека” имеет собственные меню и элементы управления и полностью готово к работе.

Вернемся к окну, изображенному на рис.1.16, и рассмотрим другой вариант. Пусть теперь пользователь вместо выбора из меню того или иного варианта “нажмет" командную кнопку “Отказ” в правом нижнем углу этого окна. Допустим, разработчик связал эту кнопку с командным событием CancelButton, и по замыслу нажатие этой кнопки должно приводить к отказу от всех сделанных в базе данных изменений и закрытию окна “Расходная накладная: корректировка". Для этого он разработал метод с именем CancelButton () в классе окон DocsOut. После “нажатия” клавиши “Отказ” диспетчер программы попытается найти сначала подкласс окон с именем CancelButton. Потерпев неудачу, диспетчер попытается далее найти подкласс отчетов с тем же именем. Не найдя отчета “CancelButton", диспетчер приступит к поиску метода CancelButton () в классе активного окна (DocsOut). Теперь ему будет сопутствовать удача, поскольку в данном классе метод с таким именем предусмотрен разработчиком. Отыскав метод, диспетчер запустит его на выполнение.

Рис.1.16. Пример окна “Расходная накладная... ”

Рис 1.17. Пример окна “Картотека"