AutoHotkey Community

[TheGood]

Download

Examples on how to use it:
Example 1 allows you to look at all the HID devices currently connected to your computer.
Example 2 allows you to register devices and examine the data coming out.
Example 3 is an example on how to detect mouse events, such as left mouse button up, wheel down, etc...

Documentation (also included in AHKHID.ahk)
Let me know if the webpage doesn't look right to you. I know next to nothing in HTML and had to learn through trial-and-error in order to build that page.

How do I stop the default keypresses coming out of my device?
This is a question that has been asked often enough to warrant answering it on the main post. AHKHID cannot stop a device's default keypresses from generating. This functionality is not part of the raw input device interface that AHKHID wraps.

If you need to disable those default keypresses, you have three options, depending on which category you fit in:

• If the device shows up as a remote, you can easily disable/modify the keys sent by modying the registry. For more information on this technique, see Step 5 of the tutorial posted below (second post in this thread).
  
• If it does not show up as a remote, but does show up in the Other tab whose TLC when registered allows you to capture all the keys, then you can try uninstalling the keyboard. For more information on this technique, see here.
  
• If it does not show up as a remote or as a device in the Other tab, but as a keyboard only, then you can try registering the keyboard TLC (UsPg 1 and Us 6) and filter the relevant keypresses. Look here for a sample script on how to do that. Don't look at the second method described in that post, it does not work.

If you somehow don't fit in any of these categories, then make a post and I'll see if there might be another way.

Extreme method: Disabling all simulated keypress events
This is another method which will disable all simulated keypresses (from devices, as well as from the Send command), but allow the physical keypresses to go through. It obviously has a huge drawback, but it's there if you really need it.

[TheGood]

Tutorial

Here is a real life example of how to use AHKHID.
When I bought my HP Media Center a few years ago, I also received this nice remote with a receiver which connects through USB. The remote is meant to be used with the Media Center interface.



However, I eventually changed computer but still had the remote. So, I started wondering if I could find a way to detect all the button presses and assign labels to each of them. Although some of them triggered keyboard events (like the arrow buttons, the numbers, the OK button and the volume up/down button), I had no way of knowing if it came from the remote or from the keyboard.

So, these are the steps I used (and the steps you can use for any other HID device).

1. Figuring out the device specs

First thing I had to figure out was to get the Vendor ID, Product ID, Version Number, and most importantly, the Usage Page and Usage the remote operates on. To do this, I fired up Example 1 and looked at the "Other" tab. The following picture is a screenshot of what I saw. In red are the "devices" registered to the remote (I know this because they only appeared after I plugged in the receiver).




As you can see, the three devices are from the remote. However, they all operate on a different Usage Page and/or Usage. Anyways, at least now I know what the Vendor ID, the Product ID and the Version Number are (which will be needed later on in the script in order to make sure the input comes from the remote).

2. Reverse engineering the data

So now that I know on which Usage Page/Usage the remote operates on, I can fire up Example 2 and look at the data coming out of it. However, since the remote possesses three different TLCs (TLC means the Usage Page and Usage values), I had to register the three of them. Also, I modified Example 2 so that the output also shows the Usage Page/Usage values from which the data came from (so that I can distinguish between the three). Then, I clicked the Call button and started pressing buttons.



This is the part where I had to "reverse engineer" the data. I realized that

• The TLC with UsPg 65468 and Us 136 showed down and up events only for some buttons.
  
• Similarly, the TLC with UsPg 12 and Us 1 showed down and up events only for some (other) buttons.
  
• Together, those two TLCs did not cover all the buttons.
  
• And most importantly, the TLC with UsPg 65468 and Us 137 showed an event for every button pressed, but only on the down event.

3. Collecting data

I decided to therefore concentrate on the last TLC (the one with UsPg 65468 and Us 137) because it was the only one with access to all buttons and because I didn't really need the Up event. However, I obviously could have decided to support as many buttons with up/down events, but I just felt it would have been extra work for not much (for what I wanted to do with it).

So now, I had to make a list of the data received for each button press. I therefore created a nice spreadsheet where I typed out the name of all the buttons. I then modified Example 2 so that instead of adding data to the listbox, it would simply do SendInput % Bin2Hex(&uData, r) "{Enter}"
which means it would insert the data (in hex format) in the cell and then press Enter to go to the next cell. This is what I got:



As you can see, I noticed that the only thing that changed for each press was the value of the 6th byte (the 7th byte is also different, but it only alternates between 04 and 84, no matter the buttons pressed).

4. Creating a script

All I had left do to was to create a simple script which would register the remote and check the 6th byte on input to see which button was pressed. The goal of the script was to add remote functionality to VLC and MPC (Media Player Classic). Instead of creating a label for each button, I decided to create labels only when needed, such that the OnMessage function only had to check if the label existed before calling it. I also added a prefix to the label, such that the label to be called would depend on the program currently in focus. For example, if VLC is in focus, the prefix would be "VLC" such that when you press the button with value 22 (which is Play), the OnMessage function will call the label called VLC_22 (if it exists). This is the resulting script:

[k3ph]

wow, awesome! this is a must have tool!
this really should be included in the official installation pack!!!

i loved the vlc/mpc stuff, great idea!

thanks for sharing it, wonderful work
when i get time, i'll test it with more different devices :D maybe i can ressurrect some old stuff here...
_________________
                                  [ profile | ahk.net | ahk.talk ]

[TheGood]

I'm glad you like it!
Definitely come back if you have any problems with your HID devices!

[b0ring]

Firstly, a huge thanks for creating this especially since I'm running 64bit so AutoHotkeyRemoteControlDLL didn't work, and Girder hasn't seemed to work with HID since version 3.

I had to rejig your code a little to get it to work with my remote, it seems to be running fine but I'd like a little feedback on how I've set it up since I'm a complete newbie to autohotkey.

When running Example 2 to catch the data, mine is in the format "Data: 040002"; "Data: 040040"; etc. My code is as follows...

[TheGood]

OK, I have to go to work right. But I'll give you a more detailed response tonight.

All I can tell you for now, is to make a complete list of the data coming in for each button (like I did in Step 3). In my case, only one byte was different, the 6th one, hence the NumGet(uData, 5, "UChar"). It might be different in your case (if one byte is not enough to differentiate between buttons).

The example script I posted is really just an example. It's very device-specific in many ways. I'll try making a script "template" to help guide you.

[n-l-i-d]

Very good stuff!

[TheGood]

[b0ring]

[LarryD]

First of all thank You for the great script!!!
I succesfully tested it on Windows 7 x64.

Is it possible somehow to repeat the generated keypresses (SendInput) if the user holds the remote button pressed for a longer time?

[TheGood]

[LarryD]

Thank you for the quick replay!
Unfortunately I can detect just one event, the down event.
I'm trying to use an MCE remote (UsPg 65468 and Us 137).
Any ideas? Maybe reading multiple times with HID_GetInputData?

[TheGood]

Unfortunately, there's no way around it. If you don't have an Up event, you can't know when the button is released, and therefore you can't know when to stop repeating the keypresses.

I find it surprising that your MCE remote doesn't send an Up event. Is it the same model as mine? Did you test the buttons under all registered TLCs? Don't forget also that the Up event is not necessarily on the same TLC as the Down event.

[Micha]

Hi,
thanks for the script.
At my post (DLLCall: Support for Human Interface devices) I put a link to your solution.
I hope you'll continue developing it.
Ciao
Micha

[TheGood]

Thank you Micha! I really appreciate the link.

I made little updates: