В этом уроке мы с помощью Studio.Net научимся разрабатывать традиционные приложения Win32, основанные на использовании функций API (Application Programming Interface). Вы, конечно, знаете, что приложения для Windows можно разрабатывать как с использованием библиотеки классов MFC, так и на основе набора инструментов, объединенных в разделе SDK (Software Development Kit) студии разработчика. Обширную документацию по SDK вы можете найти в MSDN (Microsoft Developer's Network), которая поставляется вместе со студией. Отдельные выпуски MSDN, зачастую содержат еще более свежую информацию по SDK. Без MSDN успешная деятельность в рамках студии разработчика просто немыслима.

Использование всей мощи MFC облегчает процесс разработки приложений, однако далеко не все возможности Win32 API реализованы в библиотеке MFC, многие из них доступны только средствами API. Поэтому каждому разработчику необходимо иметь представление о структуре и принципах функционирования традиционного Windows-приложения, созданного на основе API-функций. Другими доводами в пользу того, что существует необходимость знать и постоянно углублять свои познания в технологии разработки приложений с помощью SDK, могут быть следующие:

каркас MFC-приложения, так или иначе, содержит внутри себя структуру традиционного Windows-приложения;
многие методы классов MFC содержат, инкапсулируют вызовы API-функций;
накоплен огромный банк готовых решений на основе SDK, которые достаточно просто внедряются в приложения на основе MFC, и не пользоваться которыми означает обеднять себя.
В состав API входят не только функции, более 2000, но и множество структур, более 800 сообщений, макросы и интерфейсы. Цель настоящей статьи:

показать традиционную структуру Windows-приложения;
продемонстрировать способы управления таким инструментом подсистемы GDI (Graphics Driver Interface), как перо Windows.
Основной чертой всех Windows-приложений является то, что они поддерживают оконный интерфейс, используя при этом множество стандартных элементов управления (кнопки, переключатели, линейки, окна редактирования, списки и т. д.). Эти элементы поддерживаются с помощью динамических библиотек (DLL), которые являются частью операционной системы (ОС). Именно поэтому элементы доступны любым приложениям, и ваше первое приложение имеет почти такой же облик, как и любое другое. Принципиально важным отличием Windows-приложений от приложений DOS является то, что все они — программы, управляемые событиями (event-driven applications). Приложения DOS — программы с фиксированной последовательностью выполнения. Разработчик программы последовательность выполнения операторов, и система строго ее соблюдает. В случае программ, управляемых событиями, разработчик не может заранее предсказать последовательность вызовов функций и даже выполнения операторов своего приложения, так как эта последовательность определяется на этапе выполнения кода.

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

Примечание

Если вы хотите получить более полное представление о процессах и потоках в Windows, то см. статьи далее на сайте.

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

Программист может создать и определить какие-то свои собственные сообщения, действующие в пределах зарегистрированного оконного класса. В этом случае каждое новое сообщение должно иметь идентификатор, превышающий зарезервированное системой значение WM_USER (0x400). Допустим, вы хотите создать сообщение о том, что пользователь нажал определенную клавишу в тот момент, когда клавиатурный фокус находится в особом окне редактирования с уже зарегистрированным классом. В этом случае новое сообщение можно идентифицировать так:

#define WM_MYEDIT_PRESSED WM_USER + 1

Каждое новое сообщение должно увеличивать значение идентификатора по сравнению с WM_MYEDIT_PRESSED. Максимально-допустимым значением для идентификаторов такого типа является число 0x7 FFF. Если вы хотите создать сообщение, действующее в пределах всего приложения и не конфликтующее'с системными сообщениями, то вместо константы WM_USER следует использовать другую константу WM_APP (0x8000). В этом случае можно наращивать идентификатор вплоть до 0xBFFF.

 

 

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

функции winMain, с которой начинается выполнение программы и которая «закручивает» цикл ожидания сообщений (message pump);
оконной процедуры, которую вызывает система, направляя ей соответствующие сообщения.
Каждое приложение в системе, основанной на сообщениях, должно уметь получать и обрабатывать сообщения из своей очереди. Основу такого приложения в системе Windows представляет функция winMain, которая содержит стандартную последовательность действий. Однако обрабатывается большинство сообщений окном — объектом операционной системы Windows.

Примечание

C точки зрения пользователя, окно — это прямоугольная область экрана, соответствующая какому-то приложению или его части. Вы знаете, что приложение может управлять несколькими окнами, среди которых обычно выделяют одно главное окно-рамку (Frame Window). С точки зрения операционной системы, окно — это в большинстве случаев конечный пункт, которому направляются сообщения. С точки зрения программиста, окно —это объект, атрибуты которого (тип, размер, положение на экране, вид курсора, меню, зна-чек, заголовок) должны быть сначала сформированы, а затем зарегистрированы системой. Манипуляция окном осуществляется посредством специальной оконной функции, которая имеет вполне определенную, устоявшуюся структуру.

Функция winMain выполняется первой в любом приложении. Ее имя зарезервировано операционной системой. Она в этом смысле является аналогом функции main, с которой начинается выполнение С-программы для DOS-платформы. Имя оконной процедуры произвольно и выбирается разработчиком. Система Windows регистрирует это имя, связывая его с приложением. Главной целью функции winMain является регистрация оконного класса, создание окна и запуск цикла ожидания сообщений.

 

 

Если вы знакомы со структурой приложения Win32, то можете безболезненно пропустить несколько параграфов и перейти к параграфу с заголовком «Развитие начальной заготовки».

Рассмотрим более подробно структуру традиционного Windows-приложения, представленную нам мастером Win32 Application Wizard Studio.Net. Программа спроектирована как шаблон (стартовая заготовка), который можно развивать, внося в него желаемую разработчиком функциональность.

Создайте новый проект приложения Win32. Для этого:

В меню File > New выберите команду Project.
В появившемся диалоге New Project, в окне Project Type раскройте узел дерева под именем Visual C++ Projects и выберите узел Win32 Projects.
В окне Templates выберите тип проекта Win32 Project.
В окне Name задайте имя проекта: API. В окне Location задайте или оставьте без изменения местоположений новой папки с файлами решения (solution).
Нажмите ОК и проанализируйте предлагаемые по умолчанию мастером Win32 Application Wizard настройки проекта.
Нажмите кнопку Finish.
Запустите стартовую заготовку и убедитесь, что она создает окно с планкой меню и реагирует на shortcut-комбинацию Alt+? или Alt+/, создавая диалог About. Раскройте дерево в окне Class View студии и щелкните два раза имя глобальной переменной hlnst. Курсор переходит в окно редактора, где вы видите заготовку традиционного приложения Win32. Надо отметить, что она богаче оснащена, чем аналогичные заготовки предыдущих версий Visual C++. Кроме пяти функций здесь содержатся ресурсы (меню, диалог, значок, строки текста, и клавиатурный ускоритель). Вы можете убедиться в этом, раскрыв дерево ресурсов в окне Resource View, которое входит в блок страниц вместе с окном Class View. Анализ и развитие этой заготовки мы произведем немного позже, а сейчас приведем листинг, который создал мастер Win32 Application Wizard.1

// API.cpp : Определяет точку входа приложения

//

#include "stdafx.h"

#include "API.h"

#define MAX_LOADSTRING 100

//======== Глобальные переменные:

HINSTANCE hlnst;

// Текущий экземпляр

TCHAR szTitle[MAX_LOADSTRING];

// Текст заголовка окна

TCHAR szWindowClass[MAX_LOADSTRING];

// Текст регистрации

//======== Прототипы функций, входящих в данный модуль

ATOM MyRegisterClass(HINSTANCE hlnstance);

BOOL Initlnstance(HINSTANCE, int);

LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);

