I have a WPF Textbox, that I want to check that the text value is correct before I allow it to lose keyboard/focus.
I have tried setting e.Handled in the InputBox_LostFocus & InputBox_LostKeyboardFocus events, but it doesnt seem to be achieving what I want.
Any suggestions on how I can lock focus to a Textbox?
The best way to do this is to handle the PreviewLostKeyboardFocus event which is fired while the event is tunneling down to your textbox. Set handle to true and nothing else will receive the notification (meaning focus will not be transfered away from your textbox). Hope this helps.
You can call Mouse.Capture on a UIElement. This will then give you every mouse event that hapens whether on the element or not. but its tricky to use. You can capture the mouse on your text box and register for lost capture events, when you lose capture you can recapture. you have to watch out for strange behaviors. Generally its bad practice (I think) to not allow a user to move off a field. what is better is to allow them to do whatever they want, but disable the button that they push after entering data until all fields are valid (or something similar)
Here are some links
other SO question
msdn sample code
the combo box uses mouse capture to tell if the user has clicked elsewhere in the app to close the combo box if its open if you click on another control (or outside the window)
I dont know if this technique will stop you tabbing off the element. there are two kinds of focus in a wpf app. You have logical focus and keyboard focus. Multiple elements can have logical focus at once (each within a focus scope). think for example a textbox can have logical focus while you are clicking a menu (which has logical focus as well). Keyboard focus can only be in one place at a time. You are going to make a lot of work for yourself. I would seriously consider if you are doing your interaction in the right way. You could spend days getting this interaction correct. If you stop your textbox losing focus, what happens if the user clicks the close button?
heres the msdn article on focus
Related
Is there a way to make an entire WPF Window inert after a button click?
The window is invoked via Window.ShowDialog() and after use, the window is no longer needed for interaction but I leave it open to remind the user of the inputs in TextBox's, ListBox's, and give visual feedback via OxyPlot and so on. I leave it to the user to close the window manually.
One solution is to disable all buttons but that's tedious and it still leaves TextBox's functioning. That's not optimal because for anything to be functioning creates the wrong impression that the Window remains for anything other than looking at. It would be better for every control to be non-functioning by a single setting.
I did it by putting a name on the WPF window code behind and then setting .IsEnabled false upon the appropriate button click. All buttons, combo boxes, text boxes, and even OxyPlot became inert at that point and most parts were greyed out.
Consider creating a dedicated boolean dependency property in your code-behind or viewmodel and binding IsEnabled of every TextBox to the property.
Literally, I want to know that.
In some case, .Focus() appear better than SetFocusedElement(). But another case, it's reversal. So I must know what's different things are there.
Additionally, by MSDN, .Focus() is for keyboard focus, and SetFocusedElement is for logical focus. But I can't feel different thing between logical focus and keyboard focus.
The keyboard focus is generally easier to understand, as that is effectively the control that would receive keyboard input if the user typed. So if you click in a TextBox it will receive keyboard focus and you can start typing. Other controls have other behaviors and may not really support the keyboard, but they can still get the keyboard focus.
For logical focus, your application can be made up of several parts. For example, most applications would have a ToolBar/Ribbon at the top and then their main content below. Now, imagine that your content is a TextBox that currently has the keyboard focus. When you click in a ToolBar/Ribbon control, the keyboard focus is moved to that control. But you really want to "remember" that the TextBox in your content had the keyboard focus before.
To achieve this the ToolBar/Ribbon will create new "focus scope". So when you click in the ToolBar/Ribbon control, you move the keyboard focus but the TextBox still has the logical focus for the window. That allows the TextBox to be given the keyboard focus back when the user is done working with the ToolBar/Ribbon.
The same holds true if you interact with another application, as your application doesn't have the keyboard focus. When you go back to working in your application, it uses the logical focus to know who had keyboard focus last (and should have it restored).
Using FocusManager.SetFocusedElement(), you can specify a UserControl of which you want to set focus on an element. So you can set focus on a control that is in a different part of your program.
Control.Focus() is just straightforward, you set focus on the said control (which is more intuitive).
Wild guess: you use FocusManager.SetFocusedElement() improperly, resulting in unwanted behaviors but bottom line, it's the same thing really.
Sidenote: "logical" focus and "keyboard" focus are 2 different things in WPF.
I want to display a custom confirmation message box (ChildWindow) when the user selects a row in a DataGrid in Silverlight. The message box simply has 2 buttons, a yes and a no. When the user clicks No, I want to restore the previously selected item in the DataGrid. I have been able to accomplish all of that.
The problem is that when the message box appears and I click NO and I restore the previously selected item, the item that the user tried to select remains in the MouseOver visual state until I move the mouse over some other row.
Is there any known workaround for this unusual behaviour of the DataGrid, or is this perhaps a legitimate bug in the control? I have done my research and I have not found anything as yet.
Any help would be appreciated.
Thanks!
This is classic mouse enter/leave gotcha thats common in many areas of Silverlight and indeed in many other frameworks as well. The assumption is that that mouse in and out events will come in pairs but they don't when a something else hijacks the mouse events.
Thats is what is happening here the DataGridRow is simplisticly tracking mouse over using the standard mouse events. However when you show a child window while it is in the mouse over state not further mouse events go to the row. When you dismiss the childwindow the mouse is already outside the row so it still gets no events.
A possible workaround is to fiddle with the visual state of the row yourself before showing the child window:-
VisualStateManager.GotoState(someRow, "NormalSelected", false);
Not perfect but possible good enough.
I am working on a silverlight application with a significant number of invisible tab stops.
I am currently busy trying to track them all down and eliminate them.
I am aware that any control that inherits from System.Windows.Controls.Control can take focus and yet I still can't identify where the focus is be going for much of the time when I press tab to move round the UI.
So, my questions are:
Will everything that acts as a tab-stop also take focus (and visa versa)?
What, apart from anything that inherits from Control, can act as a tab-stop?
There is little point in something being a tab-stop if doesn't "also take focus". However not everything that can take focus need be a tab-stop, for example, a control may take the focus when clicked on by the mouse but not via the tab key.
In Silverlight there is nothing that can act as a tab stop that is not also a Control.
The Control class has a IsTabStop property which by default is true. If you have been building your own controls its up to you to build visual states to indicate that the control has the focus. If your control doesn't need the focus for any reason then clear its IsTabStop property early in its constructor.
I am working a WPF application, where I have maintained a Menu Bar with Input Gestures i.e keyboard Shortcuts.
For Save As menu item, I have kept Ctrl+A as per User's requirement. It works fine as far as the focus is on the main window.
Now my problem is, suppose use has navigated in some Listbox in window, and if he presses Ctrl+A, then Select All functionality takes places for the list box and Save As dialog box does not get called (as i have done the command binding for this input gesture)
Any idea how can I avoid this? and yes, I can not change my input gesture. It has to be Ctrl+A. :)
Thanks
I think you could change the command bindings on the list box object to remove the binding for the command. Look at the ListBox.CommandBindings list.
You could also turn off Focusable on the ListBox so that it never receives keyboard commands.
You could also check out the eventing model. You could probably catch the keydown as the preview events "bubble up" from the root of the logical tree and then they are passed down from the end element down. They can be marked as handled on the way up or the way back down.