Традиционный графический подход к интерфейсу с пользователем связан с работами Сазерленда, Ньюмена и др. , в котором взаимодействие базируется на использовании графического дисплея с регенерацией и светового пера. Дальнейшее развитие графического диалога связано с прогрессом в области систем интерактивной машинной графики, который привел к регламентации в виде международных стандартов.
GKS - первый международный графический стандарт. В нем впервые зафиксированы концепции "рабочих станций" и логических устройств ввода (клавиатура, выбор, локатор, валюатор, указатель, ввод последовательности координат). К сожалению задуман во время превосходства парадигмы векторного рисования. Отсюда слабость поддержки диалога: отсутствие возможности ввода новых устройств или видоизменения изображения устройства на экране даже из прикладной программы (пользователя графического пакета), что приводит к необходимости использования в основном символьного ввода при организации диалога. Реализация диалога в GKS прерогатива прикладной программы, возможности раздельного проектирования не предполагается.
Второе направление графики - растровая графика оказала чрезвычайно большое влияние на все последующее развитие интерактивных систем. Все основные черты интерфейса с пользователем на современных рабочих станциях суть производные от работ Xerox PARC: управление окнами

  • использование графических символов ("икон") для представления объектов
  • стиль взаимодействия, называемый непосредственным манипулированием
  • популярность "мыши" как устройства позиционирования на экране
  • объектно-ориентированный стиль программирования.
С тех пор система классификации инструментария для создания и управления пользовательским интерфейсом рассматривается на трех уровнях:
  1. системы управления окнами (WMS - Window Manager System);
  2. специализированный инструментарий;
    • обычный (MacIntosh, SunView . . .)
    • объектно-ориентированный (Smalltalk-80, Andrew, InterView)
  3. системы управления пользовательским интерфейсом.
В следующих разделах будут даны краткие характеристики, статус и функциональное описание каждого из этих уровней.

Системы управления окнами (WMS)

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

  • перекрывающихся окон (прямоугольных областей экрана);
  • различных устройств ввода (цифровых и аналоговых);
  • курсоров;
  • шрифтов.
Интерфейс со стороны оператора и прикладной программы содержит команды заведения/уничтожения окон, изменения их размеров и положения, поднятие наверх, сжатия окна до пиктограммы и восстановления. Содержит графическую библиотеку вывода (только основные примитивы) и обработчик событий. Тем самым есть некие механизмы для реализации пользовательского интерфейса.
Возможны реализации WMS двух типов: базовая система (Kernel System), работающая на одной машине, и сетевая (Network oriented), реализуемая на основе модели клиент-сервер.

Инструментарий создания пользовательского интерфейса

Стандарт GUI.

Одно из важнейших изменений в компьютерной индустрии – появление графического интерфейса. Поэтому возникла необходимость принять стандарты GUI, которые определяют, как должны выглядеть приложения под Windows? Macintosh и т.д. Существуют даже сертификационные программы к требованbям которых продавцы приспосабливают свои приложения, чтобы получить значок Windows. Это делается по нескольким причинам.

Одно из достоинств Windows или Mac – их стандартный вид. Когда вы научились работать в одном из них, считайте, что владеете и остальными. Большинство приложений под Windows используют одни и те же соглашения, поэтому вы знаете как открыть, сохранить, распечатать, закрыть и скопировать файл в любом из них. Стандартный интерфейс очень удобен для пользователей. Нужно стараться, чтобы ваши приложения были похожи на другие приложения под Windows с которыми пользователи уже научились работать. Есть семь общих принципов разработки GUI. Если вы изучите их и будете им следовать, с дизайном ваших приложений будет все в порядке.

Семь принципов разработки GUI.

Семь общих принципов разработки GUI взяты из руководства по интерфейсу Micrisoft Windows. Они формируют схему, на основании которой вы можете создавать собственные стандарты. Эта схема дает разработчикам и пользователям два существенных преимущества. Во-первых, приложения выглядят профессионально. Во-вторых, они функциональны, согласуются с другими приложениями и легко осваиваются пользователями.

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

1. Позволяйте пользователю контролировать приложение.

2. Следуйте парадигме объект/действие.

3. Будьте последовательны.

4. Сделайте работу с приложениями простой и очевидной.

5. Стремитесь к гармонии.

6. Обеспечьте пользователю обратную связь.

7. Будьте снисходительны

Принцип первый: дайте возможность пользователю контролировать приложение.

Пользователь должен управлять приложением, то есть иметь доступ к каждому модулю приложения из любого другого модуля. Раньше для такого доступа использовалось иерархическое меню.


Допустим пользователь хочет добавить нового клиента В примере, пользователь должен для этого перейти в модуль ACCOUNTS RECCIEVAble и затем добавить откуда нового клиента. Откуда ему знать, что нужно делать? Вероятно, из своего опыта работы с этим приложением. А в мире GUI пользователь просто выбирает в меню сначала команду New (Новый), потом Customer (Клиент), как показано на рис. В этой современной системе можно добавить нового клиента, продавца или пункт инвентаризационной записи посредством меню File (Файл). Это позволяет изменить запись клиента, находясь в экране продавца, и наоборот. Пользователю не нужно больше разбираться в сложном и запутанном иерархическом меню.

Принцип второй: следуйте парадигме объект/действие.

Парадигма объект/действие гласит, что над всеми объектами системы можно выполнить какую-либо операцию. Наиболее простой и очевидный пример – экран поддержки базы клиентов (рис). Экран содержит набор кнопок и каждая из низ позволяет произвести некоторое действие над информацией о выбранном клиенте. Можно удалить ее, отредактировать, распечатать и т.д. Действия, которые можно выполнить над определенным клиентом, должны быть доступны или недоступны в соответствующие моменты времени. Например, когда запись покупателя находится в режиме редактирования, кнопки Delete (Удалить) и New (Новый) следует деактивировать.

Принцип третий: будьте последовательны.

Последовательность – один из важнейших принципов разработки GUI. GUI – позволяют пользователям изучить больше приложений, чем старые программы. И все это благодаря принципу последовательности. Когда пользователь сталкивается с новым приложением, он уже знаком с основными командами: открытие, печать и сохранение файлов. Разработанные на этих платформах приложения обычно согласуются между собой.

Таким образом, создавая новые приложения, будьте последовательны. Если для добавления новой записи употреблена команда New (Новый), используйте ее везде. Не следует заменять это слово другими – например, словом Add 9добавить). Благодаря вашей последовательности пользователи будут знать: где им ни встретилась команда New (Новый), е можно использовать для добавления новой записи.

Принцип четвертый: сделайте работу с приложением простой и очевидной.

Можно выразить эту мысль и так: не употребляйте жаргона. Есть экран с двумя кнопками. На одной из них написано «Упаковать базу данных», а на другой – «Убрать записи с пометкой на удаление». Вторая запись наверняка будет более понятна пользователю.

При разработке приложений часто возникает соблазн применить в интерфейсе программистский сленг. Старайтесь по возможности избегать этого.

Принцип пятый: стремитесь к гармонии

Даже в черно белом виде этот экран имеет существенный эстетический недостаток: белый фон и на нем контрастные объекты. На рис. Тот же самый экран выглядит хорошо сбалансированным в цветовом отношении.

В Windows можно передать миллионы цветовых комбинаций. Означает ли это, что их все нужно использовать? Разумеется, нет. Следует выбирать простые, спокойные цвета и избегать их беспорядочного смешения, которое почему-то нравится некоторым программистам.

Принцип шестой. Обеспечивайте пользователю обратную связь.

