<< Предыдущая страница

 6.3.4 Типы свойств

Свойство может быть любого типа, который способна возвратить функция (так как реализация свойства может возлагаться на функцию). Разные типы свойств по-разному представлены в окне Инспектора объектов и определяют разные варианты их редактирования, предлагаемые Инспектором. Более того, мы уже знаем, что некоторые свойства имеют собственные редакторы. .

Правилами языка C++ устанавливаются следующие обобщенные группы типов компонентных свойств:

Тип свойства Действия Инспектора объектов
Simple Простые числовые, символьные и строчные свойства показываются Инспектором в виде чисел, символов или символьных строк, соответственно. Можно непосредственно вводить и редактировать значения простых свойств.
Enumerated Свойства перечисляемого типа (в том числе булевы) показываются Инспектором в виде значений, определенных в исходном тексте программы. Можно выбирать возможные значения из выпадающего списка перечислений.
Set Свойства типа множества показываются Инспектором в виде элементов множества. При расширении множества следует обращаться с каждым его элементом как с булевым значением: true, если элемент принадлежит множеству, или false в противном случае.
Object Свойства, которые сами по себе являются объектами, обычно обслуживаются своими собственными редакторами. Инспектор позволяет индивидуально редактировать те объектные свойства, которые объявлены какpublished. Объектные свойства должны быть производными от TPersistent
Array Свойства типа массив должны обслуживаться своими собственными редакторами свойств. Инспектор не имеет встроенных средств для редактирования таких свойств.

6.3.4.1 Свойства типа множество

Как известно из главы 3, C++Builder объявляет несколько шаблонных классов для встроенных типов Delphi, которых нет в языке C++.

В частности, типы стиля шрифта определяются следующим образом:

enum TFontStyle { fsBold, fsltalic, fsUnderline, fsStrikeOut } ;

typedef Set <TFontStyle, fsBold, fsStrikeOut>TFontStyles ;

TFontStyle является перечисляемым типом. TFontStyles определен как множество — неупорядоченная коллекция типа TFontStyle. Инспектор объектов позволяет переключать булевы значения элементов множества, выбирая значения false или true. Рис. 6.4 показывает пример манипуляций свойством Style типа множество в окне Инспектора. Это свойство, определяющее основные характеристики шрифта, имеют многие компоненты, в том числе, сама форма.

Рис. 6.4. Свойство Style.

6.3.4.2 Свойства типа массив

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

Листинг 6.7 содержит объявление свойства String и метода чтения GetNumberSize, возвращающего индексируемую строку массива.

class TDemoComponent : public TComponent
{
private:
    String __fastcall GetNumberSize(int Index);

public:
    property String Number[int Index] = { read=GetNumber };
// Другие объявления
};

String __fastcall TDemoComponent::GetNumberSize(int Index)
{
    String Result;

    switch (Index) {
       case 0: Result = "Zero"; break;
       case 100: Result = "Medium"; break;
       case 1000: Result = "Large"; break;
       default: Result = "Unknow size";
    }
    return Result;
}

Листинг 6. 7. Свойство типа массив и его метод чтения.

Объявление свойств типа массив имеет следующие особенности:

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

• Доступ к элементам массива реализуется посредством методов чтения/записи, которые имеют дополнительные параметры - индексы массива, перечисляемые в том же порядке, что и при объявлении методов. В этом состоит второе отличие от обычных массивов, где допускаются ссылки не только на отдельные элементы, но и на весь массив.

6.4 События

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

6.4.1 Зачем нужны события?

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

С точки зрения прикладного программиста, событие представляет собой имя, которому можно присвоить некоторый вызываемый метод. Например, экземпляр компоненты TButton - кнопка Buttoni имеет методы для события OnClick. По умолчанию C++Builder генерирует обработчик события с именем Button1Click и присваивает его событию OnClick. Когда происходит нажатие кнопки, объект вызывает метод, присвоенный событию OnClick, в данном случае, Button1Click.

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

6.4.2 Определение событий

Формально C++Builder определяет событие как типизированный указатель на метод в специфическом экземпляре класса:

<тип> (_closure * <имя метода>) (<список параметров>)

Для разработчика компонент closure представляет собой некоторую программную заглушку: когда пользователь определяет реакцию на некоторое событие, место заглушки занимает его обработчик, который вызывается вашей программой при возникновении этого события.

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

void _fastcall TForm1::Edit1KeyPress(TObject *Sender, char SKey)
{
    Key = UpCase(Key) ;
}

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

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

При разработке компонент нужно учитывать следующие аспекты обработчиков событий:

• Прикладные программисты не обязаны обрабатывать события. Различные события возникают практически постоянно при работе любого приложения Windows. Простое смещение курсора по компоненте вызывает передачу многочисленных сообщений Windows данной компоненте о передвижении мыши, которые компонента транслирует в события OnMouseMove. Если поведение компоненты не зависит от манипуляций мышью, то в большинстве случаев программа просто не обращает внимание на такие события.

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

