Problem with input system in Windows 8 Metro system



When I try to get the KeyboardState or MouseState in Update loop of my metro game (and more particularily in the first update call) it's generate an error.
I investigate a little bit in ANX code and I discover that the error come from the fact that the first update is done before run the CoreApplication whether the Keyboard or Mouse need the CoreApplication to run before they can get their state (CoreWindow in fact but it's linked).

I suggest you to run the gameHost (and so on, the CoreApplication) before calling the first update.

The workaround I use for now is to don't check Keyboard/Mouse on the first update and it works fine.

Closed Feb 17, 2015 at 9:47 PM by KorsarNek


wrote Feb 17, 2015 at 9:47 PM

Aufgelöst mit Changeset 32264: Fixed the creation of the swap chain for windows metro and removed the dependency of the Metro Rendersystem onto the Metro Platformsytem.
All occurrences of WindowHandles have been replaced with a custom WindowHandle type which should work out of the box in most cases, but does still represent a breaking change to XNA.
The ProjectConverter for Metro was adjusted so that with just changing the way the application is initialized, most projects that worked with ANX before should now work under win rt. The sample SimpleNoContent does now work out of the box for win rt, after a project conversion.
The application name for win rt apps is now a guid, the display name stayed the same though. That's to be more compliant with the way win rt apps are normally created.
The default namespace and namespace of the classes for the Sample "SimpleNoContent" is renamed from "SimpleModernUI" to "SimpleNoContent".
With the new way win rt apps are initialized for ANX, it's necessary to first create the WindowsGameHost for WinRT with a handler how to create the game instance and give that to the CoreApplication object to run it.
Also took care of a few annoying bugs when working with win rt and ANX where no InputDevices could be created on the first frame (Issue #1164 ) and that it wasn't possible to use the localfolder of the application on the first update and all the other stuff for which an instance of the Application class was necessary.