key up events and AutoHotKey

[inpd]

If I run the following simple AHK hotkey script on the slave:

NumpadDot & Q::
kystate:=GetKeyState("Q","P")
MsgBox %kystate%
return

the return value when I hold down NumpadDot and Q together on the
keyboard connected to the master is reported as 0 in the message box,
which is incorrect since it should be 1 to reflect the physical state
of the Q key. Indeed, if I connect a keyboard directly to the slave
and hold down NumpadDot and Q on that keyboard, the value 1 appears in
the message box.

Any thoughts on what might be happening here and how to fix it? This
was just a simple test I devised to understand why they hotkey below
stopped working when I connected to the slave machine through the
master using Input Director:

NumpadDot & W::
SendInput, {Shift down}
KeyWait, W ;
SendInput, {Shift up}
return

In fact, if I run instead:

NumpadDot & W::
SendInput, {a}
KeyWait, W ;
SendInput, {a}

I always get 'aa' even before I lift up the W key which suggests the
KeyWait for a key up event is not being triggered.

Thanks in advance for any suggestions you can provide -- Input
Director is otherwise a great piece of work that works much nicer in a
Windows-only environment than Synergy.

[sh...@inputdirector.com]

Hi,

It might be that AHK is monitoring "non-simulated" input and so not
registering keyup/keydown strokes injected by Input Director.

Regs,

Shane.

[inpd]

Thanks for your response -- I think you're right.

I've now studied the AHK documentation in more detail and used a
script called KeyStateMonitor which I found in the AHK forums to run
several experiments. KeyStateMonitor reports back in real-time the
"logical" and the "physical" states of the key(s) one is monitoring,
which are usually the same unless AHK's low-level keyboard hook is
installed.

Certain functionality in AHK requires that its low-level keyboard hook
be installed. When the keyboard hook is installed, the logical state
of a key is whatever the object (window, ...) receiving the event
thinks it is, which is not necessarily the same as the physical state
of the key (i.e. whether the user is physically pressing down the key
or not). Since Input Director sends "simulated" keystrokes, the
keyboard hook distinguishes them from physical keystrokes, creating a
problem for using the KeyWait command in hotkeys to detect physical up/
down keyevents.

In short, is there a way to include an option in Input Director to
send physical key events instead of simulated ones to the slave, if
this is even possible? If so, that would allow more AHK scripts
running on the slave to be controlled by the master without
modification.

If not, I'll continue digging on the AHK side of this issue to see if
there is a workaround -- although the output from the following simple
example is a little discouraging:

Z::
keystate:=GetKeyState("Z")
MsgBox, %keystate%
return

This returns a 0 after pressing the Z key not only when connecting to
the slave from the master but also when typing on the keyboard
connected directly to the slave. This invocation of the GetKeyState
returns the logical state of Z, not the physical. It appears that the
hotkey trigger (Z::) discards the simulated keydown event before the
GetKeyState("Z") inside the hotkey definition can see it. On the
other hand, if instead one calls GetKeyState("Z","P") when typing Z on
the keyboard attached directly to slave, the script returns 1.

I hope the above discussion does not contain more detail than you want
to digest regarding Input Director's interaction with AHK. Again,
thanks for your response and for sharing with everyone such a great
piece of software.

[sh...@inputdirector.com]

>
> In short, is there a way to include an option in Input Director to
> send physical key events instead of simulated ones to the slave, if
> this is even possible?  If so, that would allow more AHK scripts
> running on the slave to be controlled by the master without
> modification.

No - an application can only inject simulated input. The vast majority
of applications don't differentiate between the source of the input
and so this isn't a problem. Hopefully there is someway you can get
AHK to ignore the source of the input and just act on the input
itself.

Regs,

Shane.