Практически любое приложение должно иметь меню, поскольку именно меню дает наиболее удобный доступ к функциям программы. Существует несколько различных типов меню: главное меню с выпадающими списками разделов, каскадные меню, в которых разделу первичного меню ставится в соответствие список подразделов, и всплывающие или контекстные меню, появляющиеся, если пользователь щелкает правой кнопкой мыши на каком-то компоненте.
В C++Builder меню создаются компонентами MainMenu (главное меню) и PopupMenu (всплывающее меню). Оба компонента расположены на странице Standard. Кроме того, в C++Builder 6 имеется возможность создания меню, настраиваемого пользователем во время выполнения, с помощью компонентов ActionManager и ActionMainMenuBar.
Основное требование к меню это их стандартизация. Это требование относится ко многим аспектам меню: месту размещения заголовков меню и их разделов, форме самих заголовков, клавишам быстрого доступа, организации каскадных меню. Цель стандартизации - облегчит пользователю работу с приложением. Надо, чтобы пользователю не приходилось думать, в каком меню и как ему надо открыть или сохранить файл, как ему получить справку, как работать с буфером обмена Clipboard и т.д. Для осуществления всех этих операций у пользователя, поработавшего хотя бы с несколькими приложениями Windows, вырабатывается стойкий автоматизм действий и недопустимо этот автоматизм ломать.
Конечно, состав меню зависит от конкретного приложения. Но размещение общепринятых разделов должно быть стандартизированным. Все пользователи уже привыкли, что меню Файл размещается слева в полосе главного меню, раздел справки справа, перед ним в приложениях MDI размещается меню Окно и т.д. Главное меню должно также снабжаться инструментальной панелью, быстрые кнопки которой дублируют наиболее часто используемые команды меню. На этих кнопках надо использовать, по возможности, привычные картинки. В С++Builder имеется множество изображений кнопок на все случаи жизни, но, к сожалению, они не всегда имеют привычный для пользователя рисунок.
По возможности стандартным должно быть и расположение разделов в выпадающих меню:
- Файл - работа с файлами
- Правка - работа с текстами
- Окно - управление окнами в приложении MDI
- Справка или ? - просмотр справочных данных
Обратите внимание, что, например, раздел Выход всегда размещается последним в меню Файл, а раздел информации о версии программы О программе... последним в справочном меню.
Группы функционально связанных разделов отделяются в выпадающих меню разделителями.
Названия разделов меню должны быть привычными пользователю. Если не знаете, как назвать какой-то раздел, не изобретайте свое имя, а попытайтесь найти аналогичный раздел в какой-нибудь русифицированной программе Microsoft для Windows. Названия должны быть краткими и понятными. Не используйте фраз, да и вообще больше двух слов, поскольку это перегружает экран и замедляет выбор пользователя. Названия разделов должны начинаться с заглавной буквы. Применительно к английским названиям разделов существует требование, чтобы каждое слово тоже начиналось с заглавной буквы. Но применительно к русским названиям это правило не применяется. Названия разделов меню, связанных с вызовом диалоговых окон, должны заканчиваться многоточием, показывающим пользователю, что при выборе этого раздела ему предстоит установить в диалоге еще какие-то параметры.
Разделы, к которым относятся каскадные меню должны заканчиваться стрелкой, указывающей на наличие дочернего меню данного раздела. С++Builder ставит эту стрелку автоматически, так что о ней думать не приходится. Вообще злоупотреблять каскадными меню не следует, так как пользователю не так просто до них добираться. Если в дочернем меню должно быть много разделов, например, связанных с какими-то опциями и настройками, то подумайте, не лучше ли вместо этого дочернего меню предусмотреть диалоговое окно, в котором эти опции будут более обозримыми и доступными.
В каждом названии раздела должен быть выделен подчеркиванием символ, соответствующий клавише быстрого доступа к разделу (клавиша Alt плюс подчеркнутый символ). Хотя вряд ли такими клавишами часто пользуются, но традиция указания таких клавиш незыблема. Впрочем, если у пользователя отказала мышь, то клавиши быстрого доступа позволяют выполнить какие-то заключительные операции и сохранить документы, с которыми велась работа. Многим разделам могут быть поставлены в соответствие «горячие» клавиши, позволяющие обратиться к команде данного раздела, даже не заходя в меню. Комбинации таких «горячих» клавиш должны быть традиционными. Например, команды вырезания, копирования и вставки фрагментов текста практически всегда имеют «горячие» клавиши Ctrl+X, Ctrl+C и Ctrl+V соответственно. Заданные сочетания клавиш отображаются в заголовках соответствующих разделов меню.
Многие разделы меню желательно снабжать пиктограммами, причем пиктограммы для стандартных разделов должны быть общепринятыми, знакомыми пользователю. Некоторые разделы меню, соответствующие выбору каких-то настроек, могут содержать индикаторы, показывающие, выбран или нет данный раздел, и могут содержать радиокнопки.
Не все разделы меню имеют смысл в любой момент работы пользователя с приложением. Например, если в приложении не открыт ни один документ, то бессмысленно выполнять команды редактирования в меню Правка. Если в тексте документа ничего не изменялось, то бессмысленным является раздел этого меню Отменить, отменяющий последнюю команду редактирования. Такие меню и отдельные разделы должны делаться временно недоступными или невидимыми. Это осуществляется заданием значения false свойствам раздела Enabled или Visible соответственно. Различие между недоступными и невидимыми разделами в том, что недоступный раздел виден в меню, но отображается серым цветом, а невидимый раздел просто исчезает из меню, причем нижележащие разделы смыкаются, занимая его место. Выбор того или иного варианта дело вкуса и удобства работы пользователя. Вероятно, целиком меню лучше делать невидимыми, а отдельные разделы недоступными. Например, пока ни один документ не открыт, меню Правка можно сделать невидимым, чтобы он не отвлекал внимания пользователя. А раздел Отменить этого меню в соответствующих ситуациях лучше делать недоступным, чтобы пользователь видел, что такой раздел в меню есть и им можно будет воспользоваться в случае ошибки редактирования.
Вот и все основные требования к главному меню приложения.
Проектирование меню - не очень быстрый процесс и обидно повторять его снова и снова для каждого нового приложения, тем более что требование стандартизации приводит к тому, что одни и те же разделы с одинаковыми свойствами кочуют из приложения в приложение. Поэтому можно рекомендовать один раз потратить время, создать меню, содержащее большинство разделов, которые могут понадобиться в различных приложениях, и сохранить это меню как шаблон. В дальнейшем можно использовать этот шаблон в любом своем приложении, загружая его командой Insert From Template Конструктора Меню в компонент MainMenu. А удалить после этого разделы, не используемые в данном приложении, не представляет никакого труда. Просто выделяете соответствующий раздел в Конструкторе Меню и нажимаете клавишу Del.
Поскольку меню обычно проектируется в комплексе с диспетчером действий, списком изображений, инструментальными панелями, то указанная выше возможность сохранения шаблона самого меню не слишком помогает избежать повторения множества проектных операций в каждом новом приложении. Поэтому можно рекомендовать сохранять как шаблон всю совокупность компонентов: диспетчер действий, список изображений, меню, инструментальные панели. Создание подобного шаблона заметно сэкономит время при разработке последующих проектов и будет способствовать единообразию интерфейса в серии проектов, что также немаловажно.
Помимо главного меню в приложении обычно должны быть контекстные всплывающие меню отдельных компонентов, например, окон редактирования. Эти меню обычно дублируют команды главного меню, используемые при работе с данным компонентом. Всплывающие меню PopupMenu желательно не перегружать разделами, вводя в них только действительно часто используемые команды.
