AHK: Как перехватить все перемещения мыши и все нажатия клавиш? (Страница 1 из 3)

OnMessage, если этого мало, то нужно использовать хуки, а для этого нужна dll.

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

teadrinker, ок, ждём. Только без циклической проверки координат.

teadrinker, работает.

А на семёрке работает?

Однако, написал вариант с использованием dll. Но меня устраивает, то что надо.

Согласен. А этот скрипт: AHK: Отслеживание времени бездействия мыши. удалите, или перенесите в раздел "Как не надо делать"

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

Если они туда попадают по такому критерию, тогда ладно. Но мне кажется этот вариант лучше чем тот.

D_Pavel, (выделение моё):

Исключать же скрипт из Коллекции имеет смысл, если он содержит явные ошибки.

Попробуй так:

   #Persistent
   OnExit, Exit
   hHookKeybd := DllCall("SetWindowsHookEx"
      , Int, WH_KEYBOARD_LL := 13
      , UInt, RegisterCallback("LowLevelKeyboardProc", "Fast")
      , UInt, DllCall("GetModuleHandle", UInt, 0)
      , UInt, 0)
   Return
 
Exit:
   DllCall("UnhookWindowsHookEx", UInt, hHookKeybd)
   ExitApp
 
LowLevelKeyboardProc(nCode, wParam, lParam)
{
   Critical
   SetFormat, Integer, H
   ToolTip, % wParam . "| vkCode: " . NumGet(lParam+0, 0, "UInt") . " scCode: " . NumGet(lParam+0, 4, "UInt")
      . " Extended: " . NumGet(lParam+0, 8, "UInt") & 1 . " Time: " . NumGet(lParam+0, 12, "UInt")
   Return DllCall("CallNextHookEx", UInt, 0, Int, nCode, UInt, wParam, UInt, lParam)
}

   OnExit, Exit
   hHookKeybd := DllCall("SetWindowsHookEx"
      , Int, WH_MOUSE_LL := 14
      , Int, RegisterCallback("LowLevelMouseProc", "Fast")
      , UInt, DllCall("GetModuleHandle", UInt, 0)
      , UInt, 0)
   Return
 
Exit:
   DllCall("UnhookWindowsHookEx", UInt, hHookKeybd)
   ExitApp
 
LowLevelMouseProc(nCode, wParam, lParam)
{
   ToolTip, % "Message = " . wParam
      . "`nMouse_X = " . NumGet(lParam+0, 0, "UInt")
      . "`nMouse_Y = " . NumGet(lParam+0, 4, "UInt")
      . "`nExtended = " . (NumGet(lParam+0, 8, "UInt")&0xFFFF0000)>>16
      . "`nTime = " . NumGet(lParam+0, 16, "UInt")
   Return DllCall("CallNextHookEx", UInt, 0, Int, nCode, UInt, wParam, UInt, lParam)
}
 
Esc::ExitApp

Для GetModuleHandle тоже надо Fast указать.

Не совсем понял, как это?
Может, нужно учесть наличие Unicode и ANSI версий GetModuleHandle()? creature.ws, попробуй в последнем моём варианте заменить GetModuleHandle на GetModuleHandleW.

Да откуда ты этот Fast в DllCall() взял?

Чудеса: я сейчас вместо "Fast" поставил чисто от балды "Abc" — тоже помогает!

Понял, что тут работает: при всех этих левых добавках GetModuleHandle возвращает пустое значение. Можно вместо него просто передать 0.

Кстати, вроде там и нужен ноль по идее.

Может, логика такая, что all existing threads running in the same desktop as the calling thread включают и саму calling thread, т.е. ты как бы её указал. К тому же the hook procedure ведь не в DLL.

teadrinker

Cdecl отличается от stdcall только тем, что вызванная функция при выходе не меняет указатель стека так, чтобы переданные ей параметры оказались в свободной части стека. За неё это должен сделать вызывающий код. В Windows API cdecl практически нет. Только функцию wsprintf знаю. Ну и функции в msvcrt.dll, но это ведь не часть API, а "C runtime".

При DllCall("GetModuleHandleW", UInt, 0) не работает.
При передаче нуля - tooltip показывается, 1-2 клика обрабатываются - курсор останавливается.
После закрытия скрипта курсор рывком перемещается в точку куда был бы переведен, не будь он обездвижен

Видимо так
Проверил после перезагрузки при отключенном основном скрипте, более в системе посторонних хуков мыши никто ставить вроде бы не должен.

Service Pack 1 Build 7601, x64-based,  68 Hotfix(s) Installed; Ahk_L U x64 1.1.05.05

