I am unable to see anything in the suggested document link that references this particular behaviour. As this standard keyboard navigation is supported by standard controls as well as your editor controls, do you expect this limitation/bug to be addressed in the near future?

For a WPF application (which would also be making use of the xamDataGrid) would you recomend the use of the editor controls rather than the new input controls?

Here's a quick temporary hack until this is fixed for anyone that needs it...

Register a handler in Application OnStartup (or somewhere cleaner if you'd prefer):

EventManager.RegisterClassHandler(typeof(XamMaskedInput), XamMaskedInput.KeyDownEvent, new KeyEventHandler(XamMaskedInput_KeyDown));

And here is the handler:

private void XamMaskedInput_KeyDown(object sender, KeyEventArgs e)
{
var input = (XamMaskedInput)sender;

if (e.Key == Key.Tab && Keyboard.Modifiers == ModifierKeys.Shift) {
var request = new TraversalRequest(FocusNavigationDirection.Previous);
input.MoveFocus(request);

e.Handled = true;
}

That'll take care of all the the XamMaskedInput controls in your app as well as any controls that derive from it such as XamNumericInput, etc.

Hello Glen,

This is just a follow up if you require any further assistance.

Well, I figured out a workaround but I'd still like to see Shift + Tab work like every other control.

Thanks :)