1.3. Требования к меню

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

В Delphi меню создаются компонентами MainMenu — главное меню, и Popup-Menu — всплывающее меню. Оба компонента расположены на странице Standard.

Основное требование к меню — их стандартизация. Это требование относится ко многим аспектам меню: месту размещения заголовков меню и их разделов, форме самих заголовков, клавишам быстрого доступа, организации каскадных меню. Цель стандартизации — облегчить пользователю работу с приложением. Надо, чтобы пользователю не приходилось думать, в каком меню и как ему надо открыть или сохранить файл, как ему получить справку, как работать с буфером обмена Clipboard и т.д. Для осуществления всех этих операций у пользователя, поработавшего хотя бы с несколькими приложениями Windows, вырабатывается стойкий автоматизм действий и недопустимо этот автоматизм ломать.

Начнем рассмотрение требований с размещения заголовков меню. Размещение общепринятых разделов должно быть стандартизированным. Все пользователи уже привыкли, что меню Файл размещается слева в полосе главного меню, раздел справки — справа, перед ним в приложениях MDI размещается меню Окно и т.д. Главное меню должно также снабжаться инструментальной линейкой, быстрые кнопки которой дублируют наиболее часто используемые команды меню. На этих кнопках надо использовать, по возможности, привычные картинки.

По возможности стандартным должно быть и расположение разделов в выпадающих меню.

Группы функционально связанных разделов отделяются в выпадающих меню разделителями.

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

Названия разделов меню, связанных с вызовом диалоговых окон, должны заканчиваться многоточием, показывающим пользователю, что при выборе этого раздела ему предстоит установить в диалоге еще какие-то параметры.

Разделы, к которым относятся каскадные, должны заканчиваться стрелкой, указывающей на наличие дочернего меню данного раздела. Delphi ставит эту стрелку автоматически, так что о ней вам думать не приходится. Вообще злоупотреблять каскадными меню не следует, так как пользователю не так просто до них добираться. Если в дочернем меню должно быть много разделов, например, связанных с какими-то опциями и настройками, то подумайте, не лучше ли вместо этого дочернего меню предусмотреть диалоговое окно, в котором эти опции будут более обозримыми и доступными. В каждом названии раздела должен быть выделен подчеркиванием символ, соответствующий клавише быстрого доступа к разделу (клавиша Alt плюс подчеркнутый символ). Хотя вряд ли такими клавишами часто пользуются, но традиция указания таких клавиш незыблема.

Многим разделам могут быть поставлены в соответствие «горячие» клавиши, позволяющие обратиться к команде данного раздела, даже не заходя в меню. Комбинации таких «горячих» клавиш должны быть традиционными. Например, команды вырезания, копирования и вставки фрагментов текста практически всегда имеют «горячие» клавиши Ctrl-X, Ctrl-C и Ctrl-V соответственно. Заданные сочетания клавиш отображаются в заголовках соответствующих разделов меню.

Начиная с Delphi 4 предусмотрена возможность включать в меню пиктограммы, соответствующие некоторым разделам. Это не входит в обязательные требования к меню и использование пиктограмм — дело вкуса.

Некоторые разделы меню, соответствующие выбору каких-то настроек, могут содержать индикаторы, показывающие, выбран или нет данный раздел, и могут содержать радиокнопки.

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

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

Пример проектирования меню и инструментальной панели

1. Перенесите на форму компонент диспетчеризации действий. Применение этого компонента не обязательно. Но, привыкнув к работе с ним, вы увидите, что его применение экономит вам много времени и делает код более прозрачным и простым в сопровождении.

2. Перенесите на форму компонент ImageList — список изображений для разделов меню и быстрых кнопок инструментальной панели.

3. С помощью редактора списка изображений, вызываемого двойным щелчком на ImageList, заполните список изображениями, символизирующими основ­ные команды будущего меню.

4. Перенесите на форму компоненты стандартных диалогов типа «Открыть файл» (компонент OpenFileDialog), «Сохранить файл как» (компонент SaveFileDialog) и др. Перенесите также другие компоненты, к которым будут относиться действия.

5. Компонент диспетчеризации действий ActionList свяжите со списком изображений, установив его свойство Images равным ImageList 1 — имени компонента ImageList.

6. Двойным щелчком на компоненте ActionList вызовите редактор действий и занесите в него все действия, соответствующие будущим разделам меню.

7. После занесения в список очередного действия выделите его в правом окне и на странице свойств окна Редактора Кода задайте его свойства. Прежде всего, задайте Name (имя) — желательно осмысленное, связанное с введенным действием. Только не задавайте имена, которые могут оказаться тождественными именам каких-то функций, методов и т.д.