LRESULT CALLBACK About(HWND, UINT, WPARAM, LPARAM);

int APIENTRY WinMain(HINSTANCE hlnstance,

HINSTANCE hPrevInstance,

LPSTR IpCmdLine,

int nCmdShow)

{

//======= TODO: Помещайте код здесь

MSG msg;

HACCEL hAccelTable;

//======= Инициализация глобальных строк текста

LoadString(hlnstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING); LoadString(hlnstance, IDC_API, szWindowClass, MAX_LOADSTRING);

//======= Вызов функции регистрации приложения

MyRegisterClass(hlnstance);

//======= Инициализация приложения:

if (!Initlnstance (hlnstance, nCmdShow))

{

return FALSE;

}

//======= Загрузка клавиатурных ускорителей

hAccelTable = LoadAccelerators (hlnstance, (LPCTSTR)IDC_API);

//======= Цикл ожидания и обработки сообщений:

while (GetMessage(&msg, NULL, 0, 0))

if (!TranslateAccelerator(msg.hwnd, hAccelTable, Smsg))

{

TranslateMessage(Smsg);

DispatchMessage(Srasg);

}

}

return msg.wParam;

}

//

// FUNCTION: MyRegisterClass ()

//

// НАЗНАЧЕНИЕ: Регистрирует оконный класс

