Инструменты пользователя

Инструменты сайта


bb:redbook:303

Различия

Показаны различия между двумя версиями страницы.

Ссылка на это сравнение

bb:redbook:303 [2016/03/31 15:52]
prospero78 [2. Графические элементы]
bb:redbook:303 [2018/11/30 01:13]
Строка 1: Строка 1:
-===== 3.3  Принципы построения графических интерфейсов ===== 
  
-==== 1. Состав графического интерфейса ==== 
-Графический интерфейс (если он сделан правильно), состоит из трёх основных частей: 
-  
-  * графические элементы 
-  * неграфические элементы и различные сервисные процедуры 
-  * механизм событий/сообщений и маршрутизации этих событий/сообщений. 
-  
-Каждая часть заслуживает того, чтобы её рассмотреть. Без любой из них работа становится либо менее удобной, либо вообще невозможной. Например, без механизма событий невозможно узнать в каком состоянии находится клавиатура или мышь. [↑] 
-  
-  
-==== 2. Графические элементы ==== 
-С графическими элементами пользователь сталкивается в первую очередь, когда смотрит на экран: кнопки, списки, значки, меню, текстовые поля и много другой всякой всячины. И на первый взгляд они все разные. На самом деле, как правило, все они построены иерархически, и восходят к одному типу-предку. Например, tpWidget. Обычно, это просто прямоугольная область, которая имеет память о том, что на ней отражено, и имеет примитивные обработчики для реакции на мышь и клавиатуру. Поверх базового типа строятся расширенные типы. Например, tpButton или tpPlace. У них тот же самый функционал, что и у tpWidget, только у tpButton добавляется реакция на нажатие мыши, а у tPlace такой реакции нет. Это просто пассивный элемент для размещения других элементов. Даллее tpButton может наследоваться в более развитый потомок tpPictureButton. Этот тип уже может содержать картинку с произвольным положением на кнопке. И т. д. 
- 
-Нет ни одной RAD IDE, в которой был бы исчерпывающий список всех необходимых элементов. Но даже набор из 15-20 элементов уже способен перекрыть до 80% в графических элементах. Что делать, если что-то нужно, но этого что-то нет? Тут есть два пути: 
-  
-  * использовать готовые похожие элементы, скачанные из интернета (не забываем про лицензионные требования к таким элементам) 
-  * сделать самому (и приготовиться к мучительным многим часам, и необязательно к хорошему результату). 
-  
-Самостоятельная разработка графических элементов -- это тема для отдельного большого разговора. Овладеть ею непросто, но овладевший получает серьёзное преимущество. [↑] 
-  
-  
-==== 3. Неграфические элементы ==== 
-И такие тоже бывают. Например, существует необходимость выполнять какое-либо действие через заданный интервал времени (например, отображать текущее время). На первый взгляд ничего сложного. Просто опрашиваем системные часы, копируем их значение, и все довольны. Возникает закономерный вопрос, а как рассчитать тот момент, когда секунды уже изменились, и можно опрашивать? Постоянным бесконечным опросом можно задействовать 100% вычислительной мощности компьютера!!! Вот такой элемент, как таймер, как раз весьма будет кстати. Достаточно только задать интервал его срабатывания, и дописать код, который и будет выполнять необходимые нам действия. Кроме таймера, можно предложить ещё несколько вариантов таких неграфических элементов: скрытые окна для выбора и настройки принтера, выбора цвета, диалоги работы с файлами и т. д. (хотя, это конечно, уже не совсем не графические элементы, и их даже можно частично настраивать). 
- 
-Отдельного упоминания заслуживают процедуры, облегчающие типовые операции. Например, получить параметры командной строки, текущие время и дату, вычислить синусы/косинусы/тригонометрические функции и т.д. Можно все эти вещи реализовать самостоятельно, но реализовывать такие штуки каждый раз (или искать в интернете) -- это сложнее, чем иметь такие процедуры уже встроенными в каркас. [↑] 
-  
-  
-==== 4. Сообщения и маршрутизация ==== 
-Поскольку графический интерфейс пользователя не статическая система, а динамическая, то логично предположить, что графические элементы, при изменении своего состояния, должны каким-то образом оповещать всю программу об этом, и такие оповещения должны запускать какие-либо процедуры. Сообщения, могут генерироваться произвольно в коде программы, а могут и порождаться из-за действий пользователя: перемещение мыши, нажатие клавиши клавиатуры. Сообщения, которые имеют источником пользователя, либо аппаратные средства -- принято называть события. 
- 
-И как графический элемент узнает, какую часть кода должен он выполнить по какому-либо событию, или сообщению? Вот тут и пригодится нечто под названием маршрутизатор. Маршрутизатор знает кому куда отправить какое событие или сообщение. Это происходит благодаря специальному формату сообщения, в котором содержится: адресат, получатель, тип сообщения, необходимые параметры. 
- 
-И вот такая схема здорово упрощается, если использовать каркас. Ура! БлэкБокс как раз такой каркас! (строго говоря, подобной маршрутизацией занимается любое развитое RAD IDE, но, например, Lazarus не является в полном смысле каркасом). 
- 
-Как станет видно позднее, у программиста, использующего БлэкБокс не болит голова о том, как привязать события. Это всё берёт на себя сам БлэкБокс. [↑] 
-  
-  
-==== 5. Выводы ==== 
-Даже при беглом осмотре устройства графического интерфейса пользователя, оказывается: всё не так просто, как кажется на первый взгляд. В различных графических подсистемах такие части сделаны по разному. Но принципы их построения очень похожи. Достаточно изучить один ГИП, чтобы понять, как работают остальные. В современном мире современному программисту прикладных задач придётся заниматься ГИП, поэтому информация изложенная в этой главе является прологом к дальнейшим главам. [↑] 
-  
-[ ← Назад ] [ Вверх ↑ ] [ Далее → ] 
bb/redbook/303.txt · Последнее изменение: 2020/10/29 07:08 (внешнее изменение)