Часть 21

Глава 19. Рекомендации для стандартного приложения
Один из основных аргументов в пользу разработки основанного на Windows программного обеспечения состоит в простоте обучения и использования. Значительное повышение производительности пользователя Windows достигается за счет общих для большинства программ
 приемов проведения операций. Например, меню редактирования имеет одни и те же элементы меню и сочетания клавиш в текстовых процессорах, и приложениях для рисования. Другими словами, если вы знаете как работать с одним приложением Winodws, то вы сможете 
использовать любое другое приложение.
Для формализации общих рекомендаций по организации проведения операций фирма IBM опубликовала набор правил с общим названием Общий Доступ Пользователя (Common User Access - CUA). Хотя CUA разрабатывались для Менеджера Презентаций приложений OS/2, они впо
лне применимы к приложениям Windows и рассматриваются в качестве промышленного стандарта. Данный раздел основан на публикации CUA фирмы IBM.
Принципы разработки
Есть два аргумента в пользу соблюдения приложением правил CUA: пользователи будут уверены в результатах своих действий и смогут управлять потоком событий.
Обеспечение той реакции, которую ожидает пользователь
Лучший способ организации уверенной работы пользователя с приложением состоит в разработке ясных и четких реакций приложения. Предложения состоят в следующем:
- Использование метафор. Если модель поведения приложения будет   основана на чем-то известном пользователю, например, на  существующей бумажной технологии, то он будет лучше понимать  основные концептуальные модели приложения. Кроме того,  пользователь 
достаточно быстро оценит удобство работы с  приложением.
- Последовательность. Последовательно реализуйте проявление и  использование вашего приложения. Используйте унифицированные  команды (выбор меню, пиктограммы и т.п.) для совершения  некоторых общих операций. Экраны при решении аналогичных задач  должны и
 выглядеть аналогично.
- Избегайте режимов. Режим это состояние приложения, при котором  пользовать ограничен в доступе к некоторым аспектам. Это часто  форсирует действия пользователя в некотором конкретном  направлении. Режимы допустимо использовать для коротких  сообщений о
б ошибках или в процессе выбора инструмента.  Например, когда курсором является ручка, пользователь может  только рисовать, но не может сдвигать области. Обеспечивайте  визуальное подтверждение установленного режима, например,  отличительным курсором или
 выделением элемента меню серым  цветом.
Предоставление пользователю возможностей управления потоком
Пользователи чувствуют себя более уверенно, если они могут определять последовательность действий. Когда у пользователя есть управление процессом это удаляет некоторый налет таинственности, который окружает компьютерные приложения. Программа становится п
рикладным инструментом.
- Визуально показывайте возможные варианты. Обеспечьте визуальное  отображение имеющихся у пользователя вариантов совершения  действий. В общем случае должна быть видна гамма инструментов и  палитра цветов, и меню опций.
- Обеспечьте обратную связь. Каждое действие пользователя должно  сопровождаться визуальным или звуковым эффектом.
- Поощряйте изучение. Не наказывайте пользователя за обращение к  опциям из любопытства. Очень часто это наилучший способ изучения  нового приложения. Обязательно включите в приложение опцию Undo.
Стандартное появление и поведение
Большинство стандартов Windows на появление и поведение приложений очевидны из Менеджера Программ и имеющихся примеров программ. Например, каждое приложение появляется в головном окне. Простое и двойное нажатие кнопки на мыши обычно имеет аналогичный эфф
ект для разных приложений.
Общее представление
- Используйте процесс объект-действие. Типичная последовательность  действий при работе приложения следующая: пользователь выбирает  некоторый элемент или объект и затем совершает над ним некоторое  действие. Например, в приложении текстового процессора,
  пользователь может выбрать некоторый фрагмент текста и затем  сменить его шрифт или размер. В программе рисования пользователь  может выбрать некоторый прямоугольник и затем переместить его в  другое место на экране. Имеется множество способов выбора  
объектов и еще больше способов действий над ними, поэтому вам  нужно просто придерживаться этой общей модели.
- Разумно выбирайте ваши окна. Приложение Windows может появляться  в одном или в нескольких окнах. При разработке вашего приложения  для его оптимального использования следует уделить особое  внимание разным типам окон и их использованию. Головное окно 
 должно унифицировать приложение, служить его скелетом. Даже в  минимизированном до пиктограммы виде оно все равно должно давать  представление о приложении и его действиях. Головное окно может  допускать режим работы пользователя с полным экраном или с 
 максимальным размером. Вторичные окна (например, всплывающие  окна и блоки диалога) должны порождаться головным окном в  результате совершения в нем некоторых действий. Всплывающие окна  могут представлять собой совершенно автономный модуль  приложения,
 но они не должны быть минимальными.