//

// COMMENTS: //

// Эта функция нужна только если вы хотите, чтобы код

// был совместим с Win32 системами, которые

// существовали до создания функции 'RegisterClassEx ' ,

// введенной в Windows 95.

// Вызов 'RegisterClassEx' необходим для правильного

// создания маленького (small) значка, ассоциированного

// с приложением.

//

ATOM MyRegisterClass (HINSTANCE hlnstance)

{

WNDCLASSEX wcex;

wcex.cbSize = sizeof (WNDCLASSEX) ;

wcex. style = CS_HREDRAW | CS_VREDRAW;

wcex.lpfnWndProc = (WNDPROC) WndProc;

wcex. cbClsExtra = 0;

wcex.cbWndExtra = 0;

wcex. hlnstance = hlnstance;

wcex.hlcon = Loadlcon (hlnstance,

(LPCTSTR) IDI_API) ;

wcex.hCursor = LoadCursor (NULL, IDC_ARROW) ;

wcex.hbrBackground = (HBRUSH) (COLOR_WINDOW+1) ;

wcex.lpszMenuName = (LPCSTR) IDC_API;

wcex. IpszClassName = szWindowClass;

wcex.hlconSm = Loadlcon (wcex. hlnstance, (LPCTSTR) IDI_SMALL)

return RegisterClassEx (&wcex) ;

}

//

// FUNCTION: Initlnstance (HANDLE, int)

//

// НАЗНАЧЕНИЕ: Запоминание описателя экземпляра

// приложения и создание главного окна приложения

//

// COMMENTS:

// В этой функции мы запоминаем описатель экземпляра

// приложения в глобальной переменной и создаем

// главное окно приложения.

//

BOOL Initlnstance(HINSTANCE hlnstance, int nCmdShow)

{

HWND hWnd;

//======= Запоминаем экземпляр приложения

hlnst = hlnstance;

//======= Создаем главное окно

hWnd = CreateWindow(szWindowClass, szTitle, WSJDVERLAPPEDWINDOW,CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hlnstance, NULL),

if (IhWnd) {

return FALSE; }

ShowWindow(hWnd, nCmdShow);

UpdateWindow(hWnd) ;

return TRUE; }

//

// FUNCTION: WndProc(HWND, unsigned, WORD, LONG)

//

// НАЗНАЧЕНИЕ: Обработка сообщений главного окна.

//

// WM_COMMAND - обработка команд меню

// WM_PAINT - перерисовка окна

// WM_DESTROY - посылка сообщения о завершении и выход

//

//

LRESULT CALLBACK WndProc (HWND hWnd, UINT message,

WPARAM wParam, LPARAM IParam)

