locked
Event Listeners for state changes of XInput API?

    Question

  • I have been playing around with this:
    code.msdn.microsoft.com/windowsapps/XInput-and-JavaScript-c72fe535

    When I remove the renderLoop, the events only trigger if I am pressing an input while the app is loading. Pressing or moving stuff after the app has loaded does nothing. Is there any way around this?

    I did try event listeners but didn't have much luck.

    Thanks.

    Wednesday, April 24, 2013 10:35 PM

Answers

  • XInput controllers are not considered an essential form of input for Windows Store apps, but something you can support if there's a scenario that works for it (like a game). The Store certification requirements only stipulate (a) touch, and (b) mouse+keyboard, so everything else is optional.

    In this case too, clearly the controller is not set up for an event-driven model via WinRT, as you have to resort to a component accessing Win32 APIs. The whole purpose of the sample is to show that this can be done, but is not there to say it must be done. So yes, focus on more essential features if a controller is not a core part of your app's experience.

    • Marked as answer by ViralBeeb Saturday, April 27, 2013 11:19 PM
    Thursday, April 25, 2013 8:53 PM

All replies

  • The XInput API (part of DirectX, see here) is designed around a polling model rather than an event model. The XInputGetState API in Win32, which is what this sample is using through a WinRT component in C++, simply returns a structure with the present state of the controller.

    I assume that in your modified sample the renderLoop function is called the first time, and that you've removed the requestAnimationFrame call from the end of that function. In this case, that one call to renderLoop gets the state of the controller once via controller.getState (in the component), so you see the effect you describe. But as there are no events from the controller, you won't see any changes because you're not calling controller.getState again.

    To create an event-driven behavior, you would basically need to set up some kind of polling loop within the WinRT component, e.g. some thread that gets the controller state at whatever rate suits you and fires an event when it detects changes (I'd say the event args would contain the new state). I don't have specific advice to offer there, however, as I haven't explore that particular aspect of WinRT components.


    Kraig

    Author, Programming Windows 8 Apps with HTML, CSS, and JavaScript, a free ebook from Microsoft Press

    Thursday, April 25, 2013 6:01 PM
  • Thanks for the reply Kraig. 

    Would it be fair to conclude that MS doesn't really expect these JS apps to be interfaced with controllers? 

    Or do you think app devs should try to support as many different input devices as possible?

    Just trying to work out if this is an area I should spend more time on or not (I really want to move on to speech recognition haha).

    Thursday, April 25, 2013 8:47 PM
  • XInput controllers are not considered an essential form of input for Windows Store apps, but something you can support if there's a scenario that works for it (like a game). The Store certification requirements only stipulate (a) touch, and (b) mouse+keyboard, so everything else is optional.

    In this case too, clearly the controller is not set up for an event-driven model via WinRT, as you have to resort to a component accessing Win32 APIs. The whole purpose of the sample is to show that this can be done, but is not there to say it must be done. So yes, focus on more essential features if a controller is not a core part of your app's experience.

    • Marked as answer by ViralBeeb Saturday, April 27, 2013 11:19 PM
    Thursday, April 25, 2013 8:53 PM