Вот, а также была соответствующая тема в разработке, ищи, там подробнее.

Жаль, на AHK_L x64 мышиный хук приводит к обездвиживанию курсора при первом-втором клике.

Спасибо за рекомендацию, попробовав вариант с заменой UInt на Ptr во всех подходящих местах и не получив желаемого результата, решил таки проверить скрипт на свежеустановленной на вм аналогичной системе. Работает в оригинальном виде при hMod = 0
Вероятно, подтвердилось сказанное выше:

Мои извинения за ложные багрепорты

afinagen да, именно так и об этом пишут на MSDN:

LowLevelMouseProc

LowLevelKeyboardProc

мой пример перехвата нажатий клавиш на Purebasic

В моём примере CallNextHookEx возвращается в любом случае. Что же до ситуации, когда nCode < 0, то вот такой скрипт

   OnExit, Exit
   hHookKeybd := DllCall("SetWindowsHookEx"
      , Int, WH_MOUSE_LL := 14
      , Int, RegisterCallback("LowLevelMouseProc", "Fast")
      , UInt, DllCall("GetModuleHandle", UInt, 0)
      , UInt, 0)
   Return
 
Exit:
   DllCall("UnhookWindowsHookEx", Uint, hHookKeybd)
   ExitApp
 
LowLevelMouseProc(nCode, wParam, lParam)
{
   ToolTip % nCode
   if nCode < 0
      SoundBeep
   Return DllCall("CallNextHookEx", UInt, 0, Int, nCode, UInt, wParam, UInt, lParam)
}
 
Esc::ExitApp

показывает, что подобного в данном варианте установки хука просто не происходит.

Ты имеешь в виду нажатия клавиш, или что?

А зачем нужны эти хуки? Можно этот процесс убрать как-то? - комп тормозит, и там  конфликты с другими приложениями, что-ли, могут возникнуть?

Удалено

Удалено

Time paradox:

(внимание на даты постов).

Я видел. Судя по тому, что некоторое время хостинг отпинывал запросы на обслуживание — проблемы были на его стороне.

ОК спасибо! Создаю новую тему. Модератора или администратора просьба удалить мои посты из этой темы.

Да, исправлю.

Надо ещё мышиный подправить, наверное.

Ну просто сделать тогда уж в том же стиле, что и предыдущий, с таймером и выводом сообщений.

Нет, но в любом случае обработку событий лучше по таймеру делать, чтобы не возникало проблем.

Да, но если события будут происходить до завершения обработки предыдущих в хуке, будут задержки, а иногда и сбои, залипания клавиш, и ещё всякие неприятности.

Да как-то не задумывался. А для чего это конкретно нужно?

Не знаю, поэкспериментировать нужно. Помню, что когда подобное без хука пытался сделать, какие-то траблы вечно вылезали.

Ещё актуально? В чём там проблема?

OnExit, Exit
hHookKeybd := DllCall("SetWindowsHookEx"
   , Int, WH_KEYBOARD_LL := 13
   , Ptr, RegisterCallback("LowLevelKeyboardProc", "Fast")
   , Ptr, DllCall("GetModuleHandle", UInt, 0, Ptr)
   , UInt, 0, Ptr)
Return

Exit:
   DllCall("UnhookWindowsHookEx", Ptr, hHookKeybd)
   ExitApp

LowLevelKeyboardProc(nCode, wParam, lParam)
{
   static oMem := [], q := 0, w := 0
      , oMsg := {0x100: "WM_KEYDOWN", 0x101: "WM_KEYUP", 0x104: "WM_SYSKEYDOWN", 0x105: "WM_SYSKEYUP"}
   
   arr := {}
   arr.msg := Format("{:#x}", wParam)
   arr.vk  := Format("{:#x}", NumGet(lParam + 0, "UInt"))
   ext := NumGet(lParam + 8, "UInt") & 1
   arr.sc := Format("{:#x}", NumGet(lParam + 4, "UInt") | ext << 8)
   arr.ext := ext
   arr.time := NumGet(lParam + 12, "UInt")
   
   oMem.Push(arr), q++
   
   SetTimer, EventHandling, -10
   Return DllCall("CallNextHookEx", Ptr, 0, Int, nCode, Ptr, wParam, Ptr, lParam)
   
EventHandling:
   while oMem[1] != ""  {
      msg := oMem[1].msg
      vk := oMem[1].vk
      sc := oMem[1].sc
      ext := oMem[1].ext
      time := oMem[1].time
      oMem.RemoveAt(1)
      
      ToolTip % "Message = "  . oMsg[msg]
            . "`nvkCode = " . vk
            . "`nscCode = " . sc
            . "`nTime = "   . time 
            . "`nPhysical = "   . (ext & 16 ? "Not" : "Yes")
            . "`n " q "   " ++w "   " oMem.MaxIndex() 
      Sleep 100
   }
   Return
}

