Possible to pass through non-mapped keys and have them "work like normal"?

[dhess83]

Hello, thank you for your project.
I have Multi-Keyboard-For-AHK working with Autohotkey so that I can make custom key combinations on different keyboards. Thank you!

Is there an option to send other keys straight through to the system? For example, if I wanted to press the letter 'A' on a keyboard that is added in the configuration.ini file, no keys are sent through. LuaMacros had a way to enable non-mapped keys.

if (direction == 1) then return end -- ignore down; if you want to be able to type the original letters as well with the secondary keyboard, remove this line

This was how LuaMacros handled it. Is there a way to do this in your software?

[sebeksd]

Hello, thank you for using my software :)
Right now there is no option to do that in app, adding such an option was not in my plans.
However I think you should be able to do that in Autohotkey script by adding keys you want to some functions that will send them as key presses to OS (functions like SendText, SendInput I think). You may also add "else" to pass all keys that way.

Please try that and report back if you were successful, if not I will try to look at it later this week.

[dhess83]

I thank you for replying. I was able to use the sample autohotkey script to write an else statement to send a key to the OS using Chr(VKeyCode) and then SendRaw. However, this doesn't take into combinations using modifier keys, such as shift or control, that change a key's function.

Unfortunately, I am a novice coder, and I think this is above my current level of understanding by quite a bit. I understand projects like this don't pay and probably take a lot of time to maintain, so I understand if you can't help with this.

[sebeksd]

I will try to look at it in this week. This project was done mainly for myself and till now I didn't need functionality that you requested that is why it is not implemented (or in example script).

[sebeksd]

Hi.

I just modified example script to add pass through example, try it yourself and report back how is it working for you. It is definitely not a perfect solution. I tested it very shortly on BT keyboard because my normal secondary (macro) keyboard is numeric only so it has no control keys to test :P

Two things to remember:

1. there are two new functions, remember to copy them to your script: "byte2hex(int)" and "DoPassThrough(...)"
2. add else after you catch all necessary key presses and execute DoPassThrough (like in example)

[dhess83]

I really appreciate your willingness to help, but unfortunate it does not work in a way that I would consider reliably enough to be viable. A couple things -- held keys do not work correctly. For example, holding an arrow key to move a cursor in a text field. Certain key combinations to not seem to be working correctly either. There seems to be a substantial delay\latency as the input is passed through the Autohotkey layer. Also, for some reason my caps lock seems to go rapidly on and off as I use this software... not sure if that is on my end for some reason, or what.

To be honest, I think for this to work efficiently, there would need to be a way to exclude keys from the .dll\application level before reaching Autohotkey. I am sure that would be a lot of work as you would have to implement a key exclusion table in your config file, and make your keyhook dll file become aware of those.

I ended up coming with an alternate solution for the issue I was originally facing, I now used sequenced hotkey combinations in Autohotkey instead of keyboard specific macros. For example, I can Press Winkey + F2, then Winkey + F3 to do what I had intended for Keyboard to do when I press Winkey + F3. In other words, my first input being a "location" selector, my second input being an "action" selector.

TL:DR; I really thank you for your attempt to help me with this, but at its current implementation it is not something I could use. I really do appreciate your work as a developer though.... take care!

[sebeksd]

unfortunate it does not work in a way that I would consider reliably enough to be viable

Yes, I was expecting it will work not perfectly. I was hoping it will be enough for your use case.

To be honest, I think for this to work efficiently, there would need to be a way to exclude keys from the .dll\application level before reaching Autohotkey. I am sure that would be a lot of work as you would have to implement a key exclusion table in your config file, and make your keyhook dll file become aware of those.

Yes, this should work but require more time on my end that I don't have right now. Maybe I will have time on this weekend and will try add something simple (without GUI).

[sebeksd]

Hi.
Just implemented new option. Because I did only preliminary testing this is pre_release.
Please try it and report back if this work for you, all information how to configure new options you will find in Readme in section "Additional options".

I think it still might lack one function for you but I will wait for your opinion first.

[bjrkis]

Awesome project. I love it.

I would love this functionality since it could potentially allow me to use two layers on my numpad. I've just tried the prerelease and it works like a charm so far. However, despite configuring only catching 103 and 105, 104 still works (three out of three set in AutoHotKey.

configuration.ini:
[General]
StartOnAppLaunch=1
DeviceCount=1
[Device1]
Enabled=1
Name=Deltaco@home
Number=2
SystemId=\?\HID#VID_062A&PID_4101&MI_00#A&1917894F&0&0000#{884B96C3-56EF-11D1-BC8C-00A0C91405DD}
CatchAll=0
CatchVKCodes=103,105

AHK log:
002: SendInput,{Media_Play_Pause} (0.03)
002: Return (2.39)
003: SendInput,{Media_Prev}
003: Return (1.13)
001: SendInput,{Media_Next}
001: Return (1.39)

[sebeksd]

Awesome project. I love it.

I would love this functionality since it could potentially allow me to use two layers on my numpad. I've just tried the prerelease and it works like a charm so far. However, despite configuring only catching 103 and 105, 104 still works (three out of three set in AutoHotKey.

configuration.ini: [General] StartOnAppLaunch=1 DeviceCount=1 [Device1] Enabled=1 Name=Deltaco@home Number=2 SystemId=?\HID#VID_062A&PID_4101&MI_00#A&1917894F&0&0000#{884B96C3-56EF-11D1-BC8C-00A0C91405DD} CatchAll=0 CatchVKCodes=103,105

AHK log: 002: SendInput,{Media_Play_Pause} (0.03) 002: Return (2.39) 003: SendInput,{Media_Prev} 003: Return (1.13) 001: SendInput,{Media_Next} 001: Return (1.39)

Today I did test configuration you described and I don't see any problem. Could you please describe it more in detail?
When I set CatchVKCodes=103,105 only numpad 7 and numpad 9 was reported to AutoHotkey:

Autohotkey script part for this keyboard:

if (KeyboardNumber = 5)
{
	MsgBox % "Keyboard: " . KeyboardNumber . " Key: " . VKeyCode	
}

Maybe problem was elsewhere, when app restarts it will save current config to a file and this could overwrite your modifications to it that was done manually. In version 1.1.0.2 I have change this behavior so it will only save config when something was changed in configuration window so it would less likely overwrite user modification.
Also in this version there is new option in tray that will open config file directory for you (I was annoyed when searching manually opening this path :P).

[TarkanV]

Ì made a working prototype that allows for catching only specific keys that were assigned... It basically just listens for ahk through a tcp server and changes the catchlist dynamically depending on the keycodes autohotkey sends to it...

And it works globally or per program (global keys still work on any program but can be overridden by the assignments of programs) and it is compatible with different profiles per program.

However, it still can't differentiate between KeyCode alone and ModifierKey + KeyCode, so I'll have to look into that...

Anyway, I have it working on my own fork and there is a new sample code for testing it out and compiled .exe. : link.

However, the .exe might not be suited for the regular ahk examples, and it is much more complex to setup for now so it might not be worth it for some... I mean, I have my own third party GUI that auto-generates the appropriate Ahk code, making it 100x easier to set up lol, so it's fine for now on that front.