AutoHotkey Community

Sorry to be dragging up an old topic, but I wanted to comment on how amazingly useful this addition is. I'm experimenting with it at the moment to be able to make use of the zoom slider and "programmable" keys on a Microsoft Ergonomic Keyboard; they're presented as buttons on a separate USB device to the rest of the keyboard, so they can't be remapped (even with AutoHotkeys) like regular keyboard keys can.

Just to confirm the answer to XavierGr's question: I use a Logitech G5 mouse, so I checked Micha's test script with that. It worked fine on all buttons (except the DPI-switching ones, which I don't think are actual input buttons anyway). Oddly, button-press and button-release appear to show up as presses of separate buttons: pressing the left button triggered an event with BtnFlag=1, but releasing it sent one with BtnFlag=2; the right button sends 4 on press and 8 on release; the middle (wheel) button sends 16 and 32, and so on. (Mind you, this might be normal for all I know...)

There still seem to be limitations in the current version (for instance, all five of the "programmable" keys seem to send identical event data, as do the different directions on the D-pad of a gamepad I tried), but that might just be the test script. If not, I guess I might have to go find a Windows C++ compiler and start digging through the MSDN docs...

Oh, a small feature request (I don't know if the Windows API lets you do this, but it should): it'd be nice if we could call GetHIDDeviceInfo on keyboards and mics as well. They are just particular classes of HID device, and the information you get back (particularly vendor and device IDs) makes it a lot easier to determine which device you're actually looking at.

This is really useful - however I have a slight problem. My remote also shows as 2 devices (as in Micha's example script), however there are 2 pairs of buttons on the remote that return identical values (the difference just being the different device).
Is it possible to identify the source device ID that generated the event?

Hi,
I already use that call, but it return different values for HIDs, Mice and Keyboards:


As you can see, if calling it for a mouse, you can only receive the infos id, numofbtns, samplerate.

Vendor is only listed for HID-devices.

Ciao
Micha

I'll upload a new version today or tomorrow. I've changed the function:


The last parameter is the Devicehandle that generated the event
Ciao
Micha

Hi,
I've uploaded version 1.01.
You can receive the devicenumber which generates an event.
Please have a look at the sample-script.
Ciao
Micha

I'm getting errors with the new DLL, even using the older version of the test script; GetDeviceCount (which shouldn't have changed at all) is returning an errorcode of -3. (RemoteControl.ahk returns the same error from RegisterDevice, though I don't have an appropriate remote, which might be causing that problem.)

I'm on Windows XP Pro with all current patches; I'm pretty sure I'm using the newer version of the DLL, though its internal version number is still listed as 1.0.0.0. (Unfortunately, I didn't think to back up the older one; the MD5 hash of the one I have is 650C8C4EF25DCAFFF328D474E70ACB08, though.) The one included in the source zipfile seems to be different (though it still gives the same errors); I'm also not sure if that's the 1.0 or 1.01 source.

Hi Tarquin,
from the help:


It seems that the path to the dll is wrong or the dll can't be loaded.
The reason can be that a dll, which my dll depends on, is not at the right place.
Do you know dependency walker?
With that free program you can analyse the loaded dlls.
Download the program at http://www.dependencywalker.com/
Load the autohotkey.exe from dependency walker (file open).
press F7
As argument enter path and filename of the AHK-script.
Enter the folder where the script is located as "Starting directory"
Click on "ok"
Please e-mail me the output to misifusc-ahk@yahoo.de

Ciao
Micha

No need for the detailed output - the reason is clear enough just from opening AutohotkeyRemoteControl.dll. It's linked against the Visual C++ 8.0 (or 2005, or whatever) MFC and runtime libraries (mfc80.dll, msvcr80.dll), which I don't have.

I suspect the same problem is likely to bite other users as well, since I'm seeing a fair few topics in a quick Google search saying basically "How can I avoid having to package these files with my app?". Any chance of a statically-linked version? It shouldn't bloat the size too much, since you're only using a handful of functions anyway...

Hi,
please download the mfc-files from
http://www.autohotkey.net/~Micha/mfc_dlls.zip
or install the Microsoft vcredist-files.

I do not want to statically link the mfc-files. The dll would grow from 16 to 230 KB. This is not very much, but I've posted other dlls which would be over 25 times bigger.
At the moment the mfc-80-files are very new. Only few people have them already on their system. I'm sure everybody would have the mfc40-dlls because their really old and a lot of software is using them.

As time goes by the chance grows that other software installs the files on your system. Then it's a waste of resources to statically link the files.
I know it's unconvenient at the moment to install the files "by hand".

I've updated the first post and mentioned that you need the mfc-redist files.
Ciao
Micha

Thanks, that solved the problem (at least once I figured out that I did in fact need the .manifest files as well...) The other way to solve the problem would be to specfically link against the 7.0 versions of the libraries (which are standard on Windows XP), but I don't know whether VS2005 lets you do that.

I'm working on improving the test script for my own testing purposes; if I get it to a state I'm happy with, I'll mail you a copy. One thing that I'll be implementing in the script is "unregistering" of devices, thanks to the new additions in 1.01 - you can't really unregister them, of course, but if you know the ID of the device that generated an event, you can check it against an ignore list. I don't know if it's worth adding that to the main DLL; it'd probably be faster to do the check there, but it's really only relevant for testing and debugging, where performance isn't usually the main concern anyway...

I'm looking forward to it
Ciao
Micha

Thanks for this great DLL!

I have 2 HID remotes:
one comes from Sapphire 550Pro TV Card and it basically works.
another comes from Creative Audigy 4 Sound Card but it is not working at all.

I think I have found the reason, let's see if I am correct.

Here's the log for the TV Card remote of 3 different kinds of button:
- 0 - 49 - 48
- 51 - 49 - 48
- 0 - 50 - 49 - 52
- 54 - 50 - 49 - 52
MakeCode: 80
Flags: 3
Key: 40
Msg: 257
Extrainfo: 0
MakeCode: 80
Flags: 2
Key: 40
Msg: 256
Extrainfo: 0

This remote has different length commands and even some buttons work in the same way as HID keyboard.

Yesterday, I have visit my friend and found that he is using the same sound card remote with Grider.
So I have try out his Grider, but I think autohotkey is much better and I don't want to switch to Grider since I have using autohotkey for at least a year, I don't remember.

However, when I try again today I found the reason:
The sound card remote has simply long commands!
I think it would be 5 bytes long as follow:
- 12 - 34 - 56 - 78 - 90
Then, I look into the source I found that it is using UINT which is 4 bytes long, am I correct?
My C++ programming ability is very limited at just better than hello world level. Would Micha tell me it is true or not?
And please fix it if it is true when you are free.
Thank you very much.

That's unlikely - my keyboard (parts of which also show up as a HID device) returns eight bytes of data in its events, and Micha's test script displays that just fine. (My C++ skills are also fairly rusty, but I believe the function you're looking at returns a huge blob of BYTEs (*chRC, the actual event data), with the UINT (*RCSize) indicating the number of bytes therein. This should handle a device returning up to 4GB of data in an event message, system memory limits notwithstanding.)

Are you sure the sound card remote is actually showing up as a HID device? (It probably is, but if for some reason it's treated as some other sort of device, Micha's DLL won't be able to see it, no matter how many things you register...)

Hi,
Tarquin is fully right.

RCSize is the amount of data
BYTE is a pointer to the memory where the data is saved
Ciao
Micha

Thanks Tarquin and Micha.
Yes, I'm sure the sound card remote is shown as HID device since it only appears when it is plugged in:
Vendor:1054, Product:12544, VersionNr:257, UsagePage:65280, Usage:0, Name:\??\HID#Vid_041e&Pid_3100#7&17549d74&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}

Sorry, I don't know why I misunderstood the source, this proved that I have to work really hard in C++.

P.S.
I found that my system has already installed mfc80 before using HID DLL so I didn't notice mfc80 is required at all.
Just want to provide the link here as it is better than extracting mfc80 to autohotkey's folder:

Microsoft Visual C++ 2005 Redistributable Package (x86)
http://www.microsoft.com/downloads/deta ... layLang=en