47992 (Особенности программирования для Windows), страница 4

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

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

1.3.3 Другие типы связей в программах

Помимо связей типа “владение" CA-Visual Objects поддерживает еще четыре их разновидности:

связь по наследованию;

реляционная связь таблиц (файлов) баз данных;

связь окон с серверами данных (связь по использованию);

связь с другими приложениями (связь “клиент-сервер”).

Связь по наследованию

Наследственные связи также играют в CA-Visual Objects чрезвычайно важную роль, поскольку именно через них реализуются мощь и гибкость объктно-ориентированного программирования. Осознанное владение механизмом наследственных связей - ключ к успеху при разработке сложных приложений. Эти связи подробно рассматриваются в главе 3.

Реляционные связи файлов баз данных.

Реляционные связи файлов баз данных получили в CA-Visual Objects свое дальнейшее развитие. Как известно, Clipper в этом плане ограничивается поддержкой только связи типа “1: 1" (“один к одному”), предлагая в качестве инструмента функцию DBSetRelation () (или, что то же, оператор SET RELATION TO). Установка такой связи от одного файла (ведущего) к другому (ведомому) предполагает автоматическое перемещение указателя в ведомом файле при любых навигационных операциях на ведущем при условии, что ведомый файл упорядочен должным образом по соответствующему ключевому полю (полям). Этот простейший вид реляционной связи иллюстрируется на рис.1.18.

Рис.1.18. Типовая схема реляцонной связи “1: 1”

Связь “1: 1" (как и связь "М: 1") является традиционной при программировани на Xbase-языках. Являясь основой для построения сложных реляционных баз данных, она тем не менее предлагает лишь частичное решение задачи: гарантируя автоматическое перемещение указателя к требуемой строке в ведомой таблице, она не накладывает никаких ограничений на ведение операций над этой таблицей. В частности, для нашего примера, эта связь никак не помешает перевести указатель в файле-классификаторе партнеров явным образом, скажем, на одну строку вверх или вниз. Иначе говоря, ответственность за нарушение целостности такой связки целиком лежит на программисте.

Учитывая это, в CA-Visual Objects реализована также поддержка и более мощного типа связей, а именно - связей типа “1: M" (“один ко многим”). Эта связь в CA-Visual Objects получила название селективной или связи “мастер-детали". Селективная связь поддерживается на уровне серверов данных (т.е. на уровне объектов) стандартным методом SetSelectiveRelation (). Установка данной связи от ведущего файла к ведомому гарантирует, что в последнем (при условии его соответствующей упорядоченности) отфильтровываются все записи, значения ключевых полей которых не соответствуют значению управляющих полей в ведущем файле. Ведомый файл как бы усекается до группы последовательных записей с требуемым значением ключа, получая при этом новые логические признаки начала и конца файла. Соответственно, такие операции, как переход в начало файла (GoTop) и в его конец (GoBottom), выполняются в пределах выбранной последовательности. Селективная связь иллюстрируется на рис.1.19:

Рис.1.19. Типовая схема реляционной связи “1: M"

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

Рис.1.20. Пример реализации селективной связи в окне данных CA-Visual Objects

Заметим попутно, что для реализации этого окна в CA-Visual Objects автору пришлось вручную написать всего одну строку программного кода, задающую заголовок таблицы. Все остальное выполнено средствами визуальных редакторов системы!

Связь по использованию

Связь по использованию является одной из “изюминок" CA-Visual Objects. Обеспечивают эту связь чрезвычайно мощные скрытые механизмы системы. Данная связь может устанавливаться только между объектами двух классов: окнами и серверами данных. Суть ее вкратце заключается в том, что окно данных, используя сервер данных, становится как бы его витриной, приобретая при этом не только возможность отображать, добавлять и корректировать содержащуюся в сервере информацию, но и целый набор стандартных операций (методов), характерных только для сервера (например, операции навигации по файлу базы данных).

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

Рис.1.21 Схема взаимодействия сервера и окна данных

Связь по владению реализуется методом Use () окна данных. Использование этого мощного и универсального метода позволяет разработчику сосредоточиться на прикладной логике своей программы и абстрагироваться от множества деталей, связанных с непосредственной работой с файлами. Для примера предположим, что в программе открыт сервер базы данных oServer с полями данных Name и Code и окно данных oWnd с полями ввода, имеющими те же имена. Тогда сказанное можно проиллюстрировать следующим фрагментом программного кода:

