Ознакомление с приложениями Windows

Ознакомление с приложениями Windows

Первое знакомство

определение, к какой задаче относятся данные, полученные от устройства ввода.

передача полученных от устройства данных требуемой задаче.

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

Для клавиатуры дело обстоит несколько сложнее: нам придется ввести понятие активное окно (active window). В данный момент времени обязательно существует только одно активное окно, это окно выделяется цветом заголовка, рамки или подписи (если окно минимизировано). Активное окно является пользователем клавиатуры в данный момент времени. Для того, что бы другая задача могла получать данные, необходимо сделать активным окно, принадлежащее этой задаче.

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

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

можно воспользоваться специальной функцией, передающей управление системе, и возвращающей его назад приложению после обработки других приложений. Таких функций в Windows 3.x две -- Yield и DirectYield. Однако этот путь используется в очень специальных случаях, например при разработке отладчиков, из-за довольно жестких ограничений на применение этих функций.

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

Это очень важный момент.

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

Например, при необходимости ввода данных с клавиатуры, программа включала в себя вызов к операционной системе (или BIOS, на худой конец), который и возвращал требуемые данные.

Еще раз: обычная программа генерирует вызовы к операционной среде для получения и вывода данных: алгоритм управляет данными

В рассмотренном нами случае получается совершенно иная ситуация: поступающие от системы данные управляют поведением программы. Часто такими данными являются управляющие воздействия пользователя (например, изменение размеров окна, вызов меню и др.). Эти воздействия, вообще говоря, не синхронны с работой вашей программы, то есть получается, что данные управляют алгоритмом -- один из основных принципов объектно-ориентированного программирования (ООП).

Введем новые понятия:

данные, передаваемые от системы к соответствующей функции называются сообщением (message).

процесс обращения к требуемой функции называется посылкой (post) или передачей (send) сообщения.

функция, обрабатывающая сообщения, называется процедурой обработки сообщений (message handler).

Таким образом, когда вы создаете программу, работающую в псевдомногозадачной среде (здесь: Windows 3.x), вы должны написать требуемые процедуры обработки сообщений. Далее Windows будет передавать вашим процедурам сообщения для их обработки.

С точки зрения ООП все объекты должны обладать 3мя свойствами:

инкапсуляция -- объединение в единое целое алгоритмов и необходимых данных;

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

полиморфизм -- разность реакций на одинаковые воздействия; наследники одного объекта могут отличаться своими свойствами друг от друга и от предка.

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

Обычно говорят, что процедура обработки сообщений определяет свойства объекта, так как задает реакцию этого объекта на воздействия (сообщения). Именно с такой трактовкой объекта возникли первые языки ООП.

В Windows объектом ООП является окно. Соответственно говорят, что сообщения направлены не процедуре, а окну. Процедура обработки сообщений определяет окно с конкретными свойствами, даже больше -- одна процедура может обслуживать несколько разных окон, но тогда эти окна будут иметь одинаковую реакцию на одинаковые воздействия. То есть процедура обработки сообщений определяет не одно окно, а целый класс (class) окон.

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

Таким образом псевдомногозадачный метод разделения процессора оказался основой для построения объектно-ориентированной среды и попутно перевернул всю привычную нам философию написания программ -- мы теперь создаем не управляющий алгоритм, а набор процедур, обеспечивающий реакцию нашего окна (то есть нашей программы) на внешние события.

Обработка сообщений является очень распространенным способом организации ООП-библиотек или ООП-языков. Существенное отличие (причем не в лучшую сторону) Windows 3.x заключается в том, что обработка сообщений является методом разделения процессора в псевдомногозадачной среде. Так как система не прерывает выполнение приложения в процессе обработки сообщения, то его обработка не должна занимать много времени

Это сильно затрудняет применение Windows 3.x для расчетных задач -- либо мы должны их выполнить быстро, либо разбить на быстро выполняемые части, и понемногу обрабатывать по мере получения сообщений. Понятно, что обычно приходится разбивать на части, а это существенно замедляет вычисления. Вообще говоря, при обработке сообщения лучше укладываться в интервал менее 1 секунды, что бы задержка в реакции Windows на управляющие воздействия не была очень большой; критичной является задержка порядка 1-2 минуты -- при этом Windows 3.x может просто дать сбой или зависнуть (что очень сильно зависит от наличия других работающих приложений).

написать оконную функцию;

зарегистрировать эту функцию (класс) в Windows, присвоив классу уникальное имя;

создать окно, принадлежащее данному классу;

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

Чуть подробнее рассмотрим, что происходит с приложением за время его “жизни” -- от запуска до завершения -- перед тем, как перейдем к рассмотрению конкретного примера.

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

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

#define WM_MOVE 0x0003
#define WM_SIZE 0x0005

В большинстве случаев названия сообщений начинаются на WM_, однако названия некоторых сообщений имеют префиксы BM_, EM_, LBM_, CBM_ и другие.

