I have a UserControl containing a TextEdit and a CheckEdit; a row of these UCs are presented next to each other. TAB flow ist TextEdit to CheckEdit and then on to the next UC – but it wouldn’t make any difference if it was the other way round. Desired behaviour would be: if in TextEdit editor, on TAB key move to next UC’s TextEdit and into edit mode instead of focusing the CheckEdit – this would require the user to use two TABs to get to the next TextEdit to continue entering data. At least that is the expected flow of things my users would most likely do with that control.

To make things more complicated, we might be faced with both a simple TAB and a combined SHIFT-TAB, if we disregard CTRL and ALT as not relevant to our movement scenario. We would expect TAB to move on to the next control to the right, and the SHIFT-TAB to move on to previous control to the left.

First check the state of the keys pressed (I use a class to wrap the tab key status that is easier to handle and may be enriched in the future):

var key = new TabKey
{
	IsTab = (Keyboard.GetKeyStates(Key.Tab) & KeyStates.Down) > 0,
	IsShift = (Keyboard.Modifiers & ModifierKeys.Shift) > 0,
	IsControl = (Keyboard.Modifiers & ModifierKeys.Control) > 0
};

Keyboard, Key, KeyStates and ModifierKeys are available from System.Windows.Input.

To propagate another TAB or SHIFT-TAB we could use something like SendKeys. But there is also a mechanism for setting focus:

var keyboardFocus = Keyboard.FocusedElement as UIElement;
if (keyboardFocus != null)
{
	var tRequest = key.IsShift ?
		new TraversalRequest(FocusNavigationDirection.Previous) :
		new TraversalRequest(FocusNavigationDirection.Next);
	Dispatcher.BeginInvoke(new Action(() => keyboardFocus.MoveFocus(tRequest)));
}

Once we got the element that currently has the focus we may move on in both directions (FocusNavigationDirection would provide some more). By invoking this action more than once, we might move on more steps like multiply pressing TAB would do.