Modernizing Windows Desktop Applications with XAML Islands

If your only source of information is the Internet, you may be under the impression that Windows desktop development is pretty much dead. Yet according the telemetry data in Visual Studio, there are roughly 2.4 million developers actively working on desktop applications each month, up 50% from 20 months ago. (Metrics as of May, 2018.) With such a large community to support, Microsoft is looking at way to help developers integrate those assets into Windows 10.

XAML Islands

One of the biggest complaints about Microsoft Windows development is the lack of investment in Winforms and WPF; most of the new features exposed by Windows 10 are built soley for UWP. And despite the fact that we can now call UWP APIs from the .NET framework, that only works when the UI isn’t involved.

To address this, two new controls are being created: WinForms XAML Host and WPF XAML Host, which allow you to embed a UI written for UWP inside your existing WinForms/WPF application.

Wrapped UWP and Windows 7 Fallbacks

One of the reasons developers continue to use WinForms or WPF is support for Windows 7. Subsequently, a requirement for the new XAML Islands is the ability to function correctly when the application isn’t running on Windows 10.

One example is a WebView, which is available now. If the application is running on Windows 10, the web view will host the Edge browser. If you are instead running on Windows 7, an IE browser control will be loaded.

Other controls in the planning stages include MediaPlayer, InkCanvas/InkToolBar, Map, and SwapChainPanel.

Airspace

Developers who have had to mix WinForms with WPF are familiar with the concept known as “airspace”, which deals with the problem of overlapping controls from difference UI frameworks within the same window.

In Win32 development, each object on the screen gets its own window handle (HWND) registered at the OS level. This HWND is associated with a rectangle on the screen where the object can render its content. Generally speaking, each WinForms control each gets its own HWND, while most WPF controls just share one HWND for the whole window.

For XAML islands (WinForms and WPF), a HWND is created for use by the UWP control. This can have some repercussions that aren’t obvious. For example, if you rotate the UWP control the HWND doesn’t rotate with it, which means the HWND needs to be larger to accommodate it.

Popup context menus can be especially difficult to deal with. These usually have their own HWND, but that HWND may not necessarily be stacked correctly with the HWND for the XAML island causing the menu to appear behind another control.

Threading Model

Currently with UWP, each top-level window is expected to have its own dedicated UI thread. Say, for example, you have a master-detail view where the detail view is written in UWP. There are several ways you can implement this:

• Detail view shares the master view’s window: no problem.
• Detail view has its own top-level window and doesn’t share objects: no problem.
• Detail view has its own top-level window but shares objects with the master view: possible race conditions, UI cross-threading issues, etc.

Eventually this problem will be resolved with the introduction of lightweight windows.