From MSDN article I found out that WinForm controls can be hosted in a WPF application using HwndHost.
Also, from other internet resources, I found that WPF is rendered using DirectX and WinForm is rendered using GDI+.
My question is, what renders a WinForm control when the WinForm control is drawn in a WPF application; DirectX, GDI+, or both?
I have very little experience with both technologies and making baby steps.
Thank you
You are incorrect about requiring a HwndHost to display a Windows Forms control in a WPF Application. The article that you were reading is for Win32 Interoperation, not for Windows Forms. To use a Windows Forms control in a WPF Application, you should use the WindowsFormsHost Class.
As for what will render the Windows Forms control, you need to understand something. WPF uses a totally different graphics system to Windows Forms. From the WPF Graphics Rendering Overview page on MSDN:
One of the keys to understanding the role of the Visual object is to understand the difference between immediate mode and retained mode graphics systems. A standard Win32 application based on GDI or GDI+ uses an immediate mode graphics system. This means that the application is responsible for repainting the portion of the client area that is invalidated, due to an action such as a window being resized, or an object changing its visual appearance.
In contrast, WPF uses a retained mode system. This means application objects that have a visual appearance define a set of serialized drawing data. Once the drawing data is defined, the system is responsible thereafter for responding to all repaint requests for rendering the application objects. Even at run time, you can modify or create application objects, and still rely on the system for responding to paint requests. The power in a retained mode graphics system is that drawing information is always persisted in a serialized state by the application, but rendering responsibility left to the system.
Therefore in general, the WPF Rendering system will render the WindowsFormsHost, although you may find that Windows Forms does actually perform some rendering of its own on the Windows Forms control.
You need to understand WPF and Win32 Interoperation, it show how controls are plotted.
On the other hand Technology Regions Overview explains the relationship between Wind32, WPF and DirectX.
Hope it will make you more clear about this..!!!
Related
I want to integrate two existing applications into one. One of those apps is built on Windows Forms and the other on WPF.
Is it possible to achieve this?
WPF supplies the WindowsFormsHost class that allows you to host WinForms controls inside a WPF window; conversely, WinForms supplies ElementHost that allows you to host WPF controls inside a form.
Unfortunately how well things work out is highly dependent on exactly what you are doing, last time I checked there were more than a few rough edges. For more information, definitely start from this MSDN page.
If you want to have "independent" WPF windows and WinForms forms inside the same application, you will have to make both frameworks "share" some code in your UI thread's message loop. For a primer on how to do that, see here.
There are various classes to help you with this.
For hosting Windows Forms controls in a WPF Window, you can use the WindowsFormsHost class. For hosting WPF Controls in a Windows Forms Window, you can use the ElementHost class.
You can look here for mor information on the subject (windows forms section):
http://msdn.microsoft.com/en-us/library/ms753178.aspx
I am trying to create a multitouch application.
I have the hardware which will allow me to do this. On the software side I want to be able to have WPF textboxes, WPF web browsers, multiple focuses, multiple keyboards and multiple users at the same time.
From what I've seen, I can't be focused on two controls at the same time.
What is the Microsoft MultiTouch approach for this kind of job ?
The OS limitations are what they are (and don't appear to change in Win8): only one hWnd at a time can have focus.
Since you are using WPF though, everything within your application (with the exception of the WebBrowser control ActiveX widgets you may be using) is rendered within one big hWnd.
WPF 4 introduced native support for multitouch, including multi-touch capture. The APIs for this are many but pretty intuitive so I'll just say this... go to http://msdn.microsoft.com/en-us/library/ms590078.aspx and search within the page for all of the members with "Touch" in their name.
The catch however is that the controls shipping with WPF 4 don't work with the touch input events... you'll only be able to interact with one of those controls at a time. To take advantage of the multi-touch capture APIs, you'll have to create controls that are designed with it in mind. Fortunately, the Surface team at Microsoft has you covered on that... the "Surface 2.0 SDK" includes a suite of controls (usable on any Win7 machine, not just for Surface) that were built with this stuff in mind.
To create application with MultiTouch UI, use MultiTouch Framework in .Net
Go to http://multitouchvista.codeplex.com/
I have developed a GUI for a random application using WPF. I have a bunch of out of box WPF controls laid on the application window. I haven't customized anything, didn't use bitmaps, etc.
When running my application and zooming using Magnifier application in Windows 7 (Win key + Plus key, the magnified GUI is showing pixels.I am probably wrong, because I can't explain it otherwise, but isn't WPF supposed to provide vector like control rendering?
Thanks for participating in the discussion.
Bonus Reading
Tim Sneath: Magnifier: An Interesting Discovery (archive)
WPF Vector based interface *(screenshot of WPF being vector scaled by Magnifier)
MSDN Blogs: Greg Schechter explains why it longer happens (archive)
Back when Vista first shipped, and when WPF was on version 3.0, zooming with the built-in magnifier would actually do vector-based scaling.
This stopped working when WPF 3.5 service pack 1 shipped. (It worked in 3.5 before sp1.) The reason it worked before then is that the DWM (Desktop Window Manager) - the part of Windows responsible for presenting everything you see on screen - uses MILCORE.DLL to do its rendering. Version 3.0 and 3.5 of WPF also used this same component to render - this meant that all WPF content was native content, so to speak. (In fact, on Windows XP, which doesn't have the DWM, MILCORE.DLL is something that WPF puts on your system for its own benefit. But it's built into Vista and Windows 7.) When WPF was using MILCORE.DLL to render on Vista, any effects applied by the DWM such as scaling would also apply in the way you want to WPF - it really did scale without pixelating.
Unfortunately, this is no longer the case. And the reason is that WPF started adding new rendering features. In 3.5 sp1, the new feature in question was support for custom pixel shaders. To enable that, Microsoft had to release an update to the MIL. (The Media Integration Layer - the bit that does the actual rendering.) However, they weren't really in a position to update MILCORE.DLL, because that's part of Windows - it's how everything you see on screen gets to be on screen. Releasing a new version of MILCORE.DLL effectively means pushing out an update to Windows. The release schedule for Windows is independent of that for .NET, and so the only way the WPF team could reasonably add new features was to ship a new MIL. (In theory they could have done it via Windows Update, but since WPF is now owned by a different division of Microsoft than Windows, that sort of thing doesn't seem to happen in practice.)
As of .NET 3.5 sp1, the MIL is in a different DLL called wpf_gfx_vXXXX.dll where vXXXX is the version number. In .NET 4.0, it's wpf_gfx_v0400.dll.
The upside is that WPF gets to add new rendering features with each new version, without needing Windows itself to be updated. The downside is that WPF's rendering is no longer as tightly integrated with Windows as it was briefly back when Vista shipped. And the upshot is, as you've seen, that magnifying is not as much fun as it used to be.
The magnifier application implements its own zoomed image rendering, so that's why you are seeing pixels. WPF does use vector graphics, but in this situation it's not the WPF application itself that is rendering the zoomed image.
If you use something like Snoop you can see zoomed and scaled WPF vector graphics rendering in action.
I suppose, Windows 7 magnifier takes a snapshot of actual application on-screen UI, and then magnifies it itself (not making a special case for WPF applications). Of course what it can access is just the pixels, not the vector graphics which works behind the scene.
The Windows-7-Magnifier is pixel based, but there is a difference in magnifier mode depending on wether an Aero-theme is active or not.
with Areo theme the zoom is pixelated.
without Areo theme the zoom is smoothed (blurry).
Only with Areo theme other Views (except "Docked") are selectable.
What are my options for interacting with a COM control from silverlight?
In my particular project, I have a legacy ActiveX authentication control which I would like to leverage in my silverlight application. Without too many boring details, the control takes a couple of parameters, prompts the user for credentials or tokens, and raises events. I need to set the parameters from my control, and somehow get the events' data to my control.
Furthermore, I would like to get the UI to seem as homogeneous as possible.
What are the best ways of doing this?
Silverlight 4 Beta was announced to have COM Interop for Trusted Applications.
More information on the Tim Heuer blog: http://timheuer.com/blog/archive/2009/11/18/whats-new-in-silverlight-4-complete-guide-new-features.aspx#com
IIRC, Silverlight doesn't provide any way work with COM directly - there's no P/Invoke nor COM Interop - and the sandbox wouldn't allow you to do that in any case. However, you could host ActiveX control in the browser alongside your Silverlight application (which obviously restricts this to IE only), and then write some in-browser JavaScript glue to work with it - JavaScript can interact with both ActiveX and Silverlight.
I don't think you can reasonably host an ActiveX control inside your Silverlight application, however. The closest you can do is as described above, but position ActiveX control (in browser DOM) on top if Silverlight canvas in the right spot, so it looks like a single UI. Not sure if this will not produce any rendering artifacts, however.
Can both WPF and Windows forms controls be used within one application? How difficult or practical an idea is this?
It is fairly straightforward to host WPF controls in a WinForms app with an ElementHost adapter or WinForms controls in a WPF app with a WindowsFormsHost adapter. There are not too many resources on the web showing how to do either of these, however. In the process of learning how to do this for myself I quickly discovered the inherent symmetries between the two pathways. I distilled all my notes into an article comparing and contrasting these symmetries using a unique approach: the article is really two side-by-side articles, comparing every step in detail, starting from creating a user control in one technology to hosting it in an application in the "opposite" technology. My article, published on SimpleTalk.com in August 2010 is available here: Mixing WPF and WinForms.
For completeness, here are a couple good MSDN references, one for each pathway. In fact, the demo solution accompanying my article started from both of these:
Hosting a Windows Forms Composite Control in WPF
Hosting a WPF Control in Windows Forms
I believe there is a WindowsFormsHost control you can put in your WPF apps which will do interop back to WinForms code:
http://blogs.msdn.com/ivo_manolov/archive/2007/07/26/wpf-win32-interop-part-1-hosting-winforms-controls-in-wpf-windows.aspx
We hosted significantly complex WPF controls in an existing LOB WinForms app. It can be done, but we did have issues (some no doubt caused by the steep learning curve). These primarily had to do with loss-of-focus events not being fired when expected, and also keyboard navigation issues.
You can also use an HWNDSource and HWNDHost controls to embed WPF controls in a WinForms (or any Win32, really) app.
When hosting non-WPF content (Be it HTML, WinForms, or Win32 content), you will haveAirspace issues. This means you can't completely compost the WPF content with the hosted content. You also can't animate it etc. There are some interesting issues with respect to scrollviewers see here for more details and a fix also.
Yes you can, both Windows Forms within a WPF application, and WPF controls within Windows Forms. www.novamind.com's mind-mapping application is a successful mix of the two technologies.