Quote:
My real mouse and AutoHotKey seemed to generate the same flags, neither of which evaluated as having the bit set. But, if you said on your own system you can confirm with low level hooks that AutoHotKey does generate an event with the INJECTED bit set, and your real mouse doesn't, then I must have overlooked something.
Try this test script. On my system it proves that the injected bit is different. If you let the mouse move artificially every 3 seconds, the physical idle time is unaffected. But if you physically move the mouse, it will reset the physical idle time too:
#InstallKeybdHook
#InstallMouseHook
SetTimer, ReportIdleTime, 1000
SetTimer, MoveMouse, 3000
return
ReportIdleTime:
ToolTip, Overall: %A_TimeIdle%`nPhysical: %A_TimeIdlePhysical%
return
MoveMouse:
MouseMove, 3, 3,, R
return
Quote:
I was going to utilize a hook and strip the injected bit off the data, and that would overcome the problem I thought.
That's pretty interesting. I once tried this and would be willing to try it again if you think it might help you.
Quote:
If you have working code for your system that does proves autohotkey sends an INJECTED event, and your physical mouse does not, I could probably hook that method with madCodeHook and perhaps strip the injected flag before it's returned.
If the above script works for you like it does for me, the relevant part of the source code is in hook_include.cpp. For keyboard, the flags field should have <b style="color:black;background-color:#ffff66">LLKHF_INJECTED</b> in it if it's an artificial event. For mouse, it should have LLMHF_INJECTED (one letter different) instead.
in win32k!xxxKeyEvent (yes, you'll need a device driver), and the LLKHF_INJECTED flag will never be put into the input stream. Period. It's in the kernel.
Login
Register
FAQ
Search
