Nommu

Windows Forms Lives On in .NET 6 – Visual Studio Magazine

npressfetimg-1245.png

News

Windows Forms Lives On in .NET 6

Windows Forms would like you to know that the reports of its death are greatly exaggerated.

How exaggerated? Claims of its death go back at least to 2014, when a post started off with “Everyone knows WinForms is dead, right?” And that was just one of many through the years, as a quick web search will confirm.

But Microsoft begs to differ.

“We continue to support and innovate in Windows Forms runtime,” said Microsoft’s Igor Velikorossov last month in announcing what’s new for WinForms in .NET 6. He’s a software engineer on the dev team for the 19-year-old product, a free and open-source graphical (GUI) class library included as a part of .NET, as described by Wikipedia.

Here’s how Microsoft describes it for you coders who might have been more concerned about learning your ABCs when it was introduced in 2002:


Windows Forms (WinForms) is a UI framework for building Windows desktop applications. It is a .NET wrapper over Windows user interface libraries, such as User32 and GDI+. It also offers controls and other functionality that is unique to Windows Forms.

Windows Forms also provides one of the most productive ways to create desktop applications based on the visual designer provided in Visual Studio. It enables drag-and-drop of visual controls and other similar functionality that make it easy to build desktop applications.

Velikorossov said Microsoft began a WinForms modernization and rejuvenation effort back when .NET Core 3.0 came on the scene in 2019. In explaining what’s new for WinForms in .NET 6, he detailed changes in accessibility, application bootstrapping, templates, runtime designers and high DPI and scaling.

[Click on image for larger view.] WinForms Accessibility Improvements (source: Microsoft).

“Making Windows Forms applications more accessible to more users is one of the big goals for the team,” Velikorossov said, listing a host of enhancements:

  • Improved support for assistive technology when using Windows Forms apps. UIA providers enable tools like Narrator and others to interact with the elements of an application. UIA is also often used to create test automation to drive apps.
    We have now added UIA providers support for the following controls:

    • CheckedListBox
    • LinkLabel
    • Panel
    • ScrollBar
    • TabControl
    • TrackBar
  • Improved Narrator announcements in DataGridView, ErrorProvider and ListView column header controls.
  • Keyboard tooltips for the TabControl‘s TabPage and the TreeView‘s TreeNode controls.
  • ScrollItem Control Pattern support for ComboBoxItemAccessibleObject.
  • Corrected control types for better support of Text Control Patterns.
  • ExpandCollapse Control Pattern support for the DateTimePicker control.
  • Invoke Control Pattern support for the UpDownButtons component in DomainUpDown and NumericUpDown controls.
  • Improved color contrast in the following controls:
    • CheckedListBox
    • DataGridView
    • Label
    • PropertyGridView
    • ToolStripButton

As far as application bootstrapping and trimming boilerplate code, that effort seeks to address a problem: “the lack of a mechanism to share Windows Forms project-level configuration settings between the runtime and the designer.” That has to do with no communication to the designer about things like default font settings in an app, for example.

In following a general .NET trend, the team trimmed the boilerplate, replacing the “very dated” Program.cs and Main() methods with this:

class Program
{
    [STAThread]
    static void Main()
    {
        ApplicationConfiguration.Initialize();
        Application.Run(new Form1());
    }
}

Other changes included:

  • Template updates: In an effort to match changes in .NET workloads, the team updated C# WinForms templates, adding support for:

    • Global using directives
    • File-scoped namespaces
    • Nullable reference types

    One new C# feature normally associated with those features above, top-level statements, isn’t available because of the way WinForms works.

  • More runtime designers: WinForms consists of the runtime and the designer, the latter being a “general designer” that can be embedded in applications or closed-source components specific to Visual Studio. The team ported missing designers and designer-related infrastructure for building a general-purpose designer, such as a report designer, per an earlier update.

    [Click on image for larger view.] WinForms Designer (source: Microsoft).

    Duplicating the .NET Framework WinForms designer on .NET Core (which became just .NET 5, .NET 6, etc.) proved to be a thorny problem for the dev team, which mentioned it was a “huge technical challenge” way back in 2019.

    “For developers the .NET Core Windows Forms Designer (when we will release the GA version) will look and feel the same as the .NET Framework Windows Forms Designer,” said program manager Olia Gavrysh at the time. “But for us it is a huge technical challenge to bring the designer to .NET Core because it requires the design surface that hosts the live .NET Core form to run outside the Visual Studio process. That means we need to re-architect the way the designer surface ‘communicates’ with Visual Studio.”

  • High DPI and scaling fixes: The team has progressed on the “challenging undertaking” of dealing with high-DPI awareness concerns, specifically providing correct support for PerMonitorV2 mode in WinForms apps. “Sadly we couldn’t achieve as much as we’d hoped,” Velikorossov said, noting that the progress made now enables the team to:
    • Create controls in the same DPI awareness as the application
    • Correctly scale ContainerControls and MDI child windows in PerMonitorV2 mode in most scenarios. There are still few specific scenarios (e.g., anchoring) and controls (e.g., MonthCalendar) where the experience remains subpar.

Some 28 comments were made on the post, with one thread concerning app theming, specifically a request for a native dark mode for WinForms apps. “The team is acutely aware of the desire for the theming of Win32 apps, unfortunately it has dependencies on Windows API, and there are challenges resolving this,” replied Velikorossov. “We’re actively engaged with our partners in Windows but don’t have an ETA at this time.”

The fact that WinForms hasn’t died might well be attributable to an active open source community, with Velikorossov mentioning several contributors by name. One comment doubled down on that praise, specifically mentioning Paul M. Cohen, as did Velikorossov, thanking him for a contribution along with many others.

About the Author


David Ramel is an editor and writer for Converge360.

Source: https://visualstudiomagazine.com/articles/2021/12/03/winforms-net-6.aspx

Windows