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.
Related
I have a WPF RichTextBox in my application that sits in Grid. It gets updated every second or two as it displays logs (though sometimes there are no logs for up to a minute depending on the load).
The grid is not always visible, as it sits in its own tab. If the user is on another tab, the logger is not visible.
My problem is that I want the RichTextBox to scroll to the end every time a new paragraph is added. It seemed simple as there is a 'ScrollToEnd' method on the RichTextBox control and so I call that method every time text is added to the control.
The problem is that that method only works if the control is visible, if the user is on another tab, the RichTextBox will not scroll to the end and it looks weird when you click on the tab with the logger and after a couple of seconds or longer it scrolls to the bottom when it should already be at the bottom.
Is there a way around this annoying "feature" of the control? I would like to ALWAYS have the RichTextBox be at the bottom unless the user is manually taking control of the scroll bar.
Thanks!
By default, the TabControl actually doesn't change its contents visibility, it removes them from the view completely when you change tabs and then "re-attachs" them when you navigate back to the previous tab.
That's why the Visibility change doesn't get fired. Instead, you should handle the Loaded event, which should get fired right before the view is re-rendered.
Is there a reason you cannot simply call ScrollToEnd in response to the text box becoming visible? That seems like the simplest approach. Did you try it and run into an issue?
Edit: If you are using a TabControl, each TabItem has an IsSelected property you can bind to from the ItemContainerStyle. You could probably scroll your text box in response to the tab becoming selected.
As a separate note: if you are planning to make a custom control for this, here are some things to consider.
I wrote an auto-scrolling version of a FlowDocumentScrollViewer. (I never needed a RichTextBox specifically, but they display similar content.) I can tell you that there are a lot of things to account for, such as knowing when and when not to auto-scroll based on what the user is currently doing.
For example:
If the user takes over the scrolling themselves via the scrollbar or mousewheel, you don't want the control to fight with them.
If they start selecting text, you don't want to scroll it away from them mid selection.
If they scroll to the bottom, you probably want it to start auto-scrolling again.
Also, determining what the user is doing to begin with can sometimes be a complex process on its own.
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 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
Using WPF how can I do similar thing as done in Skype contacts window? I want to be able to press on any list item with mouse, be able to use Up/Down to navigate and filter contacts when I start typing. I also want to show what I'm typing in separated TextBox.
So far I have all filtering set up through TextBox. I can navigate with arrows when TreeView is focused and filter when entering text inside TextBox.
You might be interested in the PreviewXXXX functions, which lets you catch key presses before they get to the listbox.
I don't have skype, but I think you'll have to catch those up/down keys from the keyboard and send them to your treeview if I understand your question well.
... or perhaps this link helps!