I have just started to use the NetAdvantage 2011.2. When using the new Input controls (e.g. XamMaskedInput) I noticed that although pressing Tab moves focus correctly forward through the controls, using Shift+Tab (reverse tab navigation) seems to get 'stuck' in the input controls (does not occur in the equivalent editor controls). Is this problem due to the way I'm using them, or a limitation of the Input controls?
This can be easily seen in the xamFeatureBroswer app (xamInputs section examples).
Hello cassellm,
When hitting the Shift and Tab keys staying focus on the XamMaskedInput may be part of the design. In the help documentation contains information for the usage: http://help.infragistics.com/NetAdvantage/WPF/2011.2/CLR4.0/?page=xamMaskedInput.html. As for flexibility the control contains the KeyDown event. In this event handler you should be able to add a condition to check whether the shift + tab key has been pressed and then change it's focus.
Let me know if you have any questions with this matter. Thank you.
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?
Hi Duane,
Sorry, due to my lack of clarity you have misunderstood my question.
Infragistics has two sets of controls for data input/presentation controls, XamInputs and XamEditors (http://blogs.infragistics.com/blogs/damyan_petev/archive/2011/11/10/xaminputs-and-xameditors.aspx). I had assumed that the XamInput controls were being developed with a view to replace the XamEditor controls, creating cross-platform controls. I am writing a new application using your latest version of WPF NetAdvantage, and am deciding which of the controls to use (e.g. use xamMaskedInput or xamMaskedEditor). My question was whch of the control sets do you advise using for a new WPF app? My main concern was that the xamEditors are being retired, and replaced with the cross platform xamInputs (currently only in Silverlight that that I'm aware of at present...is this correct?). At what point, if at all, will the other xamEditors be retired?
Hello Matt,
When running cross-platform controls would be good since the consistency is kept when moving from Silverlight to WPF and vice versa. For any features that were used in the previous control such as xamEditors and have not been included to the xamInput controls may be considered to keep both controls. Depending on what you are wanting to accomplish would be a good indication of which control to use.
As far as retirement is concerned you can find in this section here: http://blogs.infragistics.com/blogs/jason_beres/archive/2011/11/10/important-product-changes-and-control-retirements-in-2011-2.aspx.
Shift + Tab is still broken in the 12.1 release.
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.
The fix is now available in the latest service release download at My Keys & Downloads.
Thanks :)
gbjorgan said: Well, I figured out a workaround but I'd still like to see Shift + Tab work like every other control.
Well, I figured out a workaround but I'd still like to see Shift + Tab work like every other control.
For this issue has been resolved with development #90155 and the fix will be included in the next service release. You can find case CAS-97232-M8MHV5 at the support activity page.