C++ C++ C# C# ASP.NET Security ASP.NET Security ASM ASM Скачать Скачать Поиск Поиск Хостинг Хостинг  
  Программа для работы с LPT портом...
Язык: .NET — ©Alexey...
  "ASP.NET Atlas" – AJAX в исполнении Micro...
Язык: .NET — ©legigor@mail.ru...
  "Невытесняющая" Многопоточность...
Язык: C/C++ — ©...
  01.05.2010 — Update World C++: Сборник GPL QT исходников
  15.12.2007 — Весь сайт целиком можно загрузить по ссылкам из раздела Скачать
Хостинг:
Windows 2003, ASP.NET 2.0
бесплатный и от 80 руб./мес


   Отправить письмо
Кулабухов Артем, Беларусь




 73 - Иерархия компонентов VCL / С++ Builder 5 / Borland C++

Шаг 73 - Иерархия компонентов VCL

Иерархия компонентов VCL предусматривает в некотором роде платформо-независимый интерфейс программирования. Это подтверждает так же и то, что пакет VCL был перенесен на системы Unix (сюда я отношу Linux, *BSD и некоторые другие разновидности) под именем Kylix.

Небольшое отступление. На момент написания статьи последняя версия была 2.0. Лично я испробовал версию 1.0. Я ничего против Дельфи не имею, однако на мой взгляд, было бы практичнее перенести для начала систему типа C++ Builder. Заинтересовавшимся должен с прискорбием сказать, что версия 1.0 была... довольно далека от совершенства. Надеюсь, что 2.0 более отработана. Ну, для примера можно сказать, что довольно много времени я потратил на проблемы устранения конфликтов локали моего линукса и собственной среды IDE. Затем оказывается, что готовые проекты могут работать только с одной версией Qt-библиотеки, если не ошибаюсь, 2.2.4. Может, конечно, это все равно, но вкладывать, например, в готовые пакеты с программами 3-4 метровый Qt как минимум неприятно. Ну да ладно. Надеюсь, все же вскоре смогу спокойно переносить проекты С++ Builder на Линукс.

Так вот. Иерархия в общем такая (в верхней строке расположены последовательные потомки, а под ними - их потомки):

TObjectTPersistentTComponentTControlTWinControlTCustomControl
TGraphicControl TButtonControl
TCustomComboBox
TCustomGrid
TCustomGroupBox
TCustomPanel
TDBImage
TDBLookupControl
THeader
TCustomEdit
TCustomHotKey
TCustomListBox
TCustomListView
TCustomTabControl
TCustomTreeView
TCustomUpDown
TDBCtrlGrid
TDBCtrlPanel
THeaderControl
TOleControl
TProgressBar
TScrollBar
TScrollingWinControl
TStatusBar
TTabPage
TTabSheet
TTrackBar

Я немного поясню общую семантику. TObject - предок ВСЕХ компонентов VCL. Это имеет несколько преимуществ, в основном связанных с тем, что практически любой класс, использующийся в программе, можно приравнять TObject. Методы (свойства и методы мы подробнее рассмотрим в следующем шаге) предоставляют некоторые возможности, связанные с run-time определением класса, его строкового имени, возможности взаимодействия с COM (ужасная вещь :)).

TPersistent определяет некоторые низкоуровневые возможности классов VCL. Это загрузка и сохранение свойств объекта, его копирование в другой экземпляр объекта такого же класса и т.д. Обычно программисты редко работают над изменениями класса TPersistent, он принимается as is. Интересным производным TPersistent является TComponent, являющийся предком всех компонентов библиотек VCL и VCLx. Его прямые потомки - невидимые компоненты, такие как TOpenDialog.

TControl дает Вашему классу возможность работать как элементу управления - перехватывать события Windows, отображаться на экране, вообще быть видимыми. Это чисто базовый класс, при этом новые компоненты чаще всего создаются от потомков TControl - TGraphicControl или TWinControl.

TGraphicControl не является оконным компонентом, но при этом предоставляет унаследованную возможность перехвата сообщений клавиатуры и мыши, а также свойство Canvas, которое предоставляет удобную возможность рисования. Однако он не дает возможности перехода на него фокуса, поскольку не является имплементацией WinAPI. Запутанно звучит, но, впрочем, достаточно знать то, что этот компонент хорошо использовать для создания оригинальных графических компонентов. Ну все равно - как же так, что если это не оконный компонент, а события перехватывать может? Дело в том, что механизм рисования и перехвата сообщений заложен в родителе - производном TWinControl. Это, кроме того, несколько экономит ресурсы собственно Windows.

TWinControl - общий интерфейс к большинству встроенных оконных... даже не классов, а ресурсов WinAPI. То есть это просто удобный интерфейс для имплементации, поскольку многие параметры, предоставляемые функциями АПИ, схожи или просто одинаковы.

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

Еще по поводу соглашений имен. Как правило, всегда следует производить потомков от класса с именем типа TCustom*. То есть если нужен потомок TListView, то надо создавать TCustomListView.

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


| |
Автор Аванесов Самвел.
[AD]