kami

Пользователи
  • Публикаций

    592
  • Зарегистрирован

  • Посещение

  • Победитель дней

    39

kami стал победителем дня 15 июня

kami имел наиболее популярный контент!

4 Подписчика

Информация о kami

  • Звание
    Продвинутый пользователь
  • День рождения 16.06.1981

Контакты

  • StackOverflow
    http://ru.stackoverflow.com/users/192901/kami

Информация

  • Пол
    Не определился
  • Город
    Санкт-Петербург

Посетители профиля

942 просмотра профиля
  1. kami

    Хук на клавиатуру

    По большому счету там происходит всего одно: система смотрит, кто еще поставил хук такого же типа и вызывает его функцию. И далее и далее, пока не пройдет всех использовавших SetWindowsHookEx. Повторю - хуков в системе даже "в штатном режиме" установлено великое множество.
  2. kami

    Хук на клавиатуру

    Что может быть непонятно во фразе non-zero value из первоисточника? Скорее всего, возвращаемый результат интерпретируется как BOOL. У любого булеан-типа есть два значения: 0 = False, не 0 = True. Что там присваивают конкретные компиляторы для значения True - это их проблемы. Сравнение всегда ведется с нулем. Может да, а может и нет. Откуда вы знаете, какую логику заложили другие разработчики в свои хуки? Это исключительно их дело - считают ли они нужным
  3. kami

    Хук на клавиатуру

    Мало. If the hook procedure processed the message, it may return a nonzero value to prevent the system from passing the message to the rest of the hook chain or the target window procedure. Не вижу ничего запутанного. В штатной ситуации - вызываете следующий хук. А когда нужно, чтобы клавиша не добралась до адресата - не вызываете. Или же - вызываете, но Result возвращаете <>0. Я не знаю, какой из двух вариантов лучше - я давно уже не работал с WinAPI в этом ракурсе. Эксперименты вам всё покажут, там делов на 20 минут. Разные механизмы работы. Оба - system-wide.
  4. kami

    Хук на клавиатуру

    Нет, не убрать. В целях нормального функционирования в подавляющем большинстве случаев вы должны вызвать следующий хук. И только в исключительных ситуациях (в данном случае - когда клавишу нельзя "пропустить" дальше) - не вызывать. А вы считаете, что единственный на всю систему установили хук на клавиатуру ? :))) Их десятки, если не сотни. Тот же WH_KEYBOARD: система будет вызывать последовательно все KeyboardProc в порядке (емнип), обратном времени установки хука. Естественно, если вы скажете системе "можно отдать на обработку следующему хуку". Внимательно читаем раздел Result в https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms644984(v=vs.85).aspx Там, оказывается, уже всё предусмотрено и потенциально не надо даже пропускать вызов последующего хука. Хотя - лучше пропустить.
  5. kami

    Хук на клавиатуру

    Но результат функции хука нужно присвоить обязательно, вне зависимости от вызова следующего!
  6. kami

    Хук на клавиатуру

    не вызывать следующий хук
  7. наверное, действительно никто. Но вот методом интуитивного тыка это находится на раз. Должно быть так: А у вас, видимо, стоит emacs
  8. kami

    Хук на клавиатуру

    Более того - там уже есть виртуальный код клавиши. Еще проще.
  9. kami

    Хук на клавиатуру

    https://msdn.microsoft.com/ru-ru/library/windows/desktop/ms644984(v=vs.85).aspx
  10. kami

    Хук на клавиатуру

    Так а в чем загвоздка-то? внутри этого хука доступен сканкод нажатой клавиши. Есть GetAsyncKeyState и много чего еще
  11. kami

    Хук на клавиатуру

    по тексту этой ошибки гуглится очень многое. Основной посыл: для WH_KEYBOARD, если указывать HInstance, то он должен быть инстансом dll. Потому что exe не инжектнется в чужой процесс. Можно указать вместо HInstance - 0, а последний параметр выставить в TThread.Current.ThreadID, но (повторюсь) я не уверен, что веббраузер работает только в контексте основного потока приложения.
  12. kami

    Хук на клавиатуру

    Было бы неплохо почитать, чем отличается WH_KEYBOARD от WH_KEYBOARD_LL. Принципы действия абсолютно разные. Вполне возможно, что окна браузера находятся в другом потоке. Посему для начала экспериментов вам нужен именно WH_KEYBOARD_LL Ну так нужно же понимать причину - почему он равен нулю. Обращаемся к первоисточнику. Смотрите, что вернется и узнавайте причину. Можно так: if CurrentHook = 0 then RaiseLastOSError. Нет. Здесь имеется ввиду не разрядность операционной системы, а именно разрядность процессов, запущенных в ней (в 64-битный процесс может быть загружена только 64-битная dll. В 32бита - 32). Кроме того, _LL хуки не зависят от разрядности процесса, поскольку работают в контексте установившего хук потока, им dll не требуется.
  13. kami

    Хук на клавиатуру

    Да куда угодно. Любой модуль, но скорее всего - модуль той формы, на которой лежит веббраузер (его же нужно "обойти"). Там же (например - в конструкторе / деструкторе формы) - регистрация и удаление хука. Ну вот например: https://ru.stackoverflow.com/a/538552/192901 (просмотрел бегло, но криминала нет, по крайней мере - система не помрет, что, кстати, весьма возможно при использовании глобальных хуков). вместо SendMessage подставить myForm.OnKeyDown(...); возможно - придется несколько поменять внутреннюю логику самого хука. Но основа останется без изменений: внутрь хука получается структура, описывающая "что произошло с клавиатурой". Вы ее обрабатываете, вызываете нужные методы и отдаете управление опять системе.
  14. kami

    Утечка памяти в TNotificationCenter | TNotification

    На windows спокойно задействуется механизм отлова утечек. Можно использовать куцый штатный (в dpr первой командой указать ReportMemoryLeaksOnShutdown := True или воспользоваться сторонними расширенными. Например - MadExcept имеет возможность показывать утечки памяти и ресурсов.
  15. Здесь ничего не меняли? (ну, Target, само собой должен быть Android)