A global mouse and keyboard hook for vvvv gamma. In contrast to the GlobalHook stuff posted in the forum and the chat beforehand this package is not based on MouseKeyHook but on SharpHook by Tolik Pylypchuk.
After some deliberation I chose Sharphook because:
Forgot to add the dependency on SharpHook to the nuspec… Should be fixed with the upcoming version. For now you have to install the dependency manually.
I suspected something like this, but I just checked with the global.io.keyboardstate for both keyboard and global hook simulator input. Your keyboardstate shows the same key order for both input methods.
Comparing system.keyboardstate with global.io.keyboardstate shows the reverse keypress order coming from the keyboard simulator… I tried inputting the reverse order, but it did not solve the problem.
Dug a bit deeper and turns out I was looking in the wrong place. Unfortunately there is nothing I can do about the issue. But you can work around it by using a non-german keyboard layout :)
I have been playing with the contrib a bit today to try and replace my own snippets I had done with MouseKeyHook, and ran into a couple of funny things.
Can any of you reproduce the behaviours illustrated in the attached patch?
Problem #1
IsKeyDown and IsKeyPress react on different set of keys only; while IsKeyUp works with them all
Problem #2
There is a inconsistency between my keyboard’s output and the key detected out of KeyboardState, which makes it very difficult to ensure consistency across users if I need to match a specific key.
Interestingly, the detected key out of KeyboardState is different from what is typed in any text field in vvvv (which is consistent with my physical key on my keyboard).
Afaict this is standard windows behaviour and Skia keyboard behaves exactly the same. Unfortunately official documentation on this is sparse. Here is a SO question touching on that topic.
Problem #2
This is also “normal”. If you need the actual character you can get it from the KeyPress event.
Afaict this standard windows behaviour and Skia keyboard behaves exactly the same. Unfortunately official documentation on this is sparse. Here is a SO question touching on that topic.
Yes, it seems to be expected behaviour indeed, as kindly pointed to me by @sebescudie:
- KeyDown Event: The KeyDown event occurs when a key on the keyboard is first pressed down. This event is raised for both non-character and character keys, including modifier keys (e.g., Shift, Control) and special keys (e.g., arrow keys, function keys). The event is raised before the character input is processed, which means it can be used to detect non-character keys or handle key combinations (e.g., Ctrl+C for copy). - KeyPress Event: The KeyPress event is raised for character keys only, such as letters, numbers, and symbols. It occurs after the KeyDown event and before the KeyUp event. The event provides a KeyPressEventArgs object that contains the character representation of the key that was pressed. This event is suitable for handling input that involves actual characters, like text input in textboxes or other text controls. - KeyUp Event: The KeyUp event is raised when a key on the keyboard is released. This event is triggered for both non-character and character keys, similar to the KeyDown event. It occurs after the KeyPress event and can be used to detect when a key has been released after being pressed down.
Problem #2
This is also “normal”. If you need the actual character you can get it from the KeyPress event.
Thanks a lot for the snippet!
Would definitely be worth adding to the help patch ;)