6.4.2.3 Стандартные события

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

Существует две категории стандартных событий: определенные для всех компонент и определенные только для оконных компонент (стандартных и оригинальных). Все компоненты наследуют от базового абстрактного класса Tcontrol следующие стандартные события:

 

OnClick

OnDragDrop

OnEndDrag

OnMouseMove

OnDblClick

OnDragOver

OnMouseDown

OnMouseUp

В дополнение к этим событиям, оконные компоненты наследуют от базового абстрактного класса TWinControl еще и следующие стандартные события:

OnEnter OnKeyDown OnKeyPress
OnKeyUp OnExit  

Чтобы стандартные события вашей компоненты были видимы Инспектору объектов на стадии проектирования или во время выполнения программы, вы должны переопределить свойства событии в секции public или published. Листинг 6.9 показывает, как сделать стандартное событие OnClick видимым.

class TMyControl : public TCustomControl
{
__published:
   __property OnClick; // OnClick стало видимым Инспектору
};

Листинг 6.9. Переопределение стандартного события

Все стандартные события имеют соответствующие защищенные динамические методы, унаследованные от TControl, имена которых образованы от названия события без частицы "On". Например, события OnClick вызывают метод Click.

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

void _fastcall TMyControl::Click() {
// Стандартное обслуживание, включающая вызов обработчика
   TWinControl::Click() ;
// Далее следует ваш код переопределения метода
}

Листинг 6.10. Переопределение защищенного метода.

6.4.2.4 Собственные события

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

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

Определение события проходит через четыре этапа, для реализации которых вам необходимо:

1. Знать, какое действие вызывает событие. Для некоторых событий ответ очевиден. Например, при нажатии левой кнопки мыши Windows посылает сообщение WM_LBUTTONDOWN. Принимая это сообщение, компонента вызывает метод MouseDown, который в свою очередь обращается к обработчику события, который пользователь подсоединил к событию OnMouseDown. Некоторые события менее очевидно связаны с внешними воздействиями. Так линейка прокрутки имеет событие OnChange, которое возникает по разным причинам - в результате щелчков мышью, нажатия управляющих клавиш или изменений в других родственных компонентах.

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

3. Объявить тип и свойство для события. Инспектор объектов определяет, что данное свойство является событием, обнаруживая тип свойства closure, и представляет его на вкладке События. Давайте событиям значимые и описательные имена, по которым пользователь догадается о том, что это за событие. C++Builder рекомендует начинать имена событий с частицы "On.".

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

6.4.2.5 События и сообщения Windows

Опытный программист определенно заметит сходство некоторых событий C++Builder и сообщений Windows. В следующей таблице приведен краткий список событий объекта TForm и соответствующих сообщений Windows, которые вы использовали бы в обычной программе на языке С:

Событие VCL
Сообщение Windows
OnCreate WM_CREATE
OnClose WM_DESTROY
OnResize WM_SIZE
OnActivate, OnDeactivate WM_ACTIVATE
OnShow, OnHide WM_SHOWWINDOW
OnKeyDown WM_KEYDOWN
OnKeyUp WM_KEYUP
OnKeyDown WM_KEYDOWN
OnMouseDown WM_LBUTTONDOWN, WM_RBUTTONDOWN
OnMouseUp WM_LBUTTONUP,WM_RBUTTONUP
OnMouseMove WM_MOUSEMOVE
OnDblClk WM_LBUTTONDBLCLK, WM_RBUTTONDBLCLK
OnPaint WM_PAINT

He всякому сообщению Windows можно найти соответствующее событие VCL. Например, в обычной программе на языке С для Windows сообщение WM_COMMAND используется как для обслуживания нажатий на кнопки, так и выбора команд из меню. В C++Builder для этих целей используются разные события: TButton::OnClick и TMenuItem::OnClick, соответственно.

С другой стороны, некоторые события VCL расширяют функциональность встроенных сообщений Windows. Так события OnDragOver и OnDragDrop Объекта TForm просто и прямолинейно реализуют операции перетаскивания (drag-and-drop) в вашей программе. Большинство компонент на вкладках Standard и Win95 Палитры компонент лишь специальным образом обрамляют известные элементы управления Windows. Компоненты на других вкладках представляют совершенно новые элементы управления (и события) для особых областей функционирования.

