Оберон / Компонентный Паскаль / Вики

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

==== 1. Состав графического интерфейса ====
Графический интерфейс (если он сделан правильно), состоит из трёх основных частей:

  * графические элементы
  * неграфические элементы и различные сервисные процедуры
  * механизм событий/сообщений и маршрутизации этих событий/сообщений.

Каждая часть заслуживает того, чтобы её рассмотреть. Без любой из них работа становится либо менее удобной, либо вообще невозможной. Например, без механизма событий невозможно узнать в каком состоянии находится клавиатура или мышь. [↑]
	
	
==== 2. Графические элементы ====
С графическими элементами пользователь сталкивается в первую очередь, когда смотрит на экран: кнопки, списки, значки, меню, текстовые поля и много другой всякой всячины. И на первый взгляд они все разные. На самом деле, как правило, все они построены иерархически, и восходят к одному типу-предку. Например, tpWidget. Обычно, это просто прямоугольная область, которая имеет память о том, что на ней отражено, и имеет примитивные обработчики для реакции на мышь и клавиатуру. Поверх базового типа строятся расширенные типы. Например, tpButton или tpPlace. У них тот же самый функционал, что и у tpWidget, только у tpButton добавляется реакция на нажатие мыши, а у tPlace такой реакции нет. Это просто пассивный элемент для размещения других элементов. Даллее tpButton может наследоваться в более развитый потомок tpPictureButton. Этот тип уже может содержать картинку с произвольным положением на кнопке. И т. д.

Нет ни одной RAD IDE, в которой был бы исчерпывающий список всех необходимых элементов. Но даже набор из 15-20 элементов уже способен перекрыть до 80% в графических элементах. Что делать, если что-то нужно, но этого что-то нет? Тут есть два пути:

  * использовать готовые похожие элементы, скачанные из интернета (не забываем про лицензионные требования к таким элементам)
  * сделать самому (и приготовиться к мучительным многим часам, и необязательно к хорошему результату).

Самостоятельная разработка графических элементов -- это тема для отдельного большого разговора. Овладеть ею непросто, но овладевший получает серьёзное преимущество. [↑]
	
	
==== 3. Неграфические элементы ====
И такие тоже бывают. Например, существует необходимость выполнять какое-либо действие через заданный интервал времени (например, отображать текущее время). На первый взгляд ничего сложного. Просто опрашиваем системные часы, копируем их значение, и все довольны. Возникает закономерный вопрос, а как рассчитать тот момент, когда секунды уже изменились, и можно опрашивать? Постоянным бесконечным опросом можно задействовать 100% вычислительной мощности компьютера!!! Вот такой элемент, как таймер, как раз весьма будет кстати. Достаточно только задать интервал его срабатывания, и дописать код, который и будет выполнять необходимые нам действия. Кроме таймера, можно предложить ещё несколько вариантов таких неграфических элементов: скрытые окна для выбора и настройки принтера, выбора цвета, диалоги работы с файлами и т. д. (хотя, это конечно, уже не совсем не графические элементы, и их даже можно частично настраивать).

Отдельного упоминания заслуживают процедуры, облегчающие типовые операции. Например, получить параметры командной строки, текущие время и дату, вычислить синусы/косинусы/тригонометрические функции и т.д. Можно все эти вещи реализовать самостоятельно, но реализовывать такие штуки каждый раз (или искать в интернете) -- это сложнее, чем иметь такие процедуры уже встроенными в каркас. [↑]
	
	
==== 4. Сообщения и маршрутизация ====
Поскольку графический интерфейс пользователя не статическая система, а динамическая, то логично предположить, что графические элементы, при изменении своего состояния, должны каким-то образом оповещать всю программу об этом, и такие оповещения должны запускать какие-либо процедуры. Сообщения, могут генерироваться произвольно в коде программы, а могут и порождаться из-за действий пользователя: перемещение мыши, нажатие клавиши клавиатуры. Сообщения, которые имеют источником пользователя, либо аппаратные средства -- принято называть события.

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

И вот такая схема здорово упрощается, если использовать каркас. Ура! БлэкБокс как раз такой каркас! (строго говоря, подобной маршрутизацией занимается любое развитое RAD IDE, но, например, Lazarus не является в полном смысле каркасом).

Как станет видно позднее, у программиста, использующего БлэкБокс не болит голова о том, как привязать события. Это всё берёт на себя сам БлэкБокс. [↑]
	
	
==== 5. Выводы ====
Даже при беглом осмотре устройства графического интерфейса пользователя, оказывается: всё не так просто, как кажется на первый взгляд. В различных графических подсистемах такие части сделаны по разному. Но принципы их построения очень похожи. Достаточно изучить один ГИП, чтобы понять, как работают остальные. В современном мире современному программисту прикладных задач придётся заниматься ГИП, поэтому информация изложенная в этой главе является прологом к дальнейшим главам. [↑]
	
[ ← Назад ]		 		[ Вверх ↑ ]					[ Далее → ]