Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News WPF in .NET 4.6

WPF in .NET 4.6

Despite rumors to the contrary, WPF development at Microsoft isn’t dead. There are four major areas of investment for WPF in .NET 4.6 and beyond:

  • Performance
  • DirectX Integration
  • Supporting Modern Hardware
  • Tooling

Before we get into that, we should first talk about support. Microsoft has been accused on numerous occasions of aggressively closing bug reports for WPF and other libraries without properly investigating them, let alone fixing them. As part of the 4.6 roadmap, Microsoft will be reopening any bug logged in Connect with 10 or more votes. While this doesn’t make up for past mistakes, it at least shows that they are starting to take community feedback seriously.

Long term, WPF in .NET 4.5.2 is guaranteed to be supported at least until 2024. This is based on the fact that .NET, and thus WPF, is considered to be an OS component an thus inherits the OS support lifecycle.

Touch Support

Touch support improvements focused primarily on reliability and performance, especially while the UI thread is busy. Multi-touch events should also be more reliably reported.

Scrolling and Virtualization

A cornerstone feature of WPF is its ability to virtualize controls in a list. In theory, this allows for lists that contain in excess of 10,000 items. In practice, virtualization can fail for a number of reasons. One of these reasons is hangs due to excessive layout cycles, which WPF 4.6 intends to resolve.

Transparent Child Windows

The ability to mark child windows as transparent was added in Windows 8. This behavior has likewise been exposed to WPF. It requires indicating that Windows 8 features are in use via a manifest file. If the application is run on a Windows 7 machine, no exception will be thrown but the child window will not be transparent.

High DPI Issues

WPF can now understand cursor files that support multiple resolutions. When loading a cursor file, you need to pass in ‘true’ for the new scale with DPI parameter for this to take effect. Previously you could work around this limitation by manually detecting the DPI and loading the correct cursor image.

Another High DPI issue is the way backgrounds on controls such as the combo box are drawn. While technically incorrect at any DPI, the symptoms of this bug such as clipped borders don’t become visible until higher DPIs come into play.

Tomorrow we’ll talk about the long-term plans for WPF including WPF App Local.

Rate this Article