Оконная функция предназначена для организации адекватной реакции со стороны Windows-приложения на действия пользователя и поддержания в актуальном состоянии того окна приложения, сообщения которого она обрабатывает. Приложение может иметь несколько оконных функций, их количество определяется количеством классов окон, зарегистрированных в системе функцией RegisterClass(). Функции RegisterClass() посредством экземпляра структуры типа WNDCLASS передается указатель на определенную оконную функция Windows-приложения. Данная функция до конца работы приложения связана с экземплярами окон, которые, в свою очередь, создаются другой функцией API – CreateWindow().
Как было показано в предыдущем разделе, оконная функция вызывается, как только в структуру msg попадает очередное сообщение. Задача оконной функции – определить природу сообщения и обработать его следующим образом. Ранее мы для упрощения говорили, что единственный источник появления сообщений – очередь сообщений приложения, но это не совсем так. Сообщения, в зависимости от источника их появления в оконной функции, могут быть двух типов: синхронные и асинхронные. К синхронным относятся те сообщения, которые помещаются в очередь сообщений приложения и терпеливо ждут момента, когда они будут выбраны функцией GetMessage(). После этого поступившие сообщения поступают в оконную функцию, где и производится их обработка. Асинхронные сообщения попадают в оконную функцию в экстренном порядке, минуя при этом все очереди. Они, в частности, инициируются некоторыми функциями Win32 API, такими как CreateWindow() и UpdateWindow(). Координацию синхронных и асинхронных сообщений осуществляет Windows. Если рассматривать синхронное сообщение, то его извлечение производится функцией GetMessage() с последующей передачей его обратно в Windows функцией DispatchMessage(). Асинхронное сообщение, независимо от источника, который инициирует его появление, сначала попадает в Windows и затем в нужную оконную функцию.
Для чего реализуется именно такая схема, неужели функция DispatchMessage() не может сразу передать сообщение в оконную функцию? Если бы это было так, то в системе появилось бы одно приложение-монополист, которое захватило бы все процессорное время своим циклом обработки сообщений. В схеме, реализованной в Windows, обработка сообщений приложением проводится в два этапа: на первом этапе приложение выбирает сообщение из очереди и отправляет его обратно во внутренние структуры Windows; на втором этапе Windows вызывает нужную оконную функцию приложения, передавая ей параметры сообщения. Преимущество этой схемы в том, что Windows самостоятельно решает все вопросы организации эффективной работы приложений.
Таким образом, при поступлении сообщения Windows вызывает оконную функцию и передает ей ряд параметров, которые берутся из соответствующих полей сообщения. Из заголовка оконной функции
LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wParam, LPARAM lparam)
видно, что она получает при активации ее (функцией DispatchMessage()) 4 параметра. Первый параметр (hwnd) – дескриптор окна, которому предназначено данное сообщение. Это – тот самый дескриптор, который был получен нами как результат работы функции CreateWindow(), и в нашем варианте программы тут же потерян, так как был объявлен как локальная для функции Create() переменная. Теперь этот же дескриптор вернулся к нам из Windows как параметр оконной функции. Он особенно полезен в тех случаях, когда на базе одного класса создается несколько различающихся чем-то окон. Если класс один, то и оконная функция для всех этих окон одна; анализируя тогда параметр hwnd, программа может определить, в какое именно окно пришло сообщение. У нас окно одно, однако, аргумент hwnd все же понадобится. Второй параметр (msg) определяет код пришедшего сообщения. Поскольку сообщений много, оконная функция должна, прежде всего, проанализировать этот код и осуществить переход на фрагмент обработки соответствующего сообщения. wParam и lParam – дополнительные параметры, являющиеся копиями соответствующих полей структуры поступившего сообщения. Оставшиеся два поля структуры msg - time и POINT используются достаточно редко, и при необходимости их значения можно извлечь непосредственно из экземпляра структуры сообщения.
Центральным местом оконной функции является синтаксическая конструкция, в задачу которой входит распознавание поступившего сообщения по его типу и передача управления на ту ветвь кода оконной функции, которая продолжает далее работу с параметрами сообщения. Для этого используется оператор switch…case (переключатель).
Оконная функция должна обрабатывать все поступающие в нее сообщения, и ее текст должен быть приблизительно таким:
switch(msg)
{
case WM_CREATE:
. . . //Обработка сообщения WM_CREATE
case WM_DESTROY:
. . . //Обработка сообщения WM_DESTROY
case WM_KEYDOWN:
. . . // Обработка сообщения WM_KEYDOWN
case WM_MOUSEMOVE:
. . . // Обработка сообщения WM_MOUSEMOVE
case WM_TIMER:
. . . // Обработка сообщения WM_TIMER
// и т. д. для всех возможных сообщений
}
Оконная функция, обрабатывающая сообщения, имеет одну точку входа и множество точек выхода. Выход из оконной функции осуществляется из той ее ветви, где обрабатывалось сообщение. Однако реально в любой программе обрабатываются далеко не все сообщения. Например, если программа управляется только мышью, в ней нет необходимости обрабатывать сообщения от клавиатуры; совсем не обязательно программа имеет дело с таймером и т. п. Надо еще иметь в виду, что приложение получает огромное количество сообщений системного характера, например, о перерисовке отдельных элементов окна, определения его размеров, изменении положения окна и т. п. Все эти сообщения мы, возможно, даже не умеет обрабатывать должным образом. Для того, чтобы дать возможность программисту работать только с теми сообщениями, которые ему нужны, в Windows предусмотрена специальная функция DefWindowProc(), которая умеет правильно обрабатывать практически все сообщения Windows. Единственным сообщением, не входящим в “юрисдикцию” DefWindowProc(), является сообщение об уничтожении окна WM_DESTROY. Поэтому в простейшем случае, когда мы вообще не предполагаем работать с сообщениями, оконная функция должна включать в себя обработку только одного сообщения WM_DESTROY:
switch(msg)
{
case WM_DESTROY:
PostQuitMessage(0);
return 0;
default:
return(DefWindowProc(hwnd, msg, wParam, lParam));
}
Такая оконная функция обеспечит обработку по умолчанию всех поступающих в главное окно сообщений. Остается выяснить вопрос, как возникает сообщение WM_DESTROY и в чем заключается его обработка.
