Replaced several times but still live and kicking: Windows Forms updated for .NET 6.0
- Reference: 1637593970
- News link: https://www.theregister.co.uk/2021/11/22/windows_forms_dotnet_60/
- Source link:
The first release of [1]Windows Forms was in February 2002, when it was positioned as the successor to Visual Basic 6.0 (1998) as a rapid application development framework for Windows desktop applications. There was huge friction in that transition, but it was nevertheless popular and easy to use. Underneath Windows Forms lies the Win32 API and the GDI+ graphics API.
In late 2006, Microsoft introduced Windows Vista and along with it a new .NET desktop framework called Windows Presentation Foundation (WPF). Unlike Windows Forms, it used DirectX to render graphics, enabling richer designs with hardware accelerated performance.
[2]
WPF was also designed to scale nicely irrespective of the display resolution and Windows display settings, thanks to use of layout managers for positioning user interface elements.
[3]
Windows Forms in Visual Studio 2022
Why is Microsoft still investing in Windows Forms, the oldest .NET desktop framework, when it has been replaced several times, first by WPF, then by Windows 8 with its Windows Runtime APIs, then by UWP (Universal Windows Platform), and most recently by WinUI 3 (also known as Project Reunion)? The answer is simply the popularity of the framework and the number of legacy business applications that use it. Third-party component vendors also gave good support to the platform.
It seems that despite the technical superiority of WPF, many business developers find Windows Forms easier, perhaps because of its apparently simple form designer where a button or checkbox stays where it is placed, at least until users with different display settings complain about overlapping text or chopped-off characters.
[4]
[5]
Windows Forms is only for Windows and not much was done to it for some years, especially as it was for .NET Framework and most development effort was going into the open source .NET Core. That changed when .NET Core 3.0 was released, with support for both Windows Forms and WPF. At this point both frameworks became open source, though this was a fork and Velikorossov's post about [6]what's new in Windows Forms concerns the .NET 6.0 version, not the .NET Framework one.
Migration of an existing application is [7]not straightforward and may be impossible without major surgery.
[8]
Some features of .NET Framework, include Application Domains, .NET Remoting, Windows Workflow Foundation, and Windows Communication Foundation (WCF), with WCF being the most problematic.
Remote communication using SOAP (an XML remoting standard) and WCF was widely used, often with ASP.NET on the web server and a Windows Forms client.
[9]Microsoft previews Visual Studio 2022 for Mac, but why bother when VS Code runs just fine on Apple hardware?
[10].NET 6 LTS and VS 2022: Major releases spoilt by continuing concern about Microsoft's commitment to open source
[11]Microsoft's UWP = Unwanted Windows Platform?
[12]Amid drama at .NET Foundation, Microsoft's De Icaza reveals it was meant to be like GNOME Foundation
Despite these issues, Microsoft has added features including accessibility improvements – such as better screen narrator support and user interface automation – updated templates to support the new .NET 6.0 global using directive, and new runtime designers. "In .NET Core 3.0 we started to modernize and rejuvenate Windows Forms," said Velikorossov.
The biggest challenge remains scaling and high DPI (dots per inch) displays. The original scaling method for Windows Forms was based on the default system font, on whose size all the autoscaling of a form depended. It was not a good system. There were rounding errors, issues with user controls and with form inheritance, and "forms and their child controls could only be concurrently designed by multiple developers if their machine resolutions were the same," say the docs.
There were tweaks, but high DPI support did not arrive until .NET Framework 4.7 and only worked on Windows 10 Creators Update and later. When the .NET Core version came along, Velikorossov describes how the team changed the default font and "quickly learned that a great number of things depended on this default font metrics."
[13]
The aim of full support for [14]per-monitor V2 DPI awareness remains, meaning that applications are never bitmap scaled by Windows (causing fuzzy fonts) but are notified when DPI changes, maybe because of a setting change or a window being dragged to another display. "It is a challenging undertaking, and sadly we couldn't achieve as much as we'd hoped," said Velikorossov, but there are improvements with correct scaling of container controls and MDI child windows "in most scenarios."
There are also community contributions to Windows Forms for .NET 6.0 including MessageBox, used for quick dialogs requiring user confirmation or input, optionally getting two new buttons: Try Again, and Continue.
Developers reacted to Velikorossov's post with some requests. "Please add native dark mode," was one, though apparently a challenge here is that "Windows still does not have a documented way to check whether the system is in light or dark mode." Another commented gratefully that the "Form Designer in release VS 2022 works much better, it was way too slow."
When the .NET Foundation conducted a developer survey earlier this year, WPF and Windows Forms came out as [15]more widely used than Microsoft's more recent efforts.
It is not a good choice for a GUI application today, being Windows-only and a weak option even on Windows, yet legacy combined with its initial ease of use means it will be around for many years to come, something developers are [16]less sure about with some other .NET technologies. ®
Get our [17]Tech Resources
[1] https://www.theregister.com/2002/11/19/windows_net_server_slips_again/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YZvMxuTIHOoi2GYqa@G8TQAAAAs&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://regmedia.co.uk/2021/11/22/winforms.jpg
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YZvMxuTIHOoi2GYqa@G8TQAAAAs&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YZvMxuTIHOoi2GYqa@G8TQAAAAs&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://devblogs.microsoft.com/dotnet/whats-new-in-windows-forms-in-net-6-0/
[7] https://docs.microsoft.com/en-us/dotnet/desktop/winforms/migration/?view=netdesktop-6.0
[8] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YZvMxuTIHOoi2GYqa@G8TQAAAAs&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[9] https://www.theregister.com/2021/11/09/visual_studio_2022_mac_preview/
[10] https://www.theregister.com/2021/11/08/dotnet_6_vs_2022/
[11] https://www.theregister.com/2021/10/26/microsofts_uwp_unwanted_windows_platform/
[12] https://www.theregister.com/2021/10/18/net_foundation_gnome/
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YZvMxuTIHOoi2GYqa@G8TQAAAAs&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[14] https://docs.microsoft.com/en-us/windows/win32/hidpi/high-dpi-desktop-application-development-on-windows#per-monitor-and-per-monitor-v2-dpi-awareness
[15] https://www.theregister.com/2021/05/06/the_state_of_net_survey/
[16] https://www.theregister.com/2021/10/26/microsofts_uwp_unwanted_windows_platform/
[17] https://whitepapers.theregister.com/
Re: Missed opportunity
That's basically what ASP.NET web forms is, which Microsoft has effectively killed by not rolling that through to .NET 5/6
Re: Missed opportunity
Except ASP.NET web forms was also Microsoft developers pretending that an HTML page was a modal system window, murdering it with unnecessary and accessibility failure JavaScript and then trying to foist this broken model onto many developers.
It's not that it couldn't be used in a sane way, however that took a lot of effort and experience from a competent web developer of which there is/was a dire shortage and a windows client application developer tends not to be a competent web developer. It was always obvious that something would be repeatedly and fundamentally broken on a page as soon as the on-hover status bar of a web browser showed "PostBack" all over the place...
Code like it's 1992!
It's 2022 and the recommended method of creating a WPF interface is to type it in by hand. Mind you, there are no WYSIWYG editors for web UIs either after 30 years.
Re: Code like it's 1992!
There were WYSIWYG editors for html the problem is they all sucked, fire up an old copy of dreamweaver sometime and look at the code horror-show that it auto-creates when using its drag and drop features.
Microsoft need to kill it off like they have with IE rather than just politely suggesting that devs move on to something new.
As a developer in both WPF and Winforms....
WPF is clearly the more capable framework but the problem is for the glorified spreadsheets that 95% of all business apps boils down to its massively bloated overkill.
WPF just cannot compete with how fast a simple form can be thrown together in winforms.
Back when Windows Forms was originally designed, most Windows developers were still doing their job in C++ using the Win32 API, maybe under a MFC layer. That's largely an imperative API, with a bunch of weird wonky bits and some shortcuts to shuffle data between the screen and your model.
Most of them had never used anything remotely like XAML bindings before. Also, a lot of people who were making Win32 programs were, well, self-taught amateurs in the field of software development, because they were professionals in something else (that happened to need some simple program put together quickly and cheaply). They went around setting Button.IsEnabled to true or false smack in the middle of business logic, and they liked it.
It's not easy to grok a drastically different design paradigm, when you've never seen anything like it, you don't have a solid understanding of what's going on underneath, and you are on a deadline.
Put simply, if Microsoft hadn't made Windows Forms, a crapload of developers would never have jumped to .NET.
Oh not all C++ developers saddled themselves with MFC. Some of us found [1]something better long before .NET and Winforms. And moving from the VCL to WinForms was a trivial step, not hugely surprising given who was behind them both ;)
In fact even before they gave us RAD [2]Borland's OWL was a better framework than MFC . It was more consistent and coherent.
[1] https://en.wikipedia.org/wiki/C%2B%2BBuilder#Borland_C++Builder
[2] https://en.wikipedia.org/wiki/Object_Windows_Library
What's particularly notable is that despite some odd standing-on-head-and-clapping implementations within the VCL, the layout engine that it exposed by default was considerably superior to almost anything I've come across since. Yes, it caused some nasty redraw issues but in general it was stable as hell. Working with variable display DPI resolutions in an appropriately designed form using the VCL was almost easy as long as the interface was constructed in a sensible manner and dynamic code didn't make assumptions.
Missed opportunity
It always seemed such a missed opportunity that we weren't able to design web applications using the windows form designer and have some magic in the background fix all the annoying formatting issues associated with HTML.
That time has passed...