InputHook

[serzh82saratov]

Thanks for the addition, it has become more convenient.
Maybe it’s worth adding an option so that in this version I can get that the key is released, and so that there is no spam on hold.

And I still don’t understand why EndMods is empty for me.
Win10x64.

Code: Select all

ih := InputHook("L0", "{Escape}")
ih.KeyOpt("{All}", "NS")
ih.OnKeyDown := Func("OnKeyDown")
ih.Start()
return

OnKeyDown(InputHook, VK, SC) {
	vksc := Format("vk{:x}sc{:x}", VK, SC)
	ToolTip % GetKeyName(vksc) "`n" vksc "`n" InputHook.EndMods
}

[lexikos]

I may add OnKeyUp. I considered it non-essential because it is used less often, and because it is much easier to detect key-up after being notified of key-down. You can just register one hotkey temporarily or use KeyWait or SetTimer. By contrast, detecting key-down without knowing which key is going to be pressed (and without InputHook) may require hundreds of hotkeys or a long list of keys passed to Input.

With OnKeyUp, it would be trivial for the script to filter out key-repeat (and only slightly more work with some other method of detecting key-up). A built-in option to filter it out would require adding tracking for the key state or repeat status to each individual InputHook, since each InputHook has different conditions for firing OnKeyDown. There is currently 1 bit available per VK/SC, but if that is used, there will be no room for future expansion (of additional per-key options or state).

Why would you expect EndMods to be non-empty?

EndMods: Returns a string of the modifiers which were logically down when Input was terminated.

If the property worked while Input was in progress, it would only be able to return the current modifier state, which is what GetKeyState gives you. The point of EndMods is that the modifier state can change between Input ending and OnEnd executing or Wait returning.

Supporting something similar for OnKeyDown would require adding a parameter.

[serzh82saratov]

You can just register one hotkey temporarily or use KeyWait or SetTimer. By contrast, detecting key-down without knowing which key is going to be pressed (and without InputHook) may require hundreds of hotkeys or a long list of keys passed to Input.

Of course, all this has been implemented for a long time, I propose to make it a solution out of the box.

[lexikos]

That's obvious. My point is that OnKeyUp is lower value than OnKeyDown due to the difference in difficulty of the two tasks.

[serzh82saratov]

You use LowLevelKeyboardProc for this?

[lexikos]

AutoHotkey uses a low-level keyboard hook to detect keyboard events of external applications. The same keyboard hook is used for many hotkeys (including all key-up hotkeys), all hotstrings, Input, InputHook, KeyHistory, the "Always" modes of SetCapsLockState and co., detection of physical key state and idle times, and probably other things.

[serzh82saratov]

I’m talking about this, AutoHotkey already uses a hook, and I need to use another one of my own, and it does not work very reliably. The InputHook lacks key release events - LLKHF_UP, and the definition of the input method is LLKHF_INJECTED. Then I can only use InputHook.I did not understand what you had in mind when you said that it was difficult to add, because all these flags are already in LowLevelKeyboardProc.

[Helgef]

you said that it was difficult to add

Where did you read that?

[serzh82saratov]

I could be wrong, I do not know English. Maybe the conversation was about the inconvenience of adding a new parameter to OnKeyDown.

[lexikos]

I was referring to the relative difficulty of achieving the functionality of OnKeyDown without InputHook or a keyboard hook vs. the functionality of OnKeyUp while already having OnKeyDown:

I considered it non-essential because it is used less often, and because it is much easier to detect key-up after being notified of key-down. You can just register one hotkey temporarily or use KeyWait or SetTimer. By contrast, detecting key-down without knowing which key is going to be pressed (and without InputHook) may require hundreds of hotkeys or a long list of keys passed to Input.

You do not need to use another keyboard hook; you can use the existing one, via hotkeys. When you register a key-up hotkey, all you are doing is telling AutoHotkey's keyboard hook to notify you when that key is released.

I use a separate keyboard hook in a script for debugging keyboard events (like a real-time key history, but showing more raw details), and have never found it to be unreliable.

[evilC]

@serzh82saratov See here for an example of filtering repeats, and also detecting key up.
I build an array (KeyWatchTimers) of function objects for held keys, and have a timer running for each one checking for key release using GetKeyState
Note that in my case I want to support holding multiple keys, so whenever one is released, I go through the array of held key timers and stop them all.
The KeyWatchTimers array is also used to filter repeats

I could be wrong, I do not know English. Maybe the conversation was about the inconvenience of adding a new parameter to OnKeyDown.

Surely a second method called OnKeyUp would make more sense? You could just use function binding in a similar way as I have to have OnKeyDown and OnKeyUp call the same function, but pass a state parameter

[serzh82saratov]

evilC
I ask you to understand me correctly, I have no problems in the realization of desires, it has long been implemented.

Hotkey - http://forum.script-coding.com/viewtopic.php?pid=127550#p127550
Hook - http://forum.script-coding.com/viewtopic.php?pid=72459#p72459

I just suggest adding options to InputHook that make it easier for other people to do this.
I am ready to agree that spam is my business. But, LLKHF_UP and LLKHF_INJECTED should be.

[serzh82saratov]

And, if I understand you correctly, then I do not propose a new OnKeyUp method, I only suggest a parameter for OnKeyDown.

[evilC]

I’m talking about this, AutoHotkey already uses a hook, and I need to use another one of my own, and it does not work very reliably.

You do not need to use another keyboard hook; you can use the existing one, via hotkeys. When you register a key-up hotkey, all you are doing is telling AutoHotkey's keyboard hook to notify you when that key is released

I was merely elaborating on what Lex was saying here and illustrating on how to do it without another hook or even another hotkey
My code appears 100% reliable

Don't get me wrong though, I myself requested OnKeyUp too..

[evilC]

And, if I understand you correctly, then I do not propose a new OnKeyUp method, I only suggest a parameter for OnKeyDown.

Having OnKeyDown fire events for key up seems wrong - pointless to break backwards compatibility and make the name misleading

[serzh82saratov]

and make the name misleading

That is why the conversation took place now. Only now, the creator wants to make the hook available to everyone. And if so. Then do not miss the moment until it becomes law.

[nnnik]

So you are telling me I cant use the InputHook object to detect KeyUps since it is already possible to do that by adding Hotkeys in the KeyDown callback?

[serzh82saratov]

1.1.32.00 - November 24, 2019

Added InputHook OnKeyUp callback.

Many thanks!

[serzh82saratov]

Do you think it is logical that Escape sometimes generates KeyUp? It seems to me that the exception cannot be KeyUp.

Code: Select all

ih := InputHook("L0")

ih.KeyOpt("{All}", "NS")
ih.KeyOpt("{Escape}", "E")

ih.OnKeyDown := Func("OnKey").bind("Down")
ih.OnKeyUp := Func("OnKey").bind("Up")
ih.OnEnd := Func("OnEnd")

ih.Start()
return

OnKey(Direction, InputHook, VK, SC) {
	vksc := Format("vk{:X}sc{:X}", VK, SC) 
	ToolTip % GetKeyName(vksc) "`n" Direction
}

OnEnd(InputHook) {
 	InputHook.Start()
}