This project has moved. For the latest updates, please go here.

Simulate Key Being Held Down


As was requested in the discussion forum, I'm submitting this as an issue:

I'm looking for a way to simulate a key being held down so it will repeat (preferably with the ability to hold down any of ctrl, alt, and shift at the same time)? Doing this would presumably require sending a command when the key is to be initially pressed and then another command when the key should be released - very similar to the shiftdown / shiftup commands for the modifier keys.

This would be useful for things like using cursor keys to scroll through lists.

I'll be using the TCP/IP interface with a Crestron control system. I realize that I could sort of simulate this with an oscillator to send a series of cursor down or cursor up commands, but that never results in the same smooth operation you get with a proper key held down command.

I did a little searching in Goggle and found some info that may be useful here on the AutoHotKey forum:

Based on the discussion there, it looks like repeats can be simulated by sending a series of keydown events followed by a keyup event when done (I'm assuming these get translated to WM_KEYDOWN and WM_KEYUP), which is essentially what a physical keyboard does. So something like:

loop until keyup command received via TCP/IP (or RS-232)
send WM_KEYDOWN {uparrow}
sleep 30 (milliseconds)
send WM_KEYUP {uparrow}

In the discussion forum, you mentioned the risk of a key being stuck down in case of a network drop, but that's a risk I'm willing to live with. Something that could be done to reduce that risk would be to require receiving an interim command within every N seconds and to exit the loop if that command isn't received. Ideally, the repeat rate (the sleep parameter) would be passed in along with what key is being held down so the repeat rate could be adjusted as needed.

The problem with doing the delays between keystrokes on the other end of the TCP/IP connection is that the repeats become erratic partly because of latency in the TCP/IP protocol.

Thanks for your consideration,