Что я должен сделать для создания моего WH_SHELL, или WH_CBT сцепить процедуру получают события от других процессов?
Да, вы можете использовать сервис Lambda для обработки потоковых данных Kinesis. Вам нужно создать лямбда-функцию для обработки данных (данные будут доступны через event, во-первых, параметр функции).
В случае потоковой передачи данных ваша лямбда-функция не вызывается как ответ на какое-то событие. Вместо этого служба Lambda периодически проверяет Kinesis на наличие доступных данных, а затем вызывает вашу функцию.
Чтобы это произошло, вам нужно создать источник источника событий между вашей пользовательской лямбда-функцией и потоком Kinesis, где вы также можете указать размер пакета, который будет обрабатываться лямбда-выражением, и его начальную позицию.
Не забудьте создать правильную роль для вашей лямбда-функции, ей нужно иметь доступ к службе Kinesis, поэтому вам нужно что-то вроде AWSLambdaKinesisExecutionRole разрешений.
Еще одна вещь, которую нужно учитывать, это размер пакета и насколько сложен ваш алгоритм обработки. Лямбда может работать только в течение ограниченного времени (в настоящее время вы можете указать не более 15 минут), после чего он автоматически прерывается AWS. В таком случае вам нужно будет использовать что-то еще, кроме лямбды, или разбить вашу лямбда-функцию на несколько более мелких.
5 ответов
Проблема в том, что ваша подключаемая DLL фактически загружается в несколько разных адресных пространств. Каждый раз, когда Windows обнаруживает событие в каком-то внешнем процессе, которое должно быть обработано вашей ловушкой, она загружает DLL-ловушку в этот процесс (если, конечно, он еще не загружен).
Однако каждый процесс имеет свое собственное адресное пространство. Это означает, что указатель функции обратного вызова, который вы передали в InitHook (), имеет смысл только в контексте вашего EXE-файла (поэтому он работает для событий в вашем приложении). В любом другом процессе этот указатель является мусором ; это может указывать на недопустимую область памяти или (что еще хуже) на какой-то случайный фрагмент кода. Результатом может быть либо нарушение прав доступа, либо повреждение памяти без вывода сообщений.
Как правило, решение состоит в том, чтобы использовать своего рода межпроцессное взаимодействие (IPC) для надлежащего уведомления вашего EXE-файла. Самый безболезненный способ для вашего случая - отправить сообщение и втиснуть нужную информацию (событие и HWND) в свой WPARAM / LPARAM. Вы можете использовать WM_APP + n или создать его с помощью RegisterWindowMessage (). Убедитесь, что сообщение отправлено и не отправлено, чтобы избежать тупиков.
Lol, похоже, что ошибка находится в тестовом коде.
Если Вы создаете две отдельных кнопки, один для Init и один для UnInit (я предпочитаю Выход).
procedure THooktest_FO.UnInitClick(Sender: TObject);
begin
UninitHook;
end;
procedure THooktest_FO.InitClick(Sender: TObject);
begin
InitHook(HookCallback)
end;
Запустите приложение. Нажмите Init и затем кнопку проверки, следующий вывод показывают:
created handle #1902442
destroyed handle #1902442
created handle #1967978
created handle #7276488
Затем messagebox показывают.
Если Вы нажимаете ОК, Вы добираетесь:
destroyed handle #1967978
HTH
Это могло бы быть третичным к Вашему вопросу, но как Вы видите, в рычагах очень трудно разобраться - если можно избегать использования этого каким-либо образом, сделайте это. Вы собираетесь столкнуться со всеми видами проблем с ними, особенно на Vista, где необходимо будет иметь дело с UIPI.
Просто для уточнения что-то, что "efotinis" упомянул о регистрации сообщений назад к Вашему процессу - wParam и lParam, который Вы отправляете на свой основной процесс, не может быть указателями, они могут просто быть "числами".
Например, позволяет, говорят, что Вы сцепляете сообщение WM_WINDOWPOSCHANGING, окна передает Вас указатель на WINDOWPOS в lparam. Вы не можете только отправить это lparam назад к Вашему основному процессу, потому что память, на которую указывает lparam, только допустима в процессе, который получает сообщение.
Это - то, что означал "efotinis", когда он сказал, "переполняют необходимую информацию (событие и HWND) в его WPARAM/LPARAM". Если Вы хотите передать более сложные сообщения, поддерживают Ваше испытание необходимость для использования некоторого другого IPC (как именованные каналы, TCP или файлы с отображенной памятью).
Я нашел документацию основы Delphi для SetWindowsHookEx. Но текст немного неопределенен.
function SetWindowsHookEx(idHook: Integer; lpfn: TFNHookProc;
hmod: HInst; dwThreadId: DWORD): HHOOK;
hmod: на дескриптор к модулю (DLL) содержащий функцию рычага указывает lpfn параметр. Этот параметр должен быть обнулен, если dwThreadId определяет поток, созданный текущим процессом, dlpfn указывает на функцию рычага, расположенную в коде, связанном с текущим процессом.
dwThreadId: идентификатор потока, с которым будет связана установленная функция рычага. Если этот параметр будет обнулен, то рычаг будет рычагом в масштабе всей системы, который связан со всеми существующими потоками.
Между прочим, для hmod параметра необходимо было использовать дескриптор модуля. (HINSTANCE указывает на дескриптор приложения).
hand := GetModuleHandle('hookhelper.dll');
Hook := SetWindowsHookEx(WH_SHELL, @HookProc, hand, 0);
Но хотя рука отличается от HINSTANCE, это все еще показывает тот же результат.