I'm trying to integrate XNA into a WPF window, using the WindowsFormsHost control in the WPF window. I've got a very strange problem that whenever XNA is running, my keyboard input into my WPF window controls don't work. More weirdly, this is happening not for all keys. It happens for all the letters and numbers, but, for example, backspace or delete key work. I first thought this was due to XNA hooking up to the keyboard input and handling all the key presses, and the events weren't being routed to my WPF window. But weirdly, they DO get handled by the OnKeyDown. I've created a custom TextBox class that derives from normal TextBox, overrided the OnKeyDown, put a breakpoint in, and it worked. The debugger stepped on the breakpoint. So I was wrong: XNA wasn't blocking the key events from reaching the WPF window (or its controls), my TextBox IS getting the correct keyboard event, but it just doesn't work. I press 'A' on my keyboard, OnKeyDown gets called, but it doesn't append 'A' into the textbox. The backspace key, on the other hand, works normally. I copy paste some text into the field using mouse right click, and I click on the middle of the text (arrows don't work too), I can delete the text by pressing backspace, but I can't type anything.
What can be the reason? I am not really good with WPF's input handling, but normally, if my TextBox DOES get the OnKeyDown event (with the right argument), it should append the letter that I've pressed. As soon as I end the XNA game, things start behaving correctly. What can be the reason for the controls behaving abnormally?
Someone else has ran into the same problem here: http://forums.create.msdn.com/forums/p/98145/584961.aspx and they've found the solution to the problem (they've also linked to this question, too)
The interoperability of XNA and WPF needs a little tweak:
System.Windows.Forms.Integration.ElementHost.EnableModelessKeyboardInterop(this);
This code should be pasted to the constructor of the WPF window that will be hosting the XNA content. I've pasted it to the constructr after InitializeComponent() and it worked.
Related
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 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 have an ActiveX control inside a WinForms user control. My WinForms app loves it!
Now, moving over to WPF, I use the user control in a WindowsFormsHost control. Works great..., but I want to treat this control as a single element so the user can neatly hit TAB over the existing WPF controls AND this user control NOT to 'go inside' it. i.e. just treat it as a single control like all the others.
I think what i need is the ability to trap the keys, and in the event handler simply move focus to the next control in the sequence, but I can't seem to trap any keyboard input. Ive tried the WPF PreviewKey.. events and the like, but once the tabbing gets to the control, it seems to stay inside it and WPF events are ignored.
I couldnt find anything on this in many WPF books and the net. Can anyone suggest a way ?
Thanks,
Jack.
Can't you create some sort of a filter by doing a preview mouse down on the panel or window (whatever is the parent of your controls), this way the panel will catch it before the user control and you should set e.handled to true, and if the user control raised the tab event, keep pushing the focus until you get another control. Preview and e.Handled=ture should solve the problem.
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
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.