Программирование на Visual C++. Архив рассылки
вернуться

Jenter Алекс
Шрифт:

Следующие три параметра – nCode, wParam, и lParam – Windows передает дальше по цепочке функций.

Windows хранит в своих внутренних структурах цепочку фильтрующих функций и следит за тем, какая функция вызывается в настоящий момент. При вызове CallNextHookEx windows определяет следующую функцию в очереди и вызывает ее.

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

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

Фильтры в DLL

Фильтрующие функции с системной областью видимости должны быть реализованы в DLL. В Win16 было возможно (хотя и не рекомендовалось) установить системный хук, находящийся в приложении. Это не сработает в Win32. Ни в коем случае не устанавливайте глобальных фильтров, не находящихся в отдельной DLL, даже если это где-нибудь и работает. Регистрационные хуки, WH_JOURNALRECORD и WH_JOURNALPLAYBACK, являются исключением из правила. Из-за того, как Windows вызывает эти хуки, их фильтрующим функциям не обязательно находиться в DLL.

Фильтрующие функции для хуков с системной областью видимости должны быть готовы разделять свои данные между разными процессами, из которых они запускаются. Каждая DLL отображается в адресное пространство использующего ее клиентского процесса. Глобальные переменные в DLL будут таковыми лишь в пределах одного экземпляра приложения, если только они не будут находиться в разделяемом сегменте данных (shared data section). Например, библиотека HOOKSDLL.DLL в примере Hooks использует две глобальные переменные:

• Хэндл окна для отображения сообщений.

• Высоту строк текста в этом окне.

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

• Использует директивы компилятора (pragma) для помещения данных в именованный сегмент данных. Заметьте, что при этом переменные должны быть обязательно инициализированы.

// Shared DATA

#pragma data_seg(".SHARDATA")

static HWND hwndMain = NULL; // Главный hwnd. Мы получим его от приложения.

static int nLineHeight = 0; // Высота строк в окне.

#pragma data_seg

Добавляет блок SECTIONS в .DEF-файл библиотеки:

SECTIONS

 .SHARDATA Read Write Shared

Создает .EXP-файл из .DEF-файла:

hooksdll.exp: hooksdll.obj hooksdll.def

 $(implib) –machine:$(CPU) \

 –def:hooks.def \

 hooksdll.obj \

 –out:hooksdll.lib

Прилинковывает получившийся файл HOOKSDLL.EXP:

hooksdll.dll: hooksdll.obj hooksdll.def hooksdll.lib hooksdll.exp

 $(link) $(linkdebug) \

 –base:0x1C000000 \

 –dll \

 –entry:LibMain$(DLLENTRY) \

 –out:hooksdll.dll \

 hooksdll.exp hooksdll.obj hooksdll.rbj \

 $(guilibsdll)

Типы хуков
WH_CALLWNDPROC

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

Структура CWPSTRUCT описана следующим образом:

typedef struct tagCWPSTRUCT {

 LPARAM lParam;

 WPARAM wParam;