Professional VB 2005 with .NET 3.0 (Programmer to Programmer)

The challenge with integration is that these two display models don’t operate under the same set of paradigms. The thing to remember, then, is that when you are working with encapsulating a control, that control - be it WPF or Windows Forms - will be affected by the environment in which it is hosted. For example, if you host a WPF control inside a Windows Forms application, then the ability to control low-level graphical display characteristics such as opacity or background is driven by the rules for Windows Forms. Unlike WPF, which layers control characteristics supporting the display of a control at a layer below the current control, Windows Forms controls are contained; when the control doesn’t paint a background on your WPF control, the display may see that region as not painted and use a black background instead. Note that setting the Transparency property is supported when hosting WPF controls on a Windows Form. You can play with the background color used for the ElementHost control earlier in this chapter to get a feel for this issue.

Recognizing that the host control is often limited by the underlying environment containing it is a good guide for predicting limitations. Although sometimes the actual characteristics of the parent application framework might come as a surprise, as you gain more experience with WPF you’ll be able to predict where issues are likely to exist. For example, you can create both window- and page-based WPF applications, but these applications work on a different model, as page-based WPF application windows are stateless. To support this stateless nature, the WindowsFormsHost control fully refreshes the contained control each time the page is refreshed - losing any user input that you might expect to remain within a Windows control.

Another issue can arise with the advanced scaling capabilities of WPF. While Windows Forms controls are scalable, Windows Forms doesn’t support the concept of scaling down to 0 and then restoring properly.

Similarly, be aware of the message loop, current control focus, and property mapping of hosted controls. The host controls support passing messages to the controls they contain, but across the application the ordering of messages may not occur in the expected order. Similarly, when a WindowsFormsHost control has passed focus to a contained control and then the form is minimized, the host control may lose track of which control within its Child has that focus. As a result, even though the unseen host has the current focus within your WPF application, there is no visible control with that focus. Finally, there are additional potential issues with property mapping other than the background issue described earlier, so you need to watch the behavior of these controls carefully.

The preceding list is not a complete list of potential issues you may encounter when attempting to integrate these two distinct user-interface implementations. One final warning is that you can’t nest host controls. Both Windows Forms and WPF can contain multiple-host controls within a given window, but each of these host controls must be separate and of the same type. Thus, you can’t create a WPF application that will host a WindowsFormsHost control in such a way that a portion of that control contains an ElementHost control. In other words, controls hosted in one environment can’t host controls that are part of the environment hosting them. If you’re integrating controls, try to minimize the number of user controls or panels containing the host controls so that you don’t accidentally attempt to nest the embedded host controls in another layer of integration.