Представьте себе, что в вашем приложении есть процесс, который долго выполняется. В течение этого времени на экран можно выводить сообщение примерно такого содержания: «Программа работает, подождите пожалуйста». Удобное решение; но откуда пользователю знать, что она не зависла? Поэтому весьма вероятно, что он отдаст приложению «салют тремя пальцами» (Ctrl+Alt+Del), хотя с программой все будет в порядке.

Лучше показать пользователю, какая часть процесса выполнена. Тогда он не прервет программу понапрасну, сможет оценить, как далеко продвинулась работа, и заняться другими делами, пока процесс не завершится. Таким образом, производительность труда пользователя повысится примерно на 25 процентов. Этого результата можно достичь простым выводом измерителя на экран. Обычно выводятся сообщения типа «10 из 100 записей обработано» или «40% завершено». Еще лучше показать как число обработанных записей, так и их процент»

Принцип седьмой: будьте снисходительны

Каждый из нас иногда удалял запись, нечаянно нажав не ту кнопку. Поэтому оставьте пользователю возможность передумать или отменить только что произведенные действия. Если процесс занимает длительное время, изменяет большой объем данных или требует, чтобы пользователь создал резервную копию данных перед выполнением действия, необходимо выдать соответствующее предупреждение, Мне приходилось видеть приложения, которые требуют подтверждения дважды, а потом еще спрашивают пароль. Нужны ли вашим программам защиты такого уровня? Возможно. Задача разработчика – помочь пользователю, если тот сделал ошибку на любом этапе работе.

Важность соглашений по стандарту GUI.

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

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

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

¦ Следует избегать сложных структур (типа дерева) для связи различных меню. В одну линейку меню лучше всего включать не более шести меню, каждое из которых будет содержать не более шести опций.

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

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

¦ При активизации всех пиктограмм, как отмечалось выше, следует использовать двойной щелчок мышью. А для получения аналогичного результата для пиктограмм объектов, которые активизируются одинарным щелчком мышью, рекомендуется также запрограммировать двойной щелчок. Многие опции, например из меню Control Panel, выглядят как пиктограммы, но являются объектами, которые активизируются одинарным щелчком мышью. Следует предусмотреть возможное поведение пользователей при работе с такими объектами (т.е. допустить, что они будут дважды щелкать по ним мышью) и помочь им достигнуть желаемого результата.

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

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

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

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

Эргономических требований к графическим интерфейсам пользователя оказалось явно недостаточно с развитием «мультимедиа» (multimedia) - интерактивных систем, обеспечивающих работы с неподвижными изображениями и движущимся видео, анимированной компьютерной графикой и текстом, речью и высококачественным звуком. Эргономические исследования и разработки этих систем представляют сложную и в профессиональном отношении увлекательную задачу.

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

1) понять назначение программного продукта во всех деталях путем тесного общения с пользователями, проводя зачастую с ними целые рабочие дни, чтобы лучше понять стиль их работы и индивидуальные привычки;

2) создание интерфейса - это работо не одиночки, а представителей трех областей: специалиста, который выясняет мнение пользователей об основных элементах интерфейса и описывает их; разработчика интерфейса и создателя графики;

3) один опытный сотрудник должен быть нозначен экспертом по интерфейсу и посредником между рабочей группой и пользователями;

4) проверка, создание макета и снова проверка, так как даже если совершенно точно понято назначение программного продукта, невозможно предусмотреть все потребности пользователей.

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


09 июля 2003г.

