What are the implications of WPF not using Windows (pl.) for Controls?

Question

It would appear that in a classic Windows^tm application each control that is displayed (Button, ListBox, Menu, ...) gets it own Window (as in HWND).

Further, with Windows Forms (WinForms), while the controls no longer use the classic Window Classes, each control still has its own Window (HWND).

However, Windows (plural) that are created via WPF don't use separate Windows (pl.) for their controls. A button on a WPF dialog is not a separate Window (HWND).

Question

What consequences does this have for what we (as developers) can do or not do with a WPF Window plus it's controls vs. a "classic" dialog Window, where not only each control gets its own HWND, but even the Window Classes are well known (Button, #32770 (Dialog), ...)?

Answer 1

This isn't new. Windowless controls were popular back in the days of ActiveX, VB6 featured them heavily. Browsers use them. Winforms has them too, the ToolStripItem classes are windowless. Component vendors like Telerik specialize in them. Clear advantages are being able to render faster, back-fill missing features, better support for custom styling and platform independence.

The consequences are the obvious ones. The UI tends to age quicker since it doesn't adapt itself to the evolving operating system look-and-feel. Usually quoted as an advantage. There tend to be slight glitches where the custom UI doesn't quite behave like the native one does. WPF does have a few. And UI Automation is more difficult, albeit well covered in WPF with the System.Windows.Automation namespace.