Взаимодействие мыши и клавиатуры
- Показывайте выбор объекта. После выбора объекта с помощью  нажатия кнопки на мыши нужно обеспечить его визуальное  выделение (например, обозначив прямоугольником его углы или  сменив его цвет или толщину линий). Отметка на объекте не должна  сохранятьс
я постоянно. После совершения над объектом некоторого  действия ее необходимо отменить. Это позволяет пользователю  предпринять некоторые другие действия. Отменяйте пометку  объекта, если пользователь выбирает другой объект.
- Не ограничивайте указатель мыши. Указатель мыши должен свободно  перемещаться от одного окна или приложения к другому. Не  ограничивайте его передвижения. Не следует также форсировать его  движения независимо от мыши. Это разрушает физическую  взаимосв
язь между мышью и ее указателем.
- Используйте курсор выбора клавиатуры. Курсор выбора клавиатуры  показывает ожидаемое место ввода данных с клавиатуры. Например,  мигающий символ подчеркивания представляет собой курсор выбора  клавиатуры для приложения по обработке текстов. Курсор выбо
ра  клавиатуры существует независимо от указателя мыши. Однако, при  нажатии кнопки на мыши они объединяются.
- Отмечайте место ввода. Место ввода это точка на экране, в  которую в данный момент допускается ввод с клавиатуры или с  мыши. Например, если пользователь выбирает опускающееся меню,  это меню будет иметь место ввода. Если пользователь подсвечивает  тек
ст, то он также будет иметь место ввода. Всегда визуально  отмечайте объект, который будет иметь место ввода. Например,  выбранные элементы меню обычно отображаются инверсным цветом и  управления в диалоге обводятся прерывистой линией. Часто, когда  поль
зователь протягивает мышь для выбора группы элементов,  область протягивания обводится прерывистой бегущей линией.
- Разработайте интерфейс клавиатуры. Используйте клавиши со  стрелками. Клавиши табуляции и акселераторы клавиатуры для  организации альтернативного варианта работы пользователя, если у  него нет мыши или он не хочет ее использовать.
- Соблюдайте соглашения относительно нажатий кнопок на мыши.  Windows придерживается, но не форсирует, определенных соглашений  относительно нажатия кнопок на мыши. В общем случае левая кнопка  на мыши используется для выбора и манипулирования объектами,
 а  правая кнопка используется для прочих целей, например, для смены  режима или вызова всплывающего списка опций. Для левой кнопке на  мыши нужно придерживаться следующих соглашений:
  Нажатие выбирает объект.
  Двойное нажатие выбирает объект и совершает некоторое действие  по умолчанию.
  Нажатие с протягиванием изменяет размеры объекта и его позицию  или выбирает и подсвечивает текст.
  Одновременное с Ctrl нажатие добавляет объект к ранее выбранным  объектам.
  Одновременное с Shift нажатие расширяет диапазон ранее выбранных  объектов добавляя вместо первого объекта текущий. (Пример можно  посмотреть в руководстве "Менеджер Файлов для Windows".)
