GetKeyState for XBox Elite controller stops working when window is not active

[evilC]

I have had numerous reports of this from users of my scripts, and have no idea what is causing it.

THIS ONLY HAPPENS WITH XBOX ONE, ELITE OR ACCESSIBILITY CONTROLLERS

Test script:

Code: Select all

id := 1
OutputDebug DBGVIEWCLEAR

Gui, Add, Text,, Stick ID:
Gui, Add, DDL, x+5 yp-3 AltSubmit gStickChanged hwndhStickId ,1|2||3|4|5|6|7|8
Gui, Show, w200 h200

GoSub, StickChanged

Loop {
	ToolTip % GetKeyState(id "JoyX")
	Sleep 100
}

StickChanged:
	GuiControlGet, id,, % hStickId
	return

^Esc::
GuiClose:
ExitApp

On the same system, using GetKeyState on a keyboard key continues to work while the window is inactive
Just doing a loop with Tooltip % A_TickCount continues to work while the window is inactive
So this seems to be solely related to the XBE / XBA controllers

[nnnik]

Yeah thats part of windows game controller design - as far as Im aware.

[evilC]

Yeah, it seems that the XBO / XBE / XBA do not use XUSB.sys

[OneSwitch3000]

Any help with this would be much appreciated (thanks for raising @evilC).

It means that the new Microsoft Xbox Adaptive Controller, aimed at otherwise disabled people, can't make use of Auto Hot Key with it. It would be massively useful if it could.

Here's an example of a single switch being able to navigate a 3D world thanks to AHK (inside of the Universal Controller Remapper): https://switchgaming.blogspot.com/2017/ ... utton.html

It would be fantastic to get Xbox One controllers working with AHK, and hugely empowering for a wide range of people.

Fingers crossed.

[nnnik]

Well Steam and PPSSPP do it somehow - I just don't know how.

[lexikos]

GetKeyState with keys has virtually nothing to do with GetKeyState with joystick buttons, axes and info. They use totally different methods of detection.

This particular issue is just another limitation of the WinMM API, introduced by Windows 10 anniversary update.

My feeling regarding replacing the WinMM API myself has not changed.

DirectInput (like WinMM) has a limitation regarding the triggers on XInput controllers, while XInput only supports a much more limited subset of buttons and axes (and controllers). DirectInput is useless to me because I only use XInput controllers, and built-in XInput support would not be a sound investment of my time because I haven't used a controller with AutoHotkey in three years, and XInput.ahk already does everything I needed.

These are the alternatives that I know about for XInput (Xbox 360 and Xbox One) controllers:

• XInput.ahk (the one I wrote and use)
• CreeAll's version with Guide button support
• AHKXbox360Lib: OOP Library of Xbox360 Controller for AHK - by edipoReboucas
• JoystickWrapper by evilC

[evilC]

@Lexikos - Thanks for the confirmation

@OneSwitch3000 - This was not really about trying to get XInput support built in to AHK, I was just trying to ascertain what the root cause was and whether there was a simple fix.
I think it would be much less work for me to implement XInput in UCR than for Lexikos to integrate with AHK, and I am not sure there is a huge amount of advantage in the latter.
I had hoped to not put any more dev effort into UCR-AHK, instead focusing solely on UCR-C#, but migrating you away from UCR-AHK is not going to happen in the very short term, so I am going to have to bite the bullet I suppose - I am looking into integrating XInput into UCR-AHK now.