Для начала выделим четыре сообщения, с которыми мы будем знакомится первыми. Это сообщения применяются при создании окна (WM_CREATE), при закрытии Точнее при уничтожении. Термин “закрытие” в Windows часто имеет другой смысл, в том числе -- сворачивание окна в пиктограмму. (WM_DESTROY и WM_QUIT) и при его перерисовывании (WM_PAINT).

В тот момент, когда приложение создает новое окно, оконная процедура получает специальное сообщение WM_CREATE, информирующее окно о его создании. При этом окно создается с помощью вызова специальной функции (CreateWindow, CreateWindowEx и некоторые другие), которая выполняет все необходимые действия; сообщение при этом имеет лишь “информационный” характер -- оно информирует окно о том, что его создают. Однако реальное создание происходит не в обработчике этого сообщения, а в той функции, которую вызвали для создания окна.

На сообщении перерисовки окна WM_PAINT надо остановиться чуть подробнее. Дело в том, что какая-либо часть окна может быть скрыта от пользователя (например, перекрыта другим окном). Далее в процессе работы эта часть может стать видимой, например вследствие перемещения других окон. Сама система при этом не знает, что должно быть нарисовано в этой, ранее невидимой части окна. В этой ситуации приложение вынуждено позаботиться о перерисовке нужной части окна самостоятельно, для чего ему и посылается это сообщение каждый раз, как видимая область окна изменяется.

Когда окно закрывается, оно получает сообщение WM_DESTROY, информирующее о закрытии окна. Как и в случае создания, сообщение о закрытии является информационным; реальное закрытие осуществляется специальной функцией (обычно DestroyWindow), которая, среди прочего, и известит окно о его уничтожении.

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

После завершения цикла обработки сообщений приложение уничтожает оставшиеся ненужные объекты и возвращает управление операционной системе.

Сейчас в качестве примера мы рассмотрим простейшее приложение для Windows, традиционную программу “Hello, world!”. После этого подробнее рассмотрим, как это приложение устроено. Здесь же можно заметить, что при создании практически любых, написанных на “C”, приложений для Windows этот текст может использоваться в качестве шаблона.

#define STRICT
#include <windows.h>

#define UNUSED_ARG(arg) (arg)=(arg)
static char szWndClass[] = "test window";

LRESULT WINAPI _export WinProc( HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam )
{
UNUSED_ARG( wParam );
UNUSED_ARG( lParam );
PAINTSTRUCT ps;

switch ( uMsg ) {
case WM_CREATE:
return 0L;

case WM_PAINT:
BeginPaint( hWnd, &ps );
TextOut( ps.hdc, 0, 0, "Hello, world!", 13 );
EndPaint( hWnd, &ps );
return 0L;

case WM_DESTROY:
PostQuitMessage( 0 );
return 0L;

default:
break;
}
return DefWindowProc( hWnd, uMsg, wParam, lParam );
}

static BOOL init_instance( HINSTANCE hInstance )
{
WNDCLASS wc;

wc.style = 0L;
wc.lpfnWndProc = WinProc;
wc.cbClsExtra = 0;
wc.cbWndExtra = 0;
wc.hInstance = hInstance;
wc.hIcon = LoadIcon( NULL, IDI_APPLICATION );
wc.hCursor = LoadCursor( NULL, IDC_ARROW );
wc.hbrBackground = (HBRUSH)(COLOR_WINDOW + 1);
wc.lpszMenuName = NULL;
wc.lpszClassName = szWndClass;
return RegisterClass( &wc ) == NULL ? FALSE : TRUE;
}

int PASCAL WinMain( HINSTANCE hInst, HINSTANCE hPrevInst, LPSTR lpszCmdLine, int nCmdShow )
{
UNUSED_ARG( lpszCmdLine );
MSG msg;
HWND hWnd;

if ( !hPrevInst ) {
if ( !init_instance( hInst ) ) return 1;
}

hWnd= CreateWindow(
szWndClass, "window header", WS_OVERLAPPEDWINDOW,
CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT,
NULL, NULL, hInst, NULL
);

if ( !hWnd ) return 1;

ShowWindow( hWnd, nCmdShow );
UpdateWindow( hWnd );

while ( GetMessage( &msg, NULL, NULL, NULL ) ) {
TranslateMessage( &msg );
DispatchMessage( &msg );
}

return msg.wParam;
}

Рисунок 1. Приложение 1a.cpp в среде Windows 3.x или Windows NT 3.x (слева) или в среде Windows-95 или Windows NT 4.0 (справа).

В зависимости от платформы, на которой запускается это приложение, внешний вид окна может несколько изменяться. Это связано с изменившимся интерфейсом пользователя при переходе от Windows 3.x и Windows NT 3.x к Windows-95 и Windows NT 4.0.

Далее мы рассмотрим исходный текст более подробно. При первом взгляде на него обращают на себя внимание сразу несколько необычных (по сравнению с программами для DOS) вещей:

новые типы данных

странные имена переменных

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

Примерно в таком порядке мы и рассмотрим эти вопросы.

Страницы: 1, 2, 3, 4