236______________________________________________Глава 4

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

Вот и все основные требования к главному меню приложения. Проектирова-
ние меню — не очень быстрый процесс и обидно повторять его снова и снова для i
каждого нового приложения, тем более, что требование стандартизации приводит 1
к тому, что одни и те же разделы с одинаковыми свойствами кочуют из приложе- '
ния в приложение. Поэтому можно рекомендовать один раз потратить время, со-
здать меню, содержащее большинство разделов, которые могут вам понадобиться в
различных приложениях, и сохранить это меню как шаблон (в разделе 3.4.1 рас-
сказано, как это делается с помощью команды Save As Template... в Конструкторе
Меню). В дальнейшем вы сможете использовать этот шаблон в любом своем прило-
жении, загружая его командой Insert From Template... Конструктора Меню в компо-
нент MainMenu. А удалить после этого разделы, не используемые в данном прило-
жении, не представляет никакого труда — вы просто выделяете соответствующий
раздел в Конструкторе Меню и нажимаете клавишу Del.

Можно поступить еще более радикально, сохранив в библиотеке шаблон,
включающий в себя компонент MainMenu, инструментальную панель, список
изображений ImageList и диспетчер событий ActionList как единое целое (см. о
сохранении шаблонов в разделе 7.2 главы 7). Это сэкономит вам в последующем
немало времени при разработке новых приложений.

Помимо главного меню в приложении обычно должны быть контекстные
всплывающие меню отдельных компонентов, например, окон редактирования. Эти
меню обычно дублируют команды главного меню, используемые при работе с дан-
ным компонентом. В разделе 3.4.2 главы 3 рассказано, как проектируются всплы-
вающие меню с помощью компонента PopupMenu. Всплывающие меню желатель-
но не перегружать разделами, вводя в них только действительно часто используе-
мые команды.

4.1.6 Проектирование экрана

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

Управляющие элементы и функционально связанные с ними компоненты эк-
рана должны быть зрительно объединены в группы, заголовки которых коротко и
четко поясняют их назначение. Такое объединение позволяют осуществлять раз-
личные панели, рассмотренные в разделе 3.5 главы З..Можно рекомендовать, как
правило, размещать компоненты не непосредственно на форме, а на таких пане-
лях. Но и внутри панелей надо продумывать размещение компонентов как с точки
зрения эстетики, так и с точки зрения визуального отражения взаимоотношений
элементов. Например, если имеется кнопка, которая разворачивает окно списка,
то эти два компонента должны быть визуально связаны между собой: размещены
на одной панели и в непосредственной близости друг от друга. Если же ваш экран
представляет собой случайные скопления кнопок, то именно так он и будет вос-
приниматься. И в следующий раз пользователь не захочет пользоваться вашей
программой.

Каждое окно должно иметь некоторую центральную тему, которой подчиняет-
ся его композиция. Пользователь должен понимать, для чего предназначено дан-