Events
Mar 17, 9 PM - Mar 21, 10 AM
Join the meetup series to build scalable AI solutions based on real-world use cases with fellow developers and experts.
Register nowThis browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
If multiple presentation technologies are used in an application, such as WPF, Win32, or DirectX, they must share the rendering areas within a common top-level window. This topic describes issues that might influence the presentation and input for your WPF interoperation application.
Within a top-level window, you can conceptualize that each HWND that comprises one of the technologies of an interoperation application has its own region (also called "airspace"). Each pixel within the window belongs to exactly one HWND, which constitutes the region of that HWND. (Strictly speaking, there is more than one WPF region if there is more than one WPF HWND, but for purposes of this discussion, you can assume there is only one). The region implies that all layers or other windows that attempt to render above that pixel during application lifetime must be part of the same render-level technology. Attempting to render WPF pixels over Win32 leads to undesirable results, and is disallowed as much as possible through the interoperation APIs.
The following illustration shows an application that mixes Win32, DirectX, and WPF. Each technology uses its own separate, non-overlapping set of pixels, and there are no region issues.
Suppose that this application uses the mouse pointer position to create an animation that attempts to render over any of these three regions. No matter which technology was responsible for the animation itself, that technology would violate the region of the other two. The following illustration shows an attempt to render a WPF circle over a Win32 region.
Another violation is if you try to use transparency/alpha blending between different technologies. In the following illustration, the WPF box violates the Win32 and DirectX regions. Because pixels in that WPF box are semi-transparent, they would have to be owned jointly by both DirectX and WPF, which is not possible. So this is another violation and cannot be built.
The previous three examples used rectangular regions, but different shapes are possible. For example, a region can have a hole. The following illustration shows a Win32 region with a rectangular hole this is the size of the WPF and DirectX regions combined.
Regions can also be completely nonrectangular, or any shape describable by a Win32 HRGN (region).
The window manager in Windows only really processes Win32 HWNDs. Therefore, every WPF Window is an HWND. The Window HWND must abide by the general rules for any HWND. Within that HWND, WPF code can do whatever the overall WPF APIs support. But for interactions with other HWNDs on the desktop, WPF must abide by Win32 processing and rendering rules. WPF supports non-rectangular windows by using Win32 APIs—HRGNs for non-rectangular windows, and layered windows for a per-pixel alpha.
Constant alpha and color keys are not supported. Win32 layered window capabilities vary by platform.
Layered windows can make the entire window translucent (semi-transparent) by specifying an alpha value to apply to every pixel in the window. (Win32 in fact supports per-pixel alpha, but this is very difficult to use in practical programs because in this mode you would need to draw any child HWND yourself, including dialogs and dropdowns).
WPF supports HRGNs; however, there are no managed APIs for this functionality. You can use platform invoke and HwndSource to call the relevant Win32 APIs. For more information, see Calling Native Functions from Managed Code.
WPF layered windows have different capabilities on different operating systems. This is because WPF uses DirectX to render, and layered windows were primarily designed for GDI rendering, not DirectX rendering.
WPF supports hardware accelerated layered windows.
WPF does not support transparency color keys, because WPF cannot guarantee to render the exact color you requested, particularly when rendering is hardware-accelerated.
For more information regarding the limitations of interop regions, see HWNDs inside WPF.
.NET Desktop feedback feedback
.NET Desktop feedback is an open source project. Select a link to provide feedback:
Events
Mar 17, 9 PM - Mar 21, 10 AM
Join the meetup series to build scalable AI solutions based on real-world use cases with fellow developers and experts.
Register nowTraining
Module
Choose the best UI framework for a native Windows development project - Training
Windows developers have various options for creating applications that run on Windows. This module introduces the native Windows UI frameworks that are available for Windows development. It also provides guidance on how to choose the best framework for your application.
Documentation
Learn how to interoperate Windows Presentation Foundation's environment for creating applications and Win32 code.
Learn how Windows Presentation Foundation provides a straightforward mechanism for hosting a Win32 window, on a WPF page.
Hosting Win32 Content - WPF .NET Framework
Learn how to reuse Win32 content inside WPF applications by using HwndHost, which is a control that makes HWNDs look like WPF content.