2009-04-03 3 views
-1

Вот ситуация. У меня есть два разных крючка окна, один из которых - глобальный крюк сорта WH_SHELL, который следит за новыми окнами верхнего уровня, второй - крючок потока WH_CALLWNDPROC, который установлен на некоторых из окон верхнего уровня, открытых первым крюк. Два крючка реализованы в разных DLL.PostMessage и CALLWNDHOOK, отсутствующие зарегистрированные сообщения?

Насколько я могу судить, оба крючка устанавливаются должным образом. Тем не менее, ничего я не отправляю в окна с крючками с код сообщения> WM_USER сообщение о регистрации когда-либо обрабатывается пользовательским крюком WH_CALLWNDPROC, но «нормальные» сообщения Windows передаются, думая, что это просто отлично.

код, который перехватывает на обнаруженное окно:

... Getting handle, mod, and procHook ... 
DWORD threadId = GetWindowThreadProcessId(handle, NULL); 

HHOOK hook = SetWindowsHookEx(WH_CALLWNDPROC, (HOOKPROC)procHook, mod, threadId); 

if(!PostMessage(handle, CUSTOM_MESSAGE, NULL, NULL)) 
{ 
    ... fetch and print error message ... 
} 

Тело самого крючка:

... Report sends a message to an agreed upon window with the passed wParam & lParam 
Report(20, nCode); 

if(nCode == CUSTOM_MESSAGE) 
{ 
    ... This code is never reached ... 
    Report(50, ERROR_SUCCESS); 

    if(PerformTask()) 
    Report(200, ERROR_SUCCESS); 
    else 
    Report(400, ERROR_SUCCESS); 
} 

... More code handling more messages in the same basic form 

Первый отчет вызов является то, что подтверждает, что крюк установлен и работает, так как она сообщения назад куча сообщений в младшие подростки и двадцатые годы (ERASEBACKGROUND, PAINT и т. д.).

CUSTOM_MESSAGE определяется как WM_USER + 314. Сообщение, используемое для отчета (...) является WM_USER + 317.

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

Так, в основном, что не так с моим дизайном или с моим использованием оконных крючков и PostMessage? Если я опустил какие-либо подробности, дайте мне знать; есть много кода, и это уже довольно большой вопрос, поэтому я попытался включить только то, что, по моему мнению, имеет значение.

Как в стороне, есть ли лучший способ отлаживать крючки? Я использую моральный эквивалент cout < < ... все, отправляя сообщения в согласованное окно и отлаживая его WndProc.

Спасибо,
Montrose Кевин

ответ

0

Я думаю, что понял. Простой случай не совсем поглощает документацию.

Мой крюк CallWndProc вел себя так, как если бы nCode, wParam и lParam были переданы подключенным потокам WndProc.Фактически, lParam содержал указатель на CWPSTRUCT; прочитайте данные из этой структуры, и все работает нормально.

+0

Ах, вот и все. :) Рад, что ты понял это в конце. – Andy

2

Хотя @Michael является правильным относительно использования WM_USER сообщений (они должны использоваться в приложении только - registered messages, тем лучше путь здесь), в то же время Я думаю, что причина, по которой вы их не получаете, связана с характером сообщения CallWndProc и сообщений. Я не уверен, но думаю, что вы хотите зацепить крючок GetMessage за сообщения.

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

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

+0

Hooking GetMessage вместо этого не изменяет поведение. Вы абсолютно правы в RegisterWindowMessage (...), хотя я исправил это и соответствующим образом обновляю свой вопрос. –

+0

Вы пытались подключить крючок отладки, чтобы выяснить, какой крючок перехватывает сообщение, если оно есть? – Andy

+0

Насколько я могу судить об этом, сообщение никогда не увидишь. Это независимо от того, отправлено или отправлено сообщение. –

Смежные вопросы