Меню
Windows всегда предоставляет и использует стандарт для появления опускающихся меню. Однако, у вас всегда есть возможность выбора некоторого стиля и опций, которые вы решили реализовать. Например, вы должны использовать уникальную мнемонику для доступа с 
клавиатуры к каждому элементу меню верхнего уровня и опускающегося меню. Вы должны использовать многоточие (...) вслед за элементом меню, выбор которого приводит к появлению блока диалога. Выделяйте серым цветом неактивные элементы меню.
Большинство приложений, предназначены ли они для графики, бизнеса, образования, науки или  инжиниринга, выполняют определенный набор операций по манипулированию файлами, редактированию и обращению к системе подсказок. Принимая это во внимание, CUA требуе
т определенных форматов для меню File, Edit и Help. Кроме того, даются рекомендации по меню View и Options. CUA требует, чтобы вы располагали элементы меню верхнего уровня определенным образом, а Help всегда был последним, независимо от того, сколько дру
гих меню имеется.
Для подготовки файлов подсказок , которые может считывать система подсказок Windows, вам нужно получить от фирмы Microsoft утилиту Компилятор Подсказок.
Рис.19.1. Стандартное меню CUA
Следующий примеры показывают рекомендации CUA по элементам меню. Обратите внимание на клавиатурные акселераторы, которые появляются рядом с некоторыми элементами меню.
Рис.19.2. Рекомендуемые CUA элементы меню File
Рис.19.3. Рекомендуемые CUA элементы меню Edit
Рис.19.4. Рекомендуемые CUA элементы меню View
Рис.19.5. Рекомендуемые CUA элементы меню Options
Рис.19.6. Рекомендуемые CUA элементы меню Help
Блоки диалога
Имеется такое большое число способов разработки блоков диалога, что можно дать лишь самые общие рекомендации. Однако, хорошая идея состоит в том, чтобы выработать стиль вашего приложения и придерживаться его. Имеется два типа блоков диалога: модальные и 
немодальные. Модальные, которые приостанавливают работу программы, должны использоваться наиболее часто. Немодальные, которые допускают продолжение обычного выполнения программы, должны использоваться только для специальных целей и организации параллельн
ой работы, например, проверки правописания в документе.
CUA требуют конкретного стиля блоков диалога Open и Save As. Имеющийся в ObjectWindows блок диалога отвечает этим требованиям.
Рекомендации по разработке
- Выбирайте размер головного окна. Реализуйте только ваши  действительные потребности в отображении запрашиваемой  информации и предоставления нужной области клиента.
- Аккуратно изменяйте размеры окна. У вас есть два выбора  прорисовки окна после изменения его размеров. Вы можете  перерисовать содержимое окна в его первоначальных пропорциях.  При этом если окна станет слишком маленьким, вы можете потерять  из вида ча
сть изображения. Этот способ лучше всего подходит для  приложений типа "что видите, то и получаете". Либо вы можете  изменить масштаб изображения таким образом, чтобы оно  соответствовало новым рамкам окна. Этот способ больше подходит  для игры или утили
ты.
- Разумно используйте цвет. Цвет должен усиливать установленную  связь между приложением и пользователем. Цветовое решение нужно  реализовывать последовательно и пользователь должен иметь  возможность заменить любой из используемых цветов.
Написание безопасных программ
Обрабатывать ошибки в диалоговом интерфейсе пользователя значительно сложнее, чем в утилите с командной строкой. В недиалоговом приложении вполне допустимо (и даже предполагается), что возникновение ошибки вызывает появление сообщения об ошибке и выполне
ние программы прекращается. В диалоге программа должна обработать ошибку и перевести диалог с пользователем в допустимое состояние. Независимо от природы происхождения ошибок нельзя допускать, чтобы они портили информацию, над которой работает пользовате
ль, или прекращали выполнение программы. Если программа отвечает вышеприведенному критерию, то ее можно назвать безопасной.
ObjectWindows способствует написанию безопасных программ. Он выдерживает стиль программирования, который облегчает обнаружение и обработку ошибок, особенно те из них, которые связаны с нехваткой памяти. Это делается путем реализации концепции атомных опе
раций.
Программировать или все или ничего
Атомные операции это операции, которые не могут быть раздроблены на более мелкие операции. Применимо к предмету нашего рассмотрения это операции, которые либо полностью не удаются, либо проходят совершенно успешно. Атомный стиль операций особенно помогае
т при операциях по выделению памяти.
Обычно программы выделяют память путем многих маленьких запросов. Например, при конструировании объекта блока диалога вы выделяете память для блока диалога и для любых других объектов, которыми владеет диалог, например, для его дочерних управлений. Каждо
е из таких размещений потенциально может закончиться неудачно, и каждый возможный сбой требует анализа, делать ли следующее размещение или остановиться. Если какое-либо из размещений будет неудачным, то нужно деаллокировать всю успешно выделенную память.
 В идеальном случае вы будет делать все размещения а уже затем проверять, не сорвалось ли какое-нибудь из них.
Буфер безопасности
ObjectWindows выделяет фиксированный объем памяти (8К), называемый буфером безопасности. Если выделение памяти в динамической области захватывает буфер безопасности, то функция системы LowMemory возвращает значение True. Это является указанием на то, что
 последующие размещения не являются безопасными и могут закончиться неуспешно.
Для того, чтобы буфер безопасности был эффективным, он должен быть того же размера, что и максимальное атомное размещение. Другими словами, он должен настолько большим, чтобы все размещения между проверками LowMemory были успешными. 8К будет достаточно д
ля большинства приложений.
При первом запуске вашего приложения оно создает свое головное окно и его дочерние окна, проверяя при этом условия нехватки памяти. Однако, если ваше приложение создает окна или диалоги как динамические объекты в произвольный момент после отображения гол
овного окна, при этом вы должны явно вызывать механизм проверки условий нехватки памяти. Такие ситуации возникают при создании блоков диалога или всплывающих окон в ответ на выбор варианта меню. Однако, приложения MDI делают проверку условий нехватки пам
яти при создании дочерних окон.
Для проверки ситуации нехватки памяти при создании окон или немодальных диалогов замените вызов Create вашего окна вызовом MakeWindow, метод TApplication, унаследованный вашим типом приложения. Данный метод создает окно без проверки возможной ситуации не
хватки памяти:
procedure TMyWindow.Help(var Msg: TMessage);
var
 HelpWnd: PHelpWindow;
begin
 HelpWnd:=New(PHelpWindow, Init(@Self, 'Help System'));
 HelpWnd^.Create;
end;
Данный метод проверяет возможность ситуации нехватки памяти:
procedure TMyWindow.Help(var Msg: TMessage);
var
 HelpWnd: PHelpWindow;
