Are native Windows Controls still used in .NET GUIs?

Question

Is the stuff that is displayed when you create a GUI with WinForms or WPF still based on the native controls like Common Controls or any of the system provided Window Classes or is everything that is displayed "custom" drawn by the framework?

Note: I'm not talking about stuff like a file dialog, but GUI that was actually implemented with WinForms or WPF.

_{And yes, this is purely out of interest.}

Answer 1

User HighCore commented:

WPF Uses an "HWND" for the Window objects, but then all other objects (Controls) inside the Window are WPF objects not related to Win32 in any way, wheareas AFAIK, winforms uses a separate HWND for each UI element.

And indeed, using Spy++, we can observe the following when we create a test app with a simple dialog/window and a button on it:

MFC/native:

• The app window is a Window (HWND) with the Window Class of #32770 (Dialog) (I used a "Dialog based" app.)
  • The Button is a separate Window (Class: Button)

Windows Forms:

• The app window has the Window Class WindowsForms10.Window.8.app.0.2bf8098_r20_ad1 (oh my)
  • The Button is a separate Window (Class: WindowsForms10.BUTTON.app.0.2bf8098_r20_ad1)

WPF

• There's only one top level Window, although for good measure I added a ComboBox, a ListBox, and a Menu to this window in the UI designer.
• The Class of the only Window is: HwndWrapper[WpfApplication1.exe;;9b1aec0f-1b88-419c-8730-858906314cd9]

The Window Class names are actually quite interesting: With the MFC/native one you get the classes known for years and documented on MSDN. With Windows Forms, it does appear that it always uses the same class names. And with WPF it seems the name of a Class of a Window also incorporates the executable/process name.

So apparently MS thinks that using more than one Window per window isn't necessary anymore. I think I need to open a second question for that.

Answer 2

Windows Forms uses native controls for some UI elements. WPF draws everything on its own.