The gyroscope will add new types of gameplay to the games. The gyroscope has long been used on PS3, PS4, Wii, Wii U and other gaming systems. It's time to add it to the XInput standard.

It would also be cool to make a new gamepad with a gyroscope.

A few examples of using a gyroscope in games.

1. First person shooter, Third person shooter.

In shooting, the gyroscope can be used for more accurate aiming during shooting, for reloading, repelling an enemy, driving a vehicle, for balance when overcoming obstacles and so on. Wishes for developers: optional use of the gyroscope and changing its sensitivity.

2. Race.

Gyroscope will allow using the gamepad as a steering wheel. Wishes for developers: optional use of the gyroscope and changing its sensitivity.

3. Platformers.

The gyroscope can be used for jumping, with varying strength, for rotating platforms and so on.

As an example say there is a ListBox. The ListBox is full of ListBoxItems which each contain a TextBox. The objective is to support copy/paste of ListBoxItems themselves. However, because each TextBox within the list also has copy/paste, the Keyboard Accelerator is invoked whenever you copy/paste text in the TextBox itself. This breaks the ability to copy/paste ListBoxItems and ScopeOwner is unable to help you in this case.

It seems TextBox does not use Keyboard Accelerators and therefore does not set Handled=true. Therefore, in order to handle this situation you must add OriginalSource to the KeyboardAcceleratorInvokedEventArgs. It is the only way to cleanly implement this case.

Otherwise, there is no way to determine where it is bubbling from and if the TextBox should handle the event. To work around this I'm forced back to manually checking keyup/down events and OriginalSource is supported for those.

Hi
I am looking after a solution already over a decade for 3D mouses working over Windows Remote Desktop Connection. Still today 3D mouses USB-connected to the local computer and used over a remote desktop connection to external server are not working properly. On the field, there are hundreds of CAD, industrial designers and other engineers still not able to use a 3D mouse on the remote server over Microsoft RDC. Normal mouses are working fine, but 3D mouse such a SpaceNavigator from 3D Connexion is only able to zoom over RDC.

I would like to ask Microsoft Developers to fix this issue and provide couple extra degrees of freedom going through the RDC. Other competitors such as Citrix and HP have already solved this issue with their own Remote Desktop clients.

It would help a lot of companies to invest in cloud systems, especially when small lag 5G-connections are soon here and develop new businesses.

Thank you.

Ismo Talka
Ericsson

Hi! As a long time WP7/8 and now W10M user, I noticed inconsistent behavior of opening flyout with touch versus mouse.
With mouse, flyout opens on right click which is ok. But when using touch gesture, I would expect behavior known from WP7/8 - flyout (aka context menu) should open after couple miliseconds while my finger is still touching the given item. Instead in W10M it opens just when I release the finger. This is very annoying as I never know if there is some additional menu under the item or not.

In the end, developers have to use some workarounds to simulate old behavior. You can see that even Apps list in W10M simulates old behavior instead of default one. Context menu appears while my finger is still touching the screen.

According to the documentation the proper way to handle input in a store app is to create a CoreIndependentInputSource from another thread by calling swapChainPanel.CreateCoreIndependentInputSource(). This gives you low latency input in case of a busy UI thread.

Once you create a CoreIndependentInputSource, touch visual feedback is visible again. Even if you disabled it using
auto pointerVisualizationSettings = Windows::UI::Input::PointerVisualizationSettings::GetForCurrentView();
pointerVisualizationSettings->IsContactFeedbackEnabled = false;
pointerVisualizationSettings->IsBarrelButtonFeedbackEnabled = false;
It's not about aesthetics, Visualfeedback kills performance, the framerate in games drops by half, which is ironic if you think that's the kind of apps CoreIndependentInputSource was created for in the first place. Devices with touch input are the ones that suffer the most from this bug since they come with weak GPUs. Devs have to chose either low responsiveness or low performance.

CoreIndependentInputSource has it's own Dispatcher, does that mean it has it's own HWND/message queue?
Maybe that's the cause of the bug, PointerVisualizationSettings.GetForCurrentView() is tied to the main Window.
If you try to call "PointerVisualizationSettings.GetForCurrentView().IsContactFeedbackEnabled = false;" from the input thread it fails with an exception.

I got the _hWnd from CoreIndependentInputSource.Dispacher using the VS debug inspector and then called TryDisableWindowsVisualFeedback() as seen here http://stackoverflow.com/questions/27550373/disable-touch-visual-feedback-on-windows-8-1-programmatically-desktop-app
The visual feedback was disabled!
However, live code has no access to that hWnd. All helpful Win32 apis fail one way or another (GetActiveWindow(), GetProccessId(), EnumWindows(), etc).

Why do you always have to make a developer's life difficult.
There's no easy way to detect Left Control key pushes.

Because on international keyboards, if Right Alt is pressed, then Left Control is also pressed? Why oh why, this is the stupidest thing ever.

I thought when designing a new API you could get rid of all the ******** and just make things clean and simple.

So I've developed a work around, to detect key pushes for LeftCtrl and RightAlt, and if both are pressed at the same time, then LeftCtrl pushes are ignored.

void OnKeyDown(CoreWindow^ sender, KeyEventArgs^ args) // mouse buttons are not passed here
{
KB_KEY key=KB_KEY(args->VirtualKey);
switch(key)
{
case KB_CTRL: if(!args->KeyStatus.IsExtendedKey){Kb._special++; return;} break; // because this can be triggered by pressing RightAlt too, we need to record this event, and if RightAlt is pressed in the same frame, than cancel this, there's no other way, because holding RightAlt results in 'GetKeyState' being on for left ctrl too
case KB_ALT : if( args->KeyStatus.IsExtendedKey) Kb._special--; break;

And later I check if(Kb._special>0)

But that doesn't work too, because now it turns out, that if I press just RightAlt, then I can get callbacks for LeftCtrl and RightAlt happening in different frames.

OnKeyDown with LeftCtrl gets called in frame 10
OnKeyDown with RightAlt gets called in frame 11

Why can't you just make it easy and get rid of AltGr altogether.

Waiting for reply.