I read on MSDN and other websites (http://msdn.microsoft.com/en-us/library/ms751797.aspx and http://www.abhishekshukla.com/wpf/advanced-wpf-part-5-of-5-interop-in-windows-presentation-foundation/) that multilevel hybrid nesting of WPF and WinForms controls is not supported...
I have an application where a WPF window has a WindowsFormsHost where inside that a WPF control is hosted in an ElementHost. This WPF control contains other WinForms controls which are also in WinFormsHost.
In short: WPF -> WinForms -> WPF -> WinForms.
So far I did not have any problems with that. After finding that small note on the MSDN page I'm wondering what exactly is not supported on that scenario, since it works for me.
Any ideas?
I would say the sense of "not supported" is "at your own risk". Most things will work, some things will not work, and it depends on your particular application whether the results will be acceptable. Or maybe you'll achieve results that are acceptable after some hacky workarounds are in place. MS aren't going to go out of there way to make it work.
I've worked with a project which contained a WinForms-WPF-WinForms nesting, and in general that worked - well enough to not rewrite the WinForms component. Focus is an issue - the nested control does not behave quite as you'd expect relating to focus gained/lost events, and keyboard focus can get stuck in the nested control. There may be a difference between whether the host element thinks it has focus and whether the contained control does. So I'd suggest focusing your testing around user input events and focus.
Related
Or what control/method I should be using to achieve the same?
I've just started transitioning from Winforms over to WPF and I tried googling as well as search on SO for the same question but to no avail. So I'm guessing it has to do more with the fact that WPF has a different method of approach entirely. I tried looking at DockPanel but I'm still quite unsure how to handle the menus/orientations and especially user-interations to reposition said menus and toolbars.
I know there are a lot of ways to achieve the same thing in WPF. But even so, what's the standard method for handling Menus like how a toolstripcontainer does?
There's no out-of-the-box control equivalent for ToolStripContainer in WPF.
But there are lots of commercial controls such as Telerik RadToolBar or DevExpress DXBars. Click the links to see their preview.
Commercial controls for WPF are mature for years so they are worth to buy.
I am looking at the possibility to host a WPF control inside a Winforms application. The reason for this is some animations inside the WinForms application. WPF should be able to support this way better because it (mostly) uses the graphic card to render instead of the CPU.
Now my question:
Are there any cons of hosting a WPF Control inside a Winforms application? Does the WPF Control still use the graphic card for the rendering or does it loose some of its advantages?
Thanks for your help. If you have any inputs or tips feel free to tell me.
EDIT
I found a similar question (but maybe that one is a bit more general, I focus more on the rendering):
Any disadvantage to using an ElementHost to host a WPF UserControl in a Winform application?
Mainly it behaves very like in a normal WPF Application.
But sometimes there are little unexpected behaviors. And it should use the hardware rendering if it would be using in normal wpf applications (depending on your configuration)
Sometimes i had problems with correctly recevien some keyboard keys in events. but there are a lot of artikels descriping the problems and solutions.
For example with some controls you could have problems catching keys. So you should have a look at System.Windows.Forms.Integration.ElementHost.EnableModelessKeyboardInterop
-> also see this blogpost
My requirement is to create a winform with contains a datagrid that allows rows to expand and show additional details. I'm considering using a WPF control and incorporate a WPF Datagrid in it to handle this, taking advantage of the RowDetails property of the DataGrid to handle the expansion of rows.
I'm completely new to WPF and the RowDetails property of Datagrid and so am only reading up on them now. Is it possible for me to use this control in my winform once I develop it? What issues may I face when trying to integrate the WPF control in my winform.
I have on multiple occasions used a WPF control on a WinForm. However, the only way I ever do it is to host it inside an ElementHost control. Once there I haven't noticed any major issues, though I do hear performance can be suspect depending on the usage.
As the two previous Answers state you have to use an ElementHost.
Here there is a comparison on how to host WPF in Winforms and Winforms in WPF. It was good for me to read the comparison when I was starting to work with it.
In this article the author links you to Gotchas For Working With Windows Forms/WPF Interop that has some common issues you can run into.
Build your WPF control like it was a Vendor control, with a clear interface and then just host it with the ElementHost. I have had to use it both ways but with legacy controls, and it really helps if you have a good interface in the control that you bring from the other platform, if not it can be a bit messy.
I've a question more about 'Good Programming Practices'.
I have just started a really big project. I'm using WebGui (long story short.. it is WinForms in web) - but it's not important.
I'm creating milions of forms with milions of controls like TextBox, NumericUpDown, DateTimePicker and etc. It might happen, that I will have to change something in behavior of DateTimePicker or appearance. It will be impossible to change it in every control. I want my project to be flexible so I've got an idea..
I do separate custom controls for every type - string, numeric, date, byte.. and within I will put TextBox for example. And on every form I will put not TextBox, but MyTextBox. In fact, that MyTextBox will be just TextBox, but when I change something there, every control will be changed.
Is it good, popular pracitce in programming?
in the case of WPF this can be achieved quite easily using Styles and Templates.
in Winforms this is not possible, therefore I'd say your approach of deriving from the controls and using your own custom controls on the UI is a good practical approach which helps managing changes centrally.
If the controls were created manually in the programme, alternatively you could use a Factory clase(s) and get the Factories to create the controller object rather than just newing up.
But this might not be possible when the UI is created by dragging and dropping controls as the developer has no control over the creation of controls.
Which ever the approach you choose, the fundamental goal should be to centralize the creation logic of the controlls.
Yes, this is perfectly normal programming practice for GUI development, if the standard controls don't satisfy your requirements.
Most developers get 3rd party control suites for the extra flexibility. The benefits in buying far out weigh the benefits in building core controls yourself.
I've worked at a place that did companyTextBox, companyDatePicker and it worked ok. A couple of controls got revamped over .Net versions so these base classed controls required some surgery. Any depreciated controls were left as framework version dependent.
For special things, I do a lot of research into good custom controls on CodeProject, CodePlex, Code.Google.com,etc and implement them into the project I'm working on.
Otherwise use the stock standard controls or the suite of 3rd party controls the company I'm working for use.
My advice is to get a 3rd party suite of controls and make a ton of re-usable user controls based on the 3rd party ones. This way you can build most of the 200 forms by Drag and Dropping the user controls onto the forms. Make each User-Control Implement an Interface with Create,Retrieve,Update & Delete methods for the forms to generically work with your user controls.
WPF WebBrowser control looks great but knowledge accumlated over time about WinForms WebBrowser is substantial and it's hard to ignore work like csExWB. It would be nice to know what functional shortcomings or advantages exists in .NET 3.5's WPF WebBrowser control over WinForms WebBrowser control. In particular, is it possible to build csExWB-like functionality on top of WPF WebBrowser?
From one full day of frustration with wpf's component, here's what I discovered. Apparently, winforms webbrowser exposes much more methods and properties. For instance, there's no IsWebBrowserContextMenuEnabled, ActiveXInstance, etc. in wpf webbrowser.
Also, the document property of each contains different types of objects. Winform contains a document of type System.Windows.Forms.HtmlDocument with a few interesting methods and properties like PointToClient and GetElementFromPoint. Wpf webbrowser document is an Object type document that can be cast to mshtml.HtmlDocument, which only provides the same methods and properties available from a standard html + javascript document. Not very exciting. I don't know if it can be cast to something else (useful that is) since there's no real documentation about it.
The only disadvantage I could notice about winforms webbrowser is that the buttons and scrollbars inside the component don't have the same appearance as the wpf native controls.
I must admit I don't know the differences, but if you hit problems you could perhaps use WindowsFormsHost to host the winform version in WPF, like so? Ultimately, both is a wrapper around shdocvw, so principles like "pure WPF" don't really apply.