на тему рефераты Информационно-образоательный портал
Рефераты, курсовые, дипломы, научные работы,
на тему рефераты
на тему рефераты
МЕНЮ|
на тему рефераты
поиск
Особенности программирования для Windows
аким образом, немодальный, многозадачный и многооконный режимы работы Windows добавляют разработчикам новые хлопоты. Каким образом создать приложение, способное устойчиво работать в столь сложной операционной среде? Ответ на этот вопрос следующий: успех ждет только на пути объектно-ориентированного программирования (ООП). И система CA-Visual Objects такое программирование обеспечивает в полной мере!

1.3 Структура программ в CA-Visual Objects

1.3.1 Объекты. Связи типа “владение"

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

Программа в CA-Visual Objects - это совокупность объектов, способных взаимодействовать друг с другом посредством сигналов (сообщений).

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

Нормально, объект пребывает в пассивном состоянии, ожидая получения предназначенных ему сообщений.

Получив сообщение X (см. рис.2.1), объект может изменить одно или несколько своих свойств (например, размеры, цвет) и сгенерировать одно или несколько сообщений Y для других объектов.

Характер реакции объекта определяется содержанием входного сообщения X. Отреагировав на очередное сообщение, объект снова переходит в пассивное состояние до тех пор, пока не получит извне новый сигнал.

Рис 1.14. Схематическое представление объекта

Объекты, имеющие общие “родовые” характеристики (т.е. сходные свойства и реакции на входные сообщения), объединяются в классы.

В ООП все возможные сообщения принято делить на две большие группы:

простые сообщения - те, которые имеют отношение к одному конкретному свойству объекта;

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

В CA-Visual Objects, как и в Clipper'е версий 5. х, факт посылки сообщения объекту обозначается символом “: ” (двоеточие). Простые сообщения формируются указанием имени объекта и его конкретного свойства, например:

cColor: = oBar: Color // значение свойства Color объекта oBar

// присвоить переменной cColor

oBox: Width: = 10 // свойству Width объекта oBox

// присвоить значение 10

Сложные сообщения в программах реализуются методами и синтаксически характеризуются наличием пары круглых скобок - “ () ”:

oWindow: Repaint () // Объекту oWindow выполнить метод // Repaint ()

Реакция объекта на получение сложного сообщения должна быть явно определена в описании соответствующего метода.

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

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

Как уже отмечалось, типовое приложение в Windows визуально представляется главным окном (или, иначе, окном-оболочкой), в рамках которого это приложение может открывать сколь угодно много дочерних окон. Любое дочернее окно содержит в себе те или иные элементы управления. Описанная цепочка легко и естественно укладывается в иерархическую структуру (рис.1.15):

Рис.1.15. Иерархическая структура связей объектов в CA-Visual Objects

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

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

1.3.2 Генерация и обработка событий

Рассмотрим более предметно схему генерации и обработки событий, принятую в 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. Пример окна “Картотека"

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, 3


© 2003-2013
Рефераты бесплатно, курсовые, рефераты биология, большая бибилиотека рефератов, дипломы, научные работы, рефераты право, рефераты, рефераты скачать, рефераты литература, курсовые работы, реферат, доклады, рефераты медицина, рефераты на тему, сочинения, реферат бесплатно, рефераты авиация, рефераты психология, рефераты математика, рефераты кулинария, рефераты логистика, рефераты анатомия, рефераты маркетинг, рефераты релиния, рефераты социология, рефераты менеджемент.