begin
 HelpWnd:=Application^.MakeWindow(New(PHelpWindow, Init(@Self,
  'Help System')));
 if HelpWnd <> nil then {окно успешно создано}
end;
Для задания объекта приложения вашей программы используйте глобальную переменную Application, определенную для каждого приложения ObjectWindows. MakeWindow возвращает указатель на объект окна или nil если создание завершилось неуспешно.
Для проверки возможности ситуации нехватки памяти при исполнении модальных диалогов вызовете метод ExecDialog, унаследованный типом вашего приложения вместо вашего метода диалога Execute.
procedure TTestWindow.RunDialog(var Msg: TMessage);
var
 TestDlg: PTestDialog;
 RetValue: Integer;
begin
 TestDlg:=New(PTestDialog, Init(@Self, 'DIAL1'));
 if RetValue=id_Cancel then
  {ошибка формирования диалога или пользовательский сбой}
end;
Если все прошло успешно, ExecDialog возвращает значение диалога, обычно ноль или положительное целое. Если запуск диалога не удался, ExecDialog возвращает одну из нескольких констант ошибки, которые представляют собой целые отрицательные значения. Эту си
туацию очень важно сразу же заметить, т.к. сбой диалога автоматически приводит к уничтожению объекта диалога. До уничтожения объекта диалога следует проверить, не возвратил ли он отрицательного значения.
MakeWindow и ExecDialog извещают объект приложения о возникновении ситуации нехватки памяти путем вызова метода объекта приложения Error с константой em_OutOfMemory в качестве аргумента. Унаследованный от TApplication метод Error выводит на экран блок со
общения, информирующий пользователя о возникновении ошибочных условий.
Другие ошибки при создании окон
Кроме ситуации нехватки памяти имеется ряд других условий, которые могут помешать созданию или корректному отображению окна или блока диалога. Например, Microsoft Windows может не разрешить создание элемента интерфейса из-за нехватки памяти Windows или н
екорректных значений, переданных в функцию Windows. Для выхода из ошибочной  ситуации приложение должно быть информировано об этих ошибках,  подобных нехватки памяти. 
Информация о других ошибках, возникающих при создании окон, автоматически поступает от методов ObjectWindows, которые конструируют и создают объекты интерфейса. TWindowsObject определяет поле Status типа Integer, значение которого есть ноль, если нет ник
аких ошибок. Если была ошибка, то будет установлено одно из следующих значений:
Таблица 19.1. Значения ошибок при создании окон
----------------------------------------------------------------
Ошибка                   Значение
----------------------------------------------------------------
cm_OutOfMemory           Выделение памяти захватывает буфер 
                         безопасности.
em_InvalidWindow         Элемент окна не может быть создан.
cm_InvalidClient         Объект окна MDI не способен создать
                         окно его клиента.
em_InvalidChild          Одно или несколько дочерних окон объекта 
                         генерируют ошибку.
em_InvalidMainWindow     Головное окно не может быть создано.
----------------------------------------------------------------
Для проверки ошибки в написанном вами конструкторе окна и методе создания, установите значение Status равным одному из перечисленных значений констант или одному из ваших собственных констант. Например, если окно должно открыть файл, но ему это не удаетс
я, оно может сообщить об этом константой, например, cm_FileOpenError. Если TWindow.Create или TDialog.Execute возвращает ненулевое значение, будучи вызванным соответственно MakeWindow или ExecDialog, вызывающий метод автоматически сообщит об ошибке метод
у Error вашего типа окна, который по умолчанию просто вызывает метод Error вашего типа приложения. Вы можете переписать метод Error вашего окна или типа приложения для надлежащей обработки ошибки.
constructor EditorWindow.Init(AParent: PWindowsObject; ATitle: PChar;
 AFileName: PChar);
begin
 TWindow.Init(AParent; ATitle);
 if (Status >= 0) and not OpenTheFile(AFileName) then
  Status:=em_FileOpenError;
end;
Основные пользователи
Вы также должны проверять условия нехватки памяти для основных его потребителей, т.е. для объектов окна, которые выделяют размер памяти, больший, чем размер буфера безопасности (например, для считывания всего содержимого файла в память). Основные потреби
тели памяти должны проверять LowMemory сами, вместо завершения всех построений и разрешая затем сделать это за них MakeWindow. 
Если основной потребитель памяти выходит за допустимые ее размеры в середине собственного построения, то он должен установить флаг Status на значение ошибки и остановить всякие попытки выделить дополнительную память. Флаг Status будет проверен методом Ma
keWindow, который сообщит об ошибке и уничтожит объект окна.
Конечно очевидно, что это не так хорошо, как предполагать, что ваши конструкторы работают, но это единственный способ управления конструированием окна, размеры которого превосходят буфер безопасности.