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