Esc::ExitApp

lParam в функции — локальная переменная, она существует только до Return функции, и извлекать что-либо из неё по таймеру не имеет смысла.

Это не «просто число», это указатель на определённые данные в памяти, которые мы извлекаем. Данные по этому указателю валидны только на время выполнения функции, непосредственно в которую был послан указатель. Как только она выполнилась (дошла до Return), данные по этому адресу могут замещаться новой информацией (само значение указателя никуда не исчезает, можешь проверить). А вот wParam в данном случае — это как раз просто число.

Почему нельзя? В моём коде как раз так и делается.

Можно прочитать участок памяти в статическую переменную, попозже напишу.

Спасибо! Вроде всё понятно.
Единственно что:

    VarSetCapacity(lParamData, Size := 16, 0)
    DllCall("RtlMoveMemory", Ptr, &lParamData, Ptr, lParam, Ptr, Size)

Если мы записали 16 байт в lParamData, занесли в массив адрес памяти, (при повторном вызове) не успев извлечь данные по этому адресу, очищаем её (VarSetCapacity) и снова пишем в неё данные. Что же тогда остаётся?

Если VarSetCapacity очищая lParamData, присваивает ей уже другой адрес, то как очищается память?

Ммм... Не понял, работает же.

Так, вроде, можно:

OnExit, Exit
hHookKeybd := DllCall("SetWindowsHookEx"
   , Int, WH_KEYBOARD_LL := 13
   , Ptr, RegisterCallback("LowLevelKeyboardProc", "Fast")
   , Ptr, DllCall("GetModuleHandle", UInt, 0, Ptr)
   , UInt, 0, Ptr)
Return

Exit:
   DllCall("UnhookWindowsHookEx", Ptr, hHookKeybd)
   ExitApp
   
Esc::ExitApp

LowLevelKeyboardProc(nCode, wParam, lParam)
{
    static oMem := [], q := 0, w := 0, HEAP_ZERO_MEMORY := 0x8, hHeap := DllCall("GetProcessHeap", Ptr)
        , oMsg := {0x100: "WM_KEYDOWN", 0x101: "WM_KEYUP", 0x104: "WM_SYSKEYDOWN", 0x105: "WM_SYSKEYUP"}
     
    pHeap := DllCall("HeapAlloc", Ptr, hHeap, UInt, HEAP_ZERO_MEMORY, Ptr, Size := 16, Ptr)
    DllCall("RtlMoveMemory", Ptr, pHeap, Ptr, lParam, Ptr, Size)
    
    oMem.Push([wParam, pHeap]), ++q 
    SetTimer, EventHandling, -10   ; обработку событий "повесим" на таймер, чтобы не создавать помех в работе клавиатуры
    Return DllCall("CallNextHookEx", Ptr, 0, Int, nCode, Ptr, wParam, Ptr, lParam)
 
EventHandling:
    While (oMem[1] != "") 
    {  
        wp := oMem[1][1], lp := oMem[1][2]
        
        msg  := wp
        vk   := Format("{:#x}", NumGet(lp + 0, "UInt"))
        ext  := NumGet(lp + 8, "UInt") 
        sc   := Format("{:#x}", NumGet(lp + 4, "UInt") | (ext & 1) << 8)
        time := NumGet(lp + 12, "UInt")
        DllCall("HeapFree", Ptr, hHeap, UInt, 0, Ptr, lp)
        oMem.RemoveAt(1) 
         
        ToolTip % "Message = "  . oMsg[msg]
                . "`nvkCode = " . vk
                . "`nscCode = " . sc
                . "`nTime = "   . time 
                . "`nPhysical = "   . (ext & 16 ? "Not" : "Yes")
                . "`n " q "   " ++w "   " oMem.MaxIndex() 
        Sleep 100
    } 
    Return
}

В LowLevelKeyboardProc() возможно узнать физическим было нажатие, или нет.
А возможно ли это в LowLevelMouseProc()?

А, кажется нашёл.

NumGet(LParam + 12, "Short") & 16

Ок. Просто сделеал по аналогии с LowLevelKeyboardProc, там &1 мало.

Если в данном примере использовать функцию, которая является методом класса, в неё по идее должен быть забинден параметр this, как в примере к статье SetTimer, но такой синтаксис RegisterCallback() не поддерживает.