Windows Presentation Foundation, especially in its first release, lacks some features that previous technologies already have. When creating a WPF-based user interface, you might want to exploit such features. For example, WPF currently doesn't include some of the standard controls that Windows Forms already has: DateTimePicker, MonthCalendar, NumericUpDown, MaskedTextBox, NotifyIcon, DataGridView, and more. Windows Forms also has support for multiple document interface (MDI) window management, wrappers over additional Win32 dialogs and APIs, and various handy APIs like Screen.AllScreens (which returns an array of screens with information about their bounds). Win32 has controls like an IP Address text box (SysIPAddress32) that have no equivalent in either Windows Forms or WPF. Windows Vista introduces Win32-based "glass" effects, task dialogs, and a new wizard framework that don't have first-class exposure to WPF. And tons of ActiveX controls exist for the purpose of embedding rich functionality into your own software.
Perhaps you've already put a lot of effort into developing your own pre-WPF user interfaces or controls. If so, you might want to leverage some of your work that's already in place. Maybe you have developed an application in a non-WPF technology with an extremely complicated main surface (like a CAD program) and just want to "WPFize" the outer edges of the applications with rich menus, toolbars, and so on. Maybe you've created a web application with tons of HTML content that you want to enhance but not replace.
Given that HTML can be hosted inside a WPF Frame and WPF content can be hosted inside HTML (as a XAML Browser Application or a loose XAMLpage), you can leverage existing HTML content alongside new WPF content. Fortunately, WPF's support for interoperability goes much deeper than that. It's fairly easy for WPF applications and controls to leverage all kinds of non-WPF content or APIs, such as all the examples in the previous two paragraphs. Some of these scenarios are possible thanks to the features I describe here, some are possible thanks to the .NET Framework's interoperability between managed and unmanaged code, and (in the case of calling miscellaneous Windows Forms APIs from WPF) some are possible simply because the other technology defines managed APIs that just happen to live in non-WPF assemblies.
Figure 1 summarizes the different UI technologies and the paths you can take to mix and match them. Win32 is a general bucket that includes any technology that runs on Windows: DirectX, MFC, WTL, OpenGL, and so on. Notice that there's a direct path between each set of technologies except for WPF and ActiveX. In that case, you must use another technology as an intermediate layer. The line between Win32 and Windows Forms is enabled by standard .NET Framework interoperability technologies for mixing managed and unmanaged code (and the fact that Windows Forms is based on Win32), and the line between Win32 and ActiveX is somewhat artificial because there are no real barriers separating Win32 and ActiveX.
In this article, I focus on embedding controls of one type inside applications of another type. I first examine both directions of WPF/Win32 interoperability, then both directions of WPF/Windows Forms interoperability. Although the focus is on embedding controls, I look at another important scenario that isn't as straightforward as you might imagine--launching heterogeneous dialogs.
Embedding Win32 Controls in WPF Applications
In Win32, all controls are considered to be "windows," and Win32 APIs interact with them via window handles known as "HWNDs." All Windows-based UI technologies--DirectX, MFC, and the like--ultimately use HWNDs to some degree, so the ability to work with HWNDs gives the ability to work with all of these technologies.
Although WPF's subsystems (layout, animation, and so on) don't know how to interact directly with HWNDs, WPF defines a FrameworkElement that can host an arbitrary HWND. This FrameworkElement is System.Windows.Interop.HwndHost, and makes HWND-based controls look and act almost exactly like WPF controls.
To demonstrate HwndHost in a WPF application, look at what's involved in embedding a custom Win32 control to add webcam functionality to WPF. WPF's video support doesn't include anything for interacting with local video capture devices such as a simple webcam. Microsoft's DirectShow technology has support for this, so Win32 interoperability lets you leverage that same webcam support in WPF applications.
