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
Related
I am currenlty developing a plugin for an existing 3rd part system. The plugin exposes a GUI, which is defined to be WPF by the plugin framework. However, i have to integrate a legacy WinForms control that is hidden in a library (no source code available).
Using WinFormsHost works great, as long as the Display scaling is set to 100%. If the settings are different, my embedded WinForms control scales awkward and doesn't look good anymore.
If I create a WinForms Window and embed the control, scaling is fine.
If I create the same window from a WPF application / Window and push the WinForms window into the WPF window with HwndHost, scaling is awkward again.
It seems that scaling is only correct when i start my WinForms window in a separate process outside the 'WPF' environment.
I should be able to catch the separate process' window and get proper scaling, but communication into my legacy window may become tricky then.
Is there a way to get proper scaling without the detour via a separate process? I know that similar questions have been posted here, but so far i did not find what i was looking for.
Thanks in advance.
I have successfully made a personal mini browser app in c# winforms.
Because I want some more fancy effects, I was considering to make a WPF app. So I tried the wiki tutorial and set up a simple WPF form with a browser, but noticed it has sluggish performance. It's even noticeable when selecting text in very simple webpage, or just when scrolling the page. Is there anything that can be done? If not, I guess it will be just winforms then, since that one behaves and performs well.
edit: my specs: http://users.telenet.be/dropbox/specs.html
WPF version of cefsharp uses different model of rendering than WinForms. In WPF it basically copies each frame into bitmap and you might imagine how slow it can become. This is especially noticeable on high-resolution screens. There are some options to improve that perfomance (see here for example), but in my experience (I tried all that options) non of them really helps to match WinForms. To run cefsharp smoothly in my WPF project I actually had to use WinForms version of cefsharp and host it inside WindowsFormsHost - this helps with perfomance problems but has it's caveats of course (for example you cannot partially hide WinForms hosted control behind WPF controls - it will always be rendered on top of everything). Still for now I consider this the only viable option, because high-resolution screens are now quite widespead.
This will disable WebGL, look at the source to determine which flags best suite your requirements. "grMain" is a Grid in Wpf
CefSettings s = new CefSettings();
s.SetOffScreenRenderingBestPerformanceArgs();
Cef.Initialize(s);
ChromiumWebBrowser wbMain = new ChromiumWebBrowser();
grMain.Children.Add(wbMain);
I'm currently working on moving out kiosk software that runs Awesomium away and instead onto CefSharp.
Our main application is written in WPF and this work is using v45 of CefSharp
I'm aware that the WPF control has some serious performance issues, when compared side-by-side with the WinForms version hosted in a WindowsFormsHost, the smoothness of transitions etc is MUCH better.
To that end I'm looking to stick with this approach of embedding the WinForms ChromiumWebBrowser inside a WindowsFormsHost on the WPF window. This all works and however I'm having issues with getting touch support to work.
Our kiosks have touch screens and run Windows 7 / 8.1, the touch works flawlessly with the WPF control, however when using the WinForms embedded one touch doesn't work at-all.
As well as touch not working it also steals all Keyboard events and consumes them internally it seems, as none of my event handlers ever fire on the main WPF window.
If anyone has any ideas or can point me in the correct direction to try and solve this it would be hugely appreciated!
Thanks
The scenario your talking about is not well supported and as such there is not a lot of information. A lot of the problem your are seeing are likely because CEF is running it's message loop in a separate thread. If you turn MultiThreadedMessageLoop off, then you become responsible for calling Cef.DoMessageLoopWork(). I recently added a rough demo the WinForms Example. You can likely port this to WPF, though I've never tried.
https://github.com/cefsharp/CefSharp/blob/cefsharp/45/CefSharp.Example/CefExample.cs#L76
https://github.com/cefsharp/CefSharp/blob/cefsharp/45/CefSharp.WinForms.Example/Program.cs#L37
You are in somewhat uncharted territory there, so you'll have to do most of the leg work yourself.
For reference there are some ways to improve the WPF performance. They come with their own set of drawbacks though. See https://github.com/cefsharp/CefSharp/blob/cefsharp/45/CefSharp.Example/CefExample.cs#L58
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 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.