{

int wmld, wmEvent;

PAINTSTRUCT ps;

HDC hdc;

switch (message)

{

case WM_COMMAND:

wmld = LOWORD (wParam) ;

wmEvent - HIWORD (wParam) ;

//====== Расшифровка выбора в меню:

switch (wmld)

{

case IDM_ABOUT:

DialogBox (hlnst, (LPCTSTR) IDD_ABOUTBOX, hWnd,

(DLGPROC)About) ;

break;

case IDM_EXIT:

DestroyWindow(hWnd);

break;

default:

return DefWindowProc(hWnd, message, wParam, IParara);

{

break;

//======= Ветвь перерисовки содержимого окна

case WM_PAINT:

hdc = BeginPaint(hWnd, sps);

//======= TODO: Вставьте сюда рисующий код

EndPaint(hWnd, Sps);

break; //======= Ветвь закрытия окна

case WM_DESTROY:

PostQuitMessage(0);

break; default:

return DefWindowProc(hWnd, message, wParam, IParam);

}

return 0;

}

//======= Обработчик команды вызова диалога About

LRESULT CALLBACK About(HWND hDlg, UINT message,

WPARAM wParam, LPARAM IParam)

{

switch (message)

{

//======= Ветвь инициализации окна диалога

case WM_INITDIALOG:

return TRUE;

//======= Ветвь обработки команд, исходящих

//======= от элементов управления диалога

case WM_COMMAND:

if (LOWORD(wParam) == IDOK ||

LOWORD(wParam) == IDCANCEL)

EndDialog(hDlg, LOWORD(wParam));

return TRUE;

}

break;

}

return FALSE;

}

 

 

Первые две строки являются директивами препроцессора, которые сообщают ему, что до того, как начать процесс компиляции модуля, следует вставить в указанное место файлы заголовков (stdafx.h и API.h). Первый файл мы обсуждали в уроке 1. Он содержит директивы подключения библиотечных файлов-заголовков. Директива

//======== Исключает редко используемые элементы

//======== Windows-заголовков

#define WIN32_LEAN_AND_MEAN

уменьшает размер исполняемого модуля, так как исключает те фрагменты каркаса приложения, которые редко используются. Второй файл (API.h) создал мастер. Вы можете открыть его с помощью окна Solution Explorer и увидеть, что он содержит лишь две строки:

#pragma once

#include"resource.h"

Директива fpragma once сообщает компилятору, что данный файл (API.h) должен быть использован при построении кода приложения только один раз, несмотря на возможные повторы (вида #include "API.h"). Вторая директива подключает файл с идентификаторами ресурсов. Сами ресурсы вы видите в окне Resource View. Все ресурсы приложения и их отдельные элементы должны быть идентифицированы, то есть пронумерованы. Новичкам рекомендуется открыть файл resource.h с помощью окна Solution Explorer и просмотреть его содержимое. В этом файле символическим именам (идентификаторам) IDS_APP_TITLE, IDR_MAINFRAME и т. д. соответствуют числовые константы, которые препроцессор вставит вместо идентификаторов еще до процесса компиляции. В конце файла содержатся пометки Studio.Net, определяющие дальнейший способ нумерации ресурсов различного типа. Рассматриваемый файл не рекомендуется редактировать вручную, так как в случае ошибок вы получите труднолокализуемые отказы. Studio.Net сама следит за состоянием resource.h, вставляя и удаляя макроподстановки #def ine по мере того, как вы редактируете ресурсы с помощью специальных редакторов.

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

HINSTANCE hlnst; // Текущий экземпляр

TCHAR szTitle[MAX_LOADSTRING];

// Текст заголовка окна

TCHAR szWindowClass[MAX_LOADSTRING];

// Текст регистрации

Рассматривайте описатель hlnst как адрес исполняемого модуля в пространстве процесса, соответствующего приложению. Если вы не знакомы с понятиями поток и процесс, то обратитесь к последнему уроку этой книги, где приведены некоторые сведения об архитектуре Windows. Текст регистрации szWindowClass будет загружен из ресурсов при выполнении winMain (см. вызов LoadString).

Примечание

Этот текст представляет собой строку символов «API», которая хранится в ресурсах. Ее можно увидеть, раскрыв дерево ресурсов в окне Resource View, узел String Table и дважды щелкнув на элементе String Table (group). С помощью этой строки ваше приложение регистрируется в операционной системе.

При вызове функции winMain система передает ей параметры:

hinstance — описатель экземпляра приложения. Это адрес приложения, загруженного в память. В Windows NT/2000 этот адрес для всех приложений имеет одно и то же значение 0x00400000 (4 Мбайт);
hPrevlnstance — описатель предыдущего экземпляра приложения. Этот параметр устарел и теперь не используется в приложениях Win32;
lpCmdLine — указатель на командную строку. Мы не будем использовать этот параметр;
nCmdShow — состояние окна при начальной демонстрации.
Ранее в Win 16 второй параметр использовался в целях экономии ресурсов, но в Win32 — это NULL, так как каждый экземпляр приложения теперь выполняется в своем собственном виртуальном адресном пространстве процесса емкостью 4 Гбайт. Все экземпляры процесса загружаются начиная с одного и того же адреса в этом пространстве (см. последний урок). Теперь рассмотрим алгоритм функции WinMain:

она загружает из ресурсов две рассмотренные выше строки текста;
создает, заполняет и регистрирует структуру типа WNDCLASS;
создает главное окно приложения;
загружает клавиатурные ускорители;
запускает цикл ожидания и обработки сообщений.
Основные атрибуты главного окна приложения задаются в структуре типа WNDCLASSEX. Понятие класс окна появилось до того, как появились классы C++. Поэтому структура WNDCLASSEX не имеет ничего общего с классами MFC. Она является типом структур языка С. Дело в том, что каждое Windows-приложение должно зарегистрировать атрибуты своего окна, а система использует их при создании окна. Структура WNDCLASSEX своими полями определяет некий шаблон или модель для создания окон данного класса. В полях структуры вы указываете необходимые атрибуты окна: адрес исполняемого модуля приложения, .адрес оконной процедуры, имя ресурса меню, набор битов для описания стиля окна, местонахождение изображения курсора, значка и т. д. Эту «неинтересную» работу выполняет большая часть кодов функции MyRegisterClass. Используя классы MFC, вы избавляете себя от подобной рутинной работы.

При регистрации класса окон (точнее, переменной типа WNDCLASSEX) операционная система связывает оконную процедуру (WndProc) с приложением. В winMain вы должны зарегистрировать главное окно приложения, остальные же окна, если они нужны, могут быть зарегистрированы и в других местах программы. Адрес заполненной структуры передается в функцию RegisterClassEx, которая говорит Windows, что от нее ожидается, когда окна подобного класса появляются на экране. Теперь система знает, какой вид курсора использовать при попадании указателя мыши в пределы окна, кому посылать сообщения о событиях, происходящих в области окна, какие значки (большой 32 х 32 и маленький 16 х 16) будут связаны с приложением и т. д. Функция RegisterClassEx возвращает число типа АТОМ (16-ти битное целое без знака), которое соответствует строке регистрации в таблице атомов, поддерживаемой системой.

После регистрации класса главного окна идет вызов функции Initlnstance, которая пытается создать окно (CreateWindow) зарегистрированного класса. Если система нашла класс окна в трех поддерживаемых ею списках зарегистрированных классов окон, то функция CreateWindow возвращает описатель окна (HWND). Мы запоминаем его для того, чтобы использовать в качестве параметра при вызове других функций. Если нет, то функция вернет нулевое значение и приложение молча завершает свою работу. Попробуйте при вызове CreateWindow вставить пустую строку, вместо szWindowClass. Запустив приложение, вы поймете, что в ветвь if (ihwnd) неплохо бы вставить вызов:

MessageBox(0,"Не нашла класс окна","Ошибка",МВ_ОК);

При успешном создании окна происходит вызов функций

//====== Показать окно

ShowWindow(hWnd, nCmdShow);

//====== Сделать это, минуя очередь

UpdateWindow(hWnd);

Далее в коде winMain загружается таблица акселераторов (соответствий клавиатурных комбинаций командам меню), которая используется в цикле ожидания и обработки сообщений. Функция GetMessage выбирает сообщение из очереди сообщений потока и помещает его в структуру типа MSG, служащей для хранения информации о сообщении Windows. Функция TranslateAccelerator пытается транслировать (преобразовать) сообщения WM_KEYDOWN (нажата клавиша) или WM_SYSKEYDOWN (нажата F10 или ALT+другая клавиша) в сообщения WM_COMMAND или WM_SYSCOMMAND, но только в том случае, если в таблице акселераторов присутствует код клавиши.

Преобразованное сообщение направляется непосредственно в оконную процедуру. Характерно то, что TranslateAccelerator ждет завершения обработки сообщения. Функция TranslateMessage транслирует сообщения, поступившие в виде виртуальных кодов клавиш, в символьные сообщения и снова отправляет их в очередь сообщений потока для того, чтобы отреагировать на него на следующей итерации цикла. Например, сообщение WM_KEYDOWN (virtual key message) она может преобразовать в WM_CHAR (character message) или в WM_DEADCHAR (см. MSDN). Функция DispatchMessage отправляет сообщение оконной процедуре.

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

Стартовая заготовка иллюстрирует стандартную последовательность действий при создании Windows-приложения на базе API-функций. Обратите внимание на то, что функция WndProc нигде явно не вызывается, хотя именно она выполняет всю полезную работу. Для проверки усвоения прочитанного ответьте на вопрос: «Когда и кем она вызывается?»