Function Test ()

...

// “Привязка" сервера к окну данных

oWnd: Use (oServer)

? oWnd: Name // “Иванов Иван Иванович"

? oWnd: Code // 0034

// Заполнение поле ввода Name новой строкой символов

// прямым присваиванием (то же можно выполнить с клавиатуры)

oWnd: Name: = “Иванов Иван Петрович"

? oWnd: Name // “Иванов Иван Петрович”

// Поле сервера (а значит, и поле файла базы данных)

// также изменилось:

? oServer: Name // “Иванов Иван Петрович”

// Переход к очередной записи:

oWnd: Skip (1)

? oWnd: Name // “Петров Сергей Дмитриевич"

...

Return nil

Однако, мощь связи по использованию этим не ограничивается. Метод Use () позволяет нескольким окнам использовать один и тот же сервер одновременно. Такого рода ситуации в практике программирования возникают довольно часто: например, одно окно служит для отображения в табличной форме информации, записанной в файле, а другое - для корректировки и/или добавления записей в этот файл в бланковой форме. Если оба окна используют один и тот же сервер данных, то любые изменения данных в одном окне автоматически отображаются в другом! Сервер данных и использующие его окна постоянно “общаются" друг с другом, не оставляя без внимания ни одного происходящего с ними события!

Связь “клиент-сервер”

Windows как мультизадачная среда устанавливает механизм общения двух параллельно исполняемых приложений и обеспечивает необходимые для этого средства. Это механизм известен под аббревиатурой DDE (Dynamic Data Exchange - Динамический Обмен Данными). Суть этого механизма состоит в том, что одно приложение, зарегистрировав себя в операционной системе в качестве сервера, способно обслуживать заранее определенные запросы другого приложения, зарегистрировавшего себя в качестве клиента. И наоборот.

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

1.3.4 Как все-таки работает программа в CA-Visual Objects?

Итак, попытаемся теперь, с учетом сказанного, представить потоки управления в типовой программе, написанной в системе CA-Visual Objects. Структурная схема головного модуля такой программы представлена на рис.1.8 Как видно, она довольно проста.

Первое, что в ней делается - это создается объект ShellWnd, принадлежащий классу главных окон приложения. В качестве одного из своих свойств этот объект имеет объект класса меню, свойства которого описаны заранее программистом с помощью специального редактора. Допустим, в объекте-меню есть два подменю с заголовками “Файл" и “Помощь”, при этом подменю “Файл" предлагает на выбор три варианта: “Открыть” (с идентификатором командного события File_Open), “Закрыть” (с идентификатором командного события File_Close) и “Выход” (с идентификатором командного события File_Exit).

Рис.1.22 Структура головного модуля программы

Далее созданное окно отображается на экране, после чего запускается внутренний диспетчер событий. Как уже отмечалось, задача диспетчера состоит в ожидании события (т.е. сигнала от Windows), дешифровке его и инициализации требуемого объекта или метода.

После фактического выполнения описанных трех блоков (кстати, представляемых всего тремя строками программного кода) на экране отобразится окно с панелью меню. Пусть пользователь выберет из меню открывшегося окна с помощью клавиатуры или мышки вариант “Файл-Открыть”. Windows в ответ на это событие пошлет диспетчеру соответствующий сигнал. Диспетчер распознает этот сигнал как событие командного типа и запустит ранее описанный стандартный алгоритм поиска обработчика данного события по его идентификатору File_Open. Если такой обработчик будет найден (в виде дочернего окна или отчета с таким же именем, или метода окна ShellWnd с этим именем), то он немедленно запустится в работу. Пусть под событием File_Open скрывается новое (дочернее) окно. В этом случае оно будет создано и показано на экране. Это окно становится активным. Оно имеет одним из своих свойств собственное меню и владеет некоторым числом элементов управления. Все эти элементы окна - потенциальные генераторы новых событий, обработка которых будет осуществляться аналогично.

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

1 Строго говоря, у переключателя имеется и третье, "неопределенное" состояние, но оно для нас интереса не представляет.

2 Строго говоря, эти события ставятся в очередь на обработку.