С появлением разнообразных визуальных средств разработки приложений, написание графических интерфейсов программ превратилось в подобие детской игры. Ткнул мышкой - появилась формочка, второй раз ткнул - кнопочка нарисовалась. Как мне кажется, многие сейчас не помышляют об ином способе программирования в графической среде. Безусловно, против прогресса не попрешь, при написании больших проектов все эти удобства очень даже кстати. Но разговор не об этом. Иногда дело доходит до абсурда, примитивное приложение пишется с использованием MFC, VCL etc. Такие программы жрут память, как термиты и занимают, своим жирным телом, лишнее дисковое пространство. Как правило, MFC/VCL аналоги "весят" в десять - двадцать раз больше, чем программы написанные на чистом API. А Visual Basic (да простит меня бог за это словосочетание) с его msvbvmXX.dll? Да и системных ресурсов расходуется значительно больше (в несколько раз). Бедные пользователи, отказывая себе в пиве, копят ассигнации на покупку нового железа. Разве не жалко - бедненьких? Не только же программерам пиво пить? Есть еще один положительный момент в API кодинге, программист становится ближе к операционной системе. Соответственно - лучше ее понимает и контролирует. Да и просто - это очень увлекательное занятие. Повторюсь, все вышесказанное относится именно к маленьким, простеньким программкам, в больших проектах все обстоит совершенно иначе.

Надеюсь, убедил. Поехали.

Мы рассмотрим создание простенького оконного интерфейса с минимальной функциональностью. Это будет простое окошко с двумя полями ввода и двумя кнопочками. При нажатии на кнопку "Copy", текст из первого поля ввода будет скопирован во второе. При нажатии на кнопку "Close", программа завершит свою работу. В дальнейшем оно может послужить шаблоном для написания других, более сложных, приложений. Будем общаться на языке C/C++, хотя и Delphi не обидим. Общий принцип один и тот же, различается только синтаксис. Чтобы работать с системными сообщениями и API-функциями, необходимо к своему проекту подключить заголовочные файлы; в C/C++ это windows.h, в Delphi это модули windows и messages.

Любая программа в ОС Windows состоит из трех основных частей: главной функции, цикла обработки сообщений и оконной функции, которая обрабатывает все сообщения, посылаемые окну.

Наша программа начинает выполняться с функции WinMain(). Это и есть главная функция. Функция WinMain() выполняет, обычно, следующие задачи:

  • Определяет класс окна. Не путать с классом ООП.
  • Регистрирует данный класс в системе.
  • Создает главное окно приложения и другие элементы управления.
  • Отображает окно на экране.
  • Запускает цикл обработки сообщений.
  • Объявляется она вот каким образом: int APIENTRY WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow) Разберемся с параметрами:
    • hInstance - дескриптор текущего экземпляра приложения.
    • hPrevInstance - дескриптор предыдущего экземпляра приложения, если оно запущено.
    • lpCmdLine - указатель на строку, содержащую параметры передаваемые программе при запуске.
    • nCmdShow - константа определяющая способ отображения окна. (Смотри константы SW_).

В Delphi мы не увидим такой картины, в этой среде разработки главная функция скрывается от программиста компилятором. Хотя, несомненно, она присутствует в конечном коде. Для регистрации класса окна, необходимо заполнить поля структуры типа WNDCLASS (в Delphi TWNDCLASS). У нас, для этого, объявлена переменная wcl. wcl.hInstance = hInstance; Дескриптор текущего экземпляра приложения, переменная hInstance инициализируется функцией WinMain(). В Delphi инициализируется неявным образом. wcl.lpszClassName = szWinName; Имя класса. Строковую переменную szWinName мы создали и инициализировали предварительно. wcl.lpfnWndProc = WindowFunc; Указатель на оконную функцию. wcl.style = 0; Константа, задающая стиль окна. Для этого используется флаги CS_, я просто обнулил. Можно задавать комбинацию флагов с помощью битовой операции "или". wcl.hIcon = LoadIcon(NULL, IDI_ASTERISK); Дескриптор иконки приложения, возвращаемый функцией LoadIcon(). Я загрузил стандартную иконку. Смотри константы IDI_. wcl.hCursor = LoadCursor(NULL,IDC_ARROW); Дескриптор курсора приложения, возвращаемый функцией LoadCursor(). Я загрузил стандартную стрелочку. Смотри константы IDC_. wcl.lpszMenuName = NULL; Указатель на строку, задающую имя ресурса меню для данного оконного класса. Нет меню, нет и указателя. wcl.cbClsExtra = 0; Зарезервированное поле. Обнуляем. wcl.cbWndExtra = 0; Зарезервированное поле. Обнуляем. wcl.hbrBackground = (HBRUSH)COLOR_WINDOW; Цвет окошка. Константа COLOR_WINDOW приводится к типу HBRUSH (в Delphi приводить не нужно). Также, с помощью функции GetStockObject(), можно задать цвет кисти окна или фоновый рисунок. Теперь, смело, регистрируем класс окна.