Помимо главного меню в приложении обычно должны быть контекстные всплывающие меню отдельных компонентов, например, окон редактирования. Эти меню обычно дублируют команды главного меню, используемые при работе с данным компонентом. Всплывающие меню желательно не перегружать разделами, вводя в них только действительно часто используемые команды. Вы можете также задать свойства: Shortcut — быстрые клавиши (если они должны назначаться для данного действия), Hint — надписи на ярлычках подсказок и в строке состояний, HelpContext — идентификатор темы контекстной справки (если для данного действия предусмотрена справка), Imagelndex — индекс изображения в ImageList, соответствующего данному действию. Можете также, при необходимости, задать свойства Enabled — доступность, Checked — занесение индикатора выделения и др.

8. Для каждого действия на странице событий Инспектора Объектов определено событие OnExecute. В обработчике этого события вам надо описать операции, соответствующие данному действию. Например, для действия AExit (выход из программы) обработчик может иметь вид

procedure TForml.AExitExecute(Sender: TObject) ;

begin

Close;

end;

Обратите внимание, что заголовок процедуры (AExitExecute) получается осмысленным — он указывает на характер действия. Такое название процедуры, конечно, много понятнее, чем ButtonSCIick или NIClick — имена, получающиеся без использования компонента ActionList.

9. После завершения списка действий перенесите на форму компонент MainMenu — главное меню. Установите его свойство Images равным ImageListl — имени компонента ImageList. Вызовите двойным щелчком на MainMenu редактор меню. Вы можете не задавать для вводимых вами разделов меню никаких свойств. Достаточно, выделив очередную пунктирную рамку в редакторе меню, задать в Инспекторе Объектов для очередного раздела свойство Action. Для этого достаточно щелкнуть в строке правее этого свойства и из выпадающего списка, в котором имеются все введенные вами действия, выбрать нужное. Вы увидите, что при этом автоматически заполнятся все свойства данного раздела меню: появится надпись, изображение (если оно предусмотрено), тексты подсказок в свойстве Hint и т.д. На странице событий Инспектора Объектов вы увидите, что в событие OnClick (щелчок) уже занесена ссылка на ранее написанный вами для этого действия обработчик. Таким образом, применение компонента ActionList существенно упростило разработку меню.

10. Перенесите на форму компонент инструментальной панели ToolBar. Щелкая на нем правой кнопкой мыши, выбирайте команды New Button (новая кнопка) или New Separator (новый разделитель). Для каждой новой кнопки так же, как ранее для разделов меню, устанавливайте свойство Action. Все остальные свойства перенесутся в кнопку автоматически.

11. Если необходимо обеспечить в приложении контекстные всплывающие меню, то перенесите на форму один или несколько (по числу различных контекстных меню) компонентов PopupMenu. Свяжите их с компонентом ImageList, задав свойство Images. Далее, сделав двойной щелчок на PopupMenu, вы попадете в тот же редактор меню, что и в случае MainMenu. Вы можете проектировать всплывающее меню так же, как главное. Но, поскольку всплывающее меню обычно дублирует какие-то разделы уже сформированного главного меню, то можно обойтись копированием соответствующих разделов. Для этого, войдя в конструктор меню из компонента PopupMenu, щелкните правой кнопкой мыши и из всплывшего меню выберите команду Select Menu (выбрать меню). Вам будет предложено диалоговое окно, в котором вы можете перейти в главное меню. В нем вы можете выделить нужный вам раздел или разделы (при нажатой клавише Shift выделяются разделы в заданном диапазоне, при нажатой клавише Ctrl можно выделить совокупность разделов, не являющихся соседними). Затем выполните копирование их в буфер обмена, нажав клавиши Ctrl-C. После этого опять щелкните правой кнопкой мыши, выберите команду Select Menu и вернитесь в контекстное меню. Укажите курсором место, в которое хотите вставить скопированные разделы, и нажмите клавиши чтения из буфера обмена — Ctrl-V. Разделы меню вместе со всеми их свойствами будут скопированы в создаваемое вами контекстное меню.

12. Когда контекстное меню сформировано, для привязки его к необходимому компоненту выделите этот компонент на форме, и в инспекторе объектов задайте его свойство PopupMenu равным имени компонента соответствующего PopupMenu.

Вот в общих чертах последовательность операций при проектировании меню и инструментальной панели с использованием компонентов ActionList, ImageList, MainMenu, PopupMenu и ToolBar. Как видите, это не очень быстрый процесс и обидно повторять его снова и снова для каждого нового приложения, тем более что требование стандартизации приводит к тому, что одни и те же разделы с одинаковыми свойствами кочуют из приложения в приложение.