I've just discovered recently the source of a problem that has been occurring within an application that I've been working on that uses traditional WinForms MDI with WPF UserControls hosted within ElementHosts for each form. The problem is that if the user changes the text in a TextBox that is TwoWay bound to a ViewModel property that the setter on the property is not set when clicking on the Save button in the toolbar. The consequence of this behavior is that the last text setting that was set is not being saved.
I'm using the default UpdateSourceTrigger value of LostFocus so I believe what is happening is that the the WPF TextBox element is not loosing focus when I click on the WinForms based Save button in the toolbar. So now that I understand the issue I'm curious what the correct or best way is to solve this problem.
The two main options that I can think of either require manual prompting to update the setter without causing the control to loose focus or just make the TextBox loose focus so that the normal source updating occurs.
You can change UpdateSourceTrigger to PropertyChanged, then the "Save" button will work nicely.
I think your reasoning is correct. WPF and Winforms have both seperate "Focusmanagers", so if you go from WPF TextBox to winforms button, then focus has nowhere to go.
Related
I have a win forms application on which an WPF UserControl is hosted using ElementHost. When user changes the text of textbox inside WPF user control and click on any Win forms control it does not update the binded property of the ViewModel.
It is not possible to change the UpdateSourceTrigger to PropertyChanged because for each change in ViewModel I need to add an undo entry. I have read some articles saying that win forms and wpf have their own focus contexts which are not shared. Anyone has found any workaround for this ?
Thanks
Sameera
I am deriving a custom control from StackPanel (or just using the usual UserControl class). This control should be focusable within the application by either tabbing or clicking the control. When focus occurs, based on other criterion the control will expand and show certain elements. The control will also choose a default child control to focus on.
The issue I have is that I can find no way to focus on a UserControl. The Got/LostFocus events don't fire when I click on the control.
I am aware of the Focusable property, but it doesn't seem to be available on any of the client dlls for Silverlight (using v4 of SDK)
What I would really like is some advice on how best achieve the functionality of a panel I can tab to, as the UI design I have in mind hangs on this.
I guess the control you are looking for, is an Accordion or Expander control.
Here, you will find steps to use the Accordion control. Hope that helps.
I have a WPF app that uses MVVM Light and I wish to both execute a command on the view model and change the keyboard focus to a specific control when the user presses ALT+SHIFT+C.
Is it possible to achieve this in an elegant way?
It depends on how the shortcut key is created (if it's like Visual Studio or more like Windows - it means if you have to hold only ALT or all the keys).
But whatever the logic, You will have to first bind an Event to a Command (it might be the event keydown of one of your controls).
In MVVM Light, you will have to use Interaction.Triggers with EventToCommand (there's a lot ot explanations on google and SO)
The logic would be put here in you command.
Then a dependecy property as show here could be implemented for getting the focus.
When tabbing through controls in an ActiveX control hosted in IE, once I get to the last control the tab key no longer does anything. I would like it to move the focus outside the ActiveX control to the next html control.
This works fine when the ActiveX control is hosted in a WinForms app, does anybody know how to make this work in the browser?
It may also be relevant that the ActiveX control is a simple wrapper around a WPF control.
I found a hacky solution.
The problem is tabbing out of the WPF control, so I've placed a hidden textbox after the ElementHost within the ActiveX control. Tabbing out of the WPF control moves focus to the hidden control correctly, which upon receiving focus uses SendKeys("{TAB}".
Just typing SendKeys makes me feel a little dirty though, so if anyone has a better solution...
I'm adding C# WPF dialogs to an existing C++ MFC app, using a C++/CLI interface layer. I've got things working, except I'm having a problem with modality. For example:
MFC app shows a WPF dialog using ShowDialog. Works as expected.
That WPF dialog shows a MFC dialog using DoModal. The WPF dialog is hidden behind the base C++ app, and is not disabled unless I manually change IsEnabled. Not ideal, but it works.
Now, that MFC dialog is closed. Now for some reason the base MFC app is enabled, when it should still be disabled due to the WPF dialog not having been closed. That's bad, as it now allows the user to do crazy things while the WPF dialog is still open.
I have a feeling that it would work better if I could set parent dialogs correctly. But so far I havent been able to set an MFC dialog's parent as a WPF dialog, or vice versa. And, I don't even know if that'd fix it.
Any ideas?
When opening a CDialog, the trick is to use a WindowsInteropHelper to get the parent WPF dialog's HWND. Then, you can use CWnd::Attach to wrap that HWND in a CWnd class to pass to the CDialog's constructor.
The problem I had was that I already had the CDialog constructed., but not yet displayed. The various versions of SetParent can only be used if your target child window already has a valid handle. I had to write a new function in my CDialog class to set m_wndParent, which is what it uses as the parent when it finally creates the dialog. Then everything works great!
Somehow creating WPF dialogs from MFC dialogs "just works". It's magic.
When showing the WPF dialog, are you using the HwndSource class to wrap the WPF window? If so, you may be able to ::SetParent the WPF window as well as use the HwndSource.Handle property to set the sub-child's parent.