Компоненты вкладок Standard и Win95 инкапсулируют стандартные элементы управления Windows. За взаимодействие между пользователем и программой, которое ранее поддерживалось реакцией на сообщения Windows, теперь отвечают обработчики событий компонент VCL. Однако, в некоторых ситуациях возникает необходимость "взять на себя" те сообщения Windows, которые не имеют соответствующих событий VCL или не адекватны им. Для таких случаев в VCL предусмотрена методика ООП, обеспечивающая непосредственный отклик на события Windows, подобно средствам библиотек базовых классов OWL или MFC. Эта методика, реализуемая с помощью макросов BEGIN_MESSAGE_MAP, MESSAGE.HANDLER и END_MESSAGE_MAP, весьма трудоемка и здесь не рассматривается. Поэтому предварительно тщательно просмотрите имеющиеся в VCL компоненты, которые могут содержать подходящие события.

6.4.3 Обработка событий

Событиям программист ставит в соответствие коды обработчиков событий, выполняющиеся всякий раз, когда соответствующее событие происходит. Некоторым событиям в Инспекторе объектов предписаны выпадающие списки, содержащие опции стандартных функций обработки событий, объявления и вызов которых C++Builder генерирует автоматически.

Рис. 6.5 показывает вкладку Events Инспектора объектов с выбранным событием OnClick компоненты TButton. Это событие возникает при нажатии кнопки Button 1. Если дважды щелкнуть мышью на поле события, C++Builder автоматически сгенерирует соответствующее объявление метода в файле объявлений Unitl.h, и Редактор кода переведет вас в нужную позицию в кодовом файле Unitl.cpp, где вы сможете написать код, реализующий этот метод.

Нижеследующий пример иллюстрирует процесс создания кода обработчика события OnClick (Нажата кнопка Button1) для компоненты TButton.

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

Чтобы связать ваш собственный обработчик с событием OnClick компоненты TButton воремя выполнения программы, вы должны сначала создать метод для обслуживания этого события. Как и любой метод, он должен принадлежать существующему объекту - форме, которая владеет компонентой TButton и на которой она размещена.

Рис. 6.6 показывает окно Редактора кода с файлами Unit1.h и Unit1.cpp программного модуля, реализующего обработку события OnClick. Объявленный метод становится обработчиком события, когда событию Button1->OnClick присваивается указатель некоторого метода MyOnClickEvent.

Указанное присваивание можно также сделать динамически при работе программы в обработчике события OnCreate вашей формы. Результат будет таким же, как и при создании обработчика событий с помощью Инспектора объектов на этапе проектирования, за исключением того, что в этом случае C++Builder сохраняет связь события с его обработчиком в ресурсном файле с расширением .dfm. При запуске приложения VCL считывает форму из ресурсного файла и динамически присваивает значения свойств и событий компонент, размещенных на форме.

Рис. 6.6. Определение метода обработки события OnClick.

Когда вы определяете методы для обработчиков событий, эти методы должны быть того же типа, что и типы свойства и членов данных, на которые ссылается свойство. Например, событие OnClick ссылается на внутренний член данных FOnClick функционального типа TNotifyEvent.

6.5 Методы

Компонентные методы ничем не отличаются от других объектных функции-членов. Хотя C++Builder не вводит никаких специальных ограничении на оформление компонентных методов, имеется ряд правил, которых стоит придерживаться:

1. Минимизируйте число методов, которые вызывает прикладной программист, чтобы использовать вашу компоненту. Многое из того, что вы намеревались реализовать в виде методов, вероятно, лучше инкапсулировать в свойства компоненты. В отличие от свойств, методы работают только во время исполнения программы.

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

3. Придерживайтесь соглашения об именах методов. Названия должны быть описательными, т.е. включать глагол действия и отражать возвращаемое значение (например, метод PasteFromClipboard передает в компоненту данные из доски объявлений, а метод GetHorizontalPosition возвращает горизонтальную позицию некоторой величины).

4. Правильно защищайте методы. Все методы (включая конструкторы и .деструкторы), к которым имеют право обращаться пользователи вашей компоненты, следует объявлять как public. Все методы, к которым имеют право обращаться производные объекты вашей компоненты, следует объявлять как protected, что запрещает пользователям преждевременно вызывать методы, данные для которых еще не созданы. Только те методы, которые реализуют доступ к свойствам компоненты, должны быть объявлены как private, поскольку пользователи оперируют со значениями свойств напрямую.

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

6.5.1 Вызовы статических методов

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

class TFirstComponent : public Tcomponent
{
public:
    void __fastcall Move() ;
    void __fastcall Flash();
};

class TSecondComponent : public TPirstComponent
{
public:
    void _fasfccall Move(); // отличен от наследованного метода
    int __fastcall Flash(int HowOften); // тоже отличается
};

Листинг 6.11. Переопределение статических методов.

Адреса статических методов не меняются при наследовании, а значит, статические методы не следует переопределять - они призваны выполнять одинаковые действия во всех родственных компонентных объектах. Листинг 6.11 показывает, что переопределение статических методов в производном классе по сути заменяет родительские методы.

6.5.2 Вызовы виртуальных методов

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

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

<< Предыдущая страница