RegisterClass(&wcl); В качестве параметра функции RegisterClass передается указатель на структуру wcl.

Следующей строкой мы создаем наше окно.

hMainWnd = CreateWindow(szWinName, "Простое окно на API." , WS_OVERLAPPEDWINDOW ^ WS_THICKFRAME ^ S_MAXIMIZEBOX, CW_USEDEFAULT, CW_USEDEFAULT, 300, 170, HWND_DESKTOP, NULL, hInstance, NULL);
  • Первый параметр - имя класса окна.
  • Второй параметр - Заголовок окна.
  • Третий параметр - стиль окна. Из стандартного WS_OVERLAPPEDWINDOW, с помощью операции xor, я изъял возможность масштабирования окна и отключил кнопку максимизации.
  • Четвертый и пятый - положение окна от левого, верхнего угла экрана. У меня CW_USEDEFAULT, при этом значении система выбирает положение окна автоматически.
  • Шестой и седьмой параметры - ширина и высота окна, соответственно.
  • Восьмой параметр - окно владелец. У главного окна, владелец - рабочий стол (0). У элементов управления - главное окно.
  • Девятый - указатель на дескриптор меню. Нет меню, нет и указателя.
  • Десятый параметр - Дескриптор текущего экземпляра приложения.
  • Одиннадцатый - Используется при создании приложений с MDI-интерфейсом. Нам не нужен.
Функция возвращает дескриптор созданного окна, который заносится в переменную hMainWnd.
Дескриптор окна - уникальный номер в системе, по которому идентифицируется окно или элемент управления.

Далее мы создадим необходимые элементы управления. Все элементы управления - те же окна, просто они имеют другое имя класса. Классы элементов управления регистрировать не нужно, они уже предопределены в системе. Кнопка - класс button. Поле ввода - класс edit. Надпись - класс ststic. Существует множество классов, которые соответствуют стандартным элементам управления. Контролы создаем с помощью, знакомой нам, функции CreateWindow() и незнакомой CreateWindowEx(). CreateWindowEx() позволяет создать окно с расширенным стилем. Мы используем ее для создания полей ввода. В этой функции добавлен первый параметр, который и задает этот самый расширенный стиль, остальные параметры как у CreateWindow(). Элементы управления являются дочерними окнами, их владелец главное окно.

Создавая контролы, в параметрах функции необходимо указать дескриптор главного окна, а также стиль окна WS_CHILD. Внешним видом и функциональностью элементов управления можно манипулировать с помощью флагов: WS_, ES_, BS_, SS_, объединяя их битовой операцией "или". Создавая контролы, мы инициализируем соответствующие переменные их дескрипторами, которые возвращают функции CreateWindow() и CreateWindowEx(). Эти дескрипторы понадобятся нам для дальнейшей работы с элементами управления. Отображаем, созданное нами, окно на экране и перерисовываем его.

Функция GetMessage выбирает очередное сообщение из очереди сообщений приложения и отправляет его окну.
  • Первый параметр - структура типа MSG (в Delphi типа TMSG)
  • Второй параметр - дескриптор окна, которому предназначено сообщение. Если NULL или 0, то все окна приложения.
  • Третий и четвертый - позволяют задать диапазон принимаемых сообщений. Если 0, то все сообщения, адресованные окну.
GetMessage - возвращает FALSE при появлении сообщения WM_QUIT, в этом случае происходит выход из цикла и приложение завершает работу. TranslateMessage - переводит виртуальные коды клавиш в клавиатурные сообщения. DispatchMessage - отправляет сообщение оконной функции, для обработки.

Оконная функция обеспечивает функциональность программы, путем обработки системных сообщений. Оконная функция является CALLBACK - функцией, т.е. вызывается операционной системой в ответ на поступившее, новое сообщение. Оконная функция объявлена таким образом:

LRESULT CALLBACK WindowFunc(HWND hMainWnd, UINT iMsg, WPARAM wParam, LPARAM lParam)

  • HMainWnd - дескриптор главного окна.
  • iMsg - номер сообщения. Смотри константы WM_.
  • lParam и wParam - параметры сообщения.

При появлении сообщения, мы можем сравнить параметр iMsg с одной из констант WM_ и запрограммировать соответствующую реакцию программы.

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

Внутри оконной функции расположен оператор выбора, который и выполняет вышеописанную задачу. В операторе выбора обязательно должен быть организован обработчик по умолчанию, который реализуется функцией DefWindowProc(hMainWnd, iMsg, wParam, lParam);

Если этого не сделать, наша программа издохнет так и не ожив. Множество сообщений, обрабатывается самой системой, такие как: изменение размеров окна, сворачивание/разворачивание окна, вызов системного меню etc. Для этого и служит DefWindowProc().

При работе с оконными элементами управления, окну владельцу посылается сообщение WM_COMMAND, при этом lParam содержит дескриптор элемента управления, а старший байт параметра wParam - идентификатор события, вызванного в элементе управления. Например: при нажатии на кнопку - BN_CLICKED. Смотри константы BN_, WM_. Закрыть прогу мы можем использовав функцию PostQuitMessage(0). Эта функция посылает окну сообщение WM_QUIT.

Несколько слов о том, как писать такие программы на Delphi. Создаем новый проект, запускаем Project Manager, удаляем Unit1 вместе с формой. Жмем Ctrl + F12 и открываем файл проекта. Удаляем из uses модуль forms, добавляем туда windows и messages. Удаляем все между begin и end. Заготовка готова. Можно кодить. Писать программы на чистом API невозможно без справки, которая всегда должна быть под рукой. Будь ты самим Гейтсом - все не запомнить. Рекомендую:

  • прежде всего - MSDN ;
  • справочная система Delphi (файл MSTOOLS.HLP);
  • на сайте http://www.soobcha.ru/rushelp есть русская справка по Win32 API.
Вот и все.
Удачи.

Бобаченко Максим Скачать: CreateWnd.zip (2.6 K)
архив содержит файлы windows.cpp и windows.dpr

yadobr 14 января 2014 в 09:10

Проектирование графического интерфейса пользователя

  • Интерфейсы

Введение

В современном мире миллиарды вычислительных устройств. Еще больше программ для них. И у каждой свой интерфейс, являющийся «рычагами» взаимодействия между пользователем и машинным кодом. Не удивительно, что чем лучше интерфейс, тем эффективнее взаимодействие.

Однако далеко не все разработчики и даже дизайнеры, задумываются о создании удобного и понятного графического интерфейса пользователя.

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

Общие принципы


Какие ЭИ создать?


Какой должен быть дизайн ЭИ?

На самом деле, дизайн ЭИ - тема отдельной статьи. Тут нужно учитывать все: начиная от цвета, формы, пропорций, заканчивая когнитивной психологией. Однако, несколько принципов все же стоит отметить:

Как правильно расположить ЭИ на экране?


Как ЭИ должны себя вести?


В заключении

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

Литература

Джеф Раскин , «Интерфейс: новые направления в проектировании компьютерных систем»
Алан Купер , «Об интерфейсе. Основы проектирования взаимодействия»
Алан Купер , «Психбольница в руках пациентов»