I think what this article (and the events it covers) highlights is that WinForms really does knock it out of the park for being a simple way to create forms over data for Windows desktop apps.
I’d argue WPF is a lot easier even for simple apps. The MVVM/binding story in WinForms is terrible (although interestingly it’s been improved very recently).
And the DPI handling alone saves a massive amount of time in WPF over WinForms. Writing everything in device independent size is a godsend.
There are zero sizes or categories of apps where I’d choose WinForms over WPF today.
> I’d argue WPF is a lot easier even for simple apps.
I could not disagree more. That might be true for you, if you are a person who has already spent a long time learning WPF. It is not true in general; WPF is complex.
Yes - This is in the context of "if you already know both frameworks reasonably well, which one lets you jump through the fewest hoops to get an app that has some minimum quality?".
This is perhaps slightly different from "which one is easier to learn" or "which one can most quickly be used to create a an app for a controlled environment or with limited functionality".
If you are trying to replace an excel sheet (i.e. the "VB6 scenario") then some people would find WinForms more intuitive. That's because it's more straightforward to iterate into something that appears to work, (which is an important quality of a framework that WPF is worse at).
But there are some key weaknesses especially obvious in recent years, which makes you quickly hit a brick wall, not least around DPI. It used to be that you could mostly ignore DPI scaling, and in those circumstances the frameworks were much more equal in terms of usability. But now you'll quickly find yourself in the situation after developing that easy-to-bang-out WinForms app that a user reports that a control has scaled off screen so the whole program isn't usable at all. And now your situation is no longer "need to make an app quickly" but "need to learn two decades of layered workarounds in win32 scaling functionality". And that's one of those things that's even harder than learning WPF to the level where you can accomplish the same thing! You CAN use WinForms and simply accept some of the drawbacks, e.g. enable automatic scaling or disable scaling. While the App will look either blurry or tiny on a 4K screen, it's now a lot simpler to do. It might also be that your app is simple enough that automatic scaling works (But this is highly unlikely).
I guess what I'm saying is that the days where you could spit out a native Windows App using something akin to a VB6 experience are more or less gone - because the landscape is now more difficult. Understanding deployment modes (store vs legacy, and so on), DPI scaling, UAC.. and so on and so forth, is a big undertaking. The VB6 era or even the 2005 WinForms experience isn't coming back. The landscape is more difficult.
Yeah, it's fair to say that the ceiling for what can be developed is higher in WPF.
I'm unsure what problems with DPI scaling you're referring to. Last time I was working on a WinForms app (admittedly not an especially big one) I think I just needed to set the DPI awareness in the manifest and it worked OK. https://learn.microsoft.com/en-us/dotnet/desktop/winforms/hi...
It works OK up to a point. There are traps everywhere. Some controls scale reasonably well, others don't. There is very little support for any vector drawing so you need to hand-roll resolution switching for assets (Admittedly, pixel based assets in WPF will require the same). Doing anything measure-based in code (rather than designer) such as placing items, requires remembering to manually multiply e.g. dpiScale * 16 to make a margin that will be 16px at 96DPI and 24px at 144DPI and so on. It eventually drives you insane.
I've never done MVVM/binding but I have maintained a big-ish WinForms app with ~5k LoC form code and it was really easy to keep it up and add features.
People are saying that wpf was good forgetting that ms has botched it from the start.
First releases had god awful font rendering, that our (.net shop) enterprise customers hated. The things improved only when ms did some parts of visual studio in wpf, if I recall correctly. Also quite bad visual designer. (Even 2! Visual studio’s one and there was another software. Blend?)
Windows Presentation Foundation had some shocking quality issues that Microsoft outright refused to fix, arguing with customers in support forums that it was “like that by design”.
It was. It was broken by design because it was designed for customers, not Microsoft themselves. It was designed to be just complete enough for the “demo” apps in the documentation, and no more.
The most egregious example of this that made me give up on WPF entirely is how they implemented list control data virtualisation.
Data virtualisation is when you have a list of 10K table rows and want to render only the 100 rows that’s visible on the screen. If a user scrolls through the list, there are only ever a few hundred GUI objects in existence.
In WPF, this interface was an IEnumerable, which meant that the framework was forced to iterate through 9000 items to get to 9001. You could see this as you scrolled down a long list: at some point the FPS would drop and the CPU fans would spin up.
The workaround for this required heroic efforts, something like several thousand lines of code.
Meanwhile a simple C# WinForms app could scroll through 40K rows no sweat.
Microsoft left this in WPF for years and years, telling customers that it’s “too hard” to change an established API.
They fixed it the second they had to eat their own dog food when they needed WPF for Visual Studio. You see, the compilation error list can be very long and merely scrolling through it could bring a high-end gaming PC to its knees.
I and many others in the industry decided to never write Windows GUI software ever again.
I don't know that that charactization is accurate.
At a minimum you needed to implement an IList whos indexer creates the actual data when called. You would then set that IList on an ItemSource.
If you could not provide data synchronously you could return an observable object and raised property changed events when the data was available
I don't know if there were constraints that that unworkable for your scenario but my memory was data virtualization not being that much more code than WinForms.
Visual Studio introduced an interface that formalized fetching a page at a time so you did less bookkeeping when mapping indices to items for SQL like scenarios but I don't know if controls had better performance using that interface
This seems like it would work, but it actually didn't. One issue was that WPF uses rows with dynamic row heights instead of fixed row heights like GDI or WinForms. This forced it calculate everything it needed for the layout of each row to compute the total height, scroll position, etc...
Like I said, this got changed when Visual Studio was rewritten to use WPF, and it "works now", but the default behaviour is still the slow path, not the fast path.
The workaround was using a collection wrapper inherited from CollectionView class, usually ListCollectionView or CollectionViewSource. So you could create a collection view, bind it to the list control's ItemsSource property and that was enough. That's few additional lines of code in a view model.
The designer was called Blend - it was started by a dev that, among many other things :), created the designer for WinForms. And the hacks they had to make in WPF to support any VisualStudio designer (WPF had to detect if it was running in designer mode and do things differently https://learn.microsoft.com/en-us/dotnet/api/system.componen...)
WPF and XAML are by far the worst tech stack that I've had to work on during my career. It was only for 1 year because my team got added to a massively delayed project, but I still remember the horrors. The node tree could only ever have a few thousand nodes before performance became abysmal so all kinds of workarounds were written.
WPF is the best desktop GUI framework for enterprise applications. WPF and Prism with third party contols are still unmatched in terms of productivity. Even good old Delphi or VB6 are not coming close.
What a blast from the past. I used to work on WinForms team at the time WPF appeared. We thought we would get fired or re-assigned to other teams. Tam members ended up re-assigned to other team (by then I already left MSFT). And I remember SilverLight as well and all the promises made - originally Silverlight was lead by a PM from WinForms team.
I definitely remember it being pitched as the future of Windows UIs, while having massive feature gaps, and, perhaps most noticeably, looked blurry and horrible on the standard displays of the era (ie, non HiDPI). Why the engineers thought that it would be a good idea to build a resolution-independent UI with no pixel hinting targeting 96ppi displays is utterly baffling.
Silverlight made perhaps a bit more sense since it was almost entirely graphics-focused, but it never really stood a chance against the massive install base that Flash had back then.
XAML isn't the problem, in fact the CSS grid model even came from there.
The problem is management mess and product reboots without any kind of compatibilyt beyond, please rewrite it, this is not the "Developers, Developers, Developers" that we got used to.
WPF will always have a warm place in my heart. It was the perfect skill to have as an undergrad looking for an internship because so many dev teams have annoying problems that can be solved with a simple software tool. I just specialized in fixing these types of problems throughout my college years with WPF and was able to build a strong resume before graduation.
I’m a Swift developer now. Learning Swift UI definitely brings back a lot of those memories. WPF was ahead of the curve for declarative interface programming.
I've wondered about this a lot. My understanding is that VS is still on .NET Framework WPF too; it will take some effort to move it onto .NET Core WPF.
My wild speculation: they'll put some effort into a .NET Core WPF migration and also build out some new features piecemeal in web UI.
I guess you can be glib about it but you should consider that if you are seen as having no awareness of or concern for accessibility then you aren't going to be taken remotely seriously when you write about UI creation.
Whats wrong with the C apis, did microsoft remove them? I think the best solution to these fickle, buggy new frameworks is to just use what was always there and hopefully would be always supported in future. Moreover it seems many of these new frameworks are strongly tied to a specific language C# instead of a simple C api that can be used from any language. It simply is creating problems for yourself if you choose to select such kinds of technologies.
The latter point is especially ridiculous. We only see "blessed languages" in blatantly user hostile platforms like mobile till now. There weren't blessed languages in desktop till now, and its strange to see this coming to desktops.
I did not know mfc is still supported. And yeah thats what I had thought, the win32 stuff still seems the safest bet, or otherwise as you said some safe cross platform framework like Qt.
Not much is happening, but still they added support for HDPI and minor fixes.
As incredible as it may seem, MFC has better integration with Direct2D (on WinUI, Win2D still is missing features from its UWP version), and doing COM is much better than the ATL/WRL experience that C++/WinRT team loves so much (without any Visual Studio support for IDL files and code generation workflows).
For a long time now, I feel like it may not be a good idea to choose a MS UI. It seemed they just start a new framework every other year or so. For example, there is WinForms, WPF, UWP, Metro (don't know what it was called back then, but it was different than UWP), Windows Phone's XAML of which there were multiple, WinUI, MAUI, Blazor and Xamarin.
Some of them overlap. Almost all of them are using some version of XAML. But the XAML you've done in WPF has nothing to do with the XAML were using in UWP. For example, Data Binding in UWP is compile-time, while in WPF, it's run-time-based. So you can't port your code that easily.
I really liked to use some these Frameworks, but nowadays I think one would be better off choosing something that's HTML-based instead.
This article only sights a video stream. I think part of the problem with the glacial pace of development is reliance on manual testing. See this comment:
> Our primary goal is to ensure reduced turn-around-times for new PRs as well as clear the pending backlog of existing PRs. To that end, we are working on putting appropriate automation in place to reduce the dependency on manual testing as much as we can.
If you look at the history of this file you can over the years tests have been always been in the backlog.
As for “where projects go to die”, they have 3 features planned for this year: Windows 11 Theming, a new type of folder browser, and null ability annotations. And they say they don’t think they can do them all. Maybe I’m underestimating, but that’s not a lot.
I would bet good money that a theming overhaul won't happen this year or next. WPF's currently staffed by a skeleton crew, and they have not demonstrated an ability to deliver features anywhere near that size.
We really are in a dark ages for GUI. I remember back in 2003-2007 every hobbyist programmer I knew was whipping up random UIs for their projects on windows. VB6, winforms, VCL, w/e. They were all ugly as hell but buttons were on the screens and they had data grids, menus, copy/paste and all kinds of minor UI niceties provided by the OS. It’s too bad the web came and ate desktop UI’s lunch. Now you’re hard pressed to find a good UI toolkit that’s not in pseudo maintenance mode or with some misguided focus on being compatible with mobile and desktop.
Dreaming for a day that desktop and data rich applications become first class citizens of gui toolkits again. Even Microsoft, historically a leader in this area, is letting us down.
WPF was great, but it was incomplete for the longest time because of lack of dog fooding. Why is it saying goodbye again? Didn't they announce the death of this 10 years ago?
50 comments
[ 4.1 ms ] story [ 99.8 ms ] threadAnd the DPI handling alone saves a massive amount of time in WPF over WinForms. Writing everything in device independent size is a godsend.
There are zero sizes or categories of apps where I’d choose WinForms over WPF today.
I could not disagree more. That might be true for you, if you are a person who has already spent a long time learning WPF. It is not true in general; WPF is complex.
This is perhaps slightly different from "which one is easier to learn" or "which one can most quickly be used to create a an app for a controlled environment or with limited functionality".
If you are trying to replace an excel sheet (i.e. the "VB6 scenario") then some people would find WinForms more intuitive. That's because it's more straightforward to iterate into something that appears to work, (which is an important quality of a framework that WPF is worse at).
But there are some key weaknesses especially obvious in recent years, which makes you quickly hit a brick wall, not least around DPI. It used to be that you could mostly ignore DPI scaling, and in those circumstances the frameworks were much more equal in terms of usability. But now you'll quickly find yourself in the situation after developing that easy-to-bang-out WinForms app that a user reports that a control has scaled off screen so the whole program isn't usable at all. And now your situation is no longer "need to make an app quickly" but "need to learn two decades of layered workarounds in win32 scaling functionality". And that's one of those things that's even harder than learning WPF to the level where you can accomplish the same thing! You CAN use WinForms and simply accept some of the drawbacks, e.g. enable automatic scaling or disable scaling. While the App will look either blurry or tiny on a 4K screen, it's now a lot simpler to do. It might also be that your app is simple enough that automatic scaling works (But this is highly unlikely).
I guess what I'm saying is that the days where you could spit out a native Windows App using something akin to a VB6 experience are more or less gone - because the landscape is now more difficult. Understanding deployment modes (store vs legacy, and so on), DPI scaling, UAC.. and so on and so forth, is a big undertaking. The VB6 era or even the 2005 WinForms experience isn't coming back. The landscape is more difficult.
I'm unsure what problems with DPI scaling you're referring to. Last time I was working on a WinForms app (admittedly not an especially big one) I think I just needed to set the DPI awareness in the manifest and it worked OK. https://learn.microsoft.com/en-us/dotnet/desktop/winforms/hi...
First releases had god awful font rendering, that our (.net shop) enterprise customers hated. The things improved only when ms did some parts of visual studio in wpf, if I recall correctly. Also quite bad visual designer. (Even 2! Visual studio’s one and there was another software. Blend?)
It was. It was broken by design because it was designed for customers, not Microsoft themselves. It was designed to be just complete enough for the “demo” apps in the documentation, and no more.
The most egregious example of this that made me give up on WPF entirely is how they implemented list control data virtualisation.
Data virtualisation is when you have a list of 10K table rows and want to render only the 100 rows that’s visible on the screen. If a user scrolls through the list, there are only ever a few hundred GUI objects in existence.
In WPF, this interface was an IEnumerable, which meant that the framework was forced to iterate through 9000 items to get to 9001. You could see this as you scrolled down a long list: at some point the FPS would drop and the CPU fans would spin up.
The workaround for this required heroic efforts, something like several thousand lines of code.
Meanwhile a simple C# WinForms app could scroll through 40K rows no sweat.
Microsoft left this in WPF for years and years, telling customers that it’s “too hard” to change an established API.
They fixed it the second they had to eat their own dog food when they needed WPF for Visual Studio. You see, the compilation error list can be very long and merely scrolling through it could bring a high-end gaming PC to its knees.
I and many others in the industry decided to never write Windows GUI software ever again.
At a minimum you needed to implement an IList whos indexer creates the actual data when called. You would then set that IList on an ItemSource.
If you could not provide data synchronously you could return an observable object and raised property changed events when the data was available
I don't know if there were constraints that that unworkable for your scenario but my memory was data virtualization not being that much more code than WinForms.
Visual Studio introduced an interface that formalized fetching a page at a time so you did less bookkeeping when mapping indices to items for SQL like scenarios but I don't know if controls had better performance using that interface
Like I said, this got changed when Visual Studio was rewritten to use WPF, and it "works now", but the default behaviour is still the slow path, not the fast path.
Silverlight made perhaps a bit more sense since it was almost entirely graphics-focused, but it never really stood a chance against the massive install base that Flash had back then.
Now you have flutter/swiftui/compose that puts to shame both WPF/.net MAUI
The fact that they doubled down with XML/XAML says it all, they lost the UI just like they lost the phone, server and embedded markets
The problem is management mess and product reboots without any kind of compatibilyt beyond, please rewrite it, this is not the "Developers, Developers, Developers" that we got used to.
I’m a Swift developer now. Learning Swift UI definitely brings back a lot of those memories. WPF was ahead of the curve for declarative interface programming.
My wild speculation: they'll put some effort into a .NET Core WPF migration and also build out some new features piecemeal in web UI.
tl;dr: WinForms is well supported if you don't need it to be pretty. WPF is complex but mature. WinUI 3 might be ready someday but it's not there yet.
I don't want to suggest Electron, but there are valid reasons why people use it...
The latter point is especially ridiculous. We only see "blessed languages" in blatantly user hostile platforms like mobile till now. There weren't blessed languages in desktop till now, and its strange to see this coming to desktops.
Depends on how much you love COM, after Longhorn's debacle, all newer APIs tend to be based on COM.
Using it from C++ or .NET, despite its warts is kind of OK, doing it from C, better be persistent.
Naturally WPF seems to be on a hard time, so that leave us with Forms, or go with third party libraries like Avalonia and Uno, that rely on Win32.
UWP is deprecated, while WinUI 3.0 is years away to reach feature parity with it.
Regarding C++, if MFC isn't your cup of tea given its age, then either Qt or VCL/FireMonkey.
As incredible as it may seem, MFC has better integration with Direct2D (on WinUI, Win2D still is missing features from its UWP version), and doing COM is much better than the ATL/WRL experience that C++/WinRT team loves so much (without any Visual Studio support for IDL files and code generation workflows).
GUI drag and drop that's almost magic. Just hook up the events you need, and you've got a GUI program.
Supports gigabyte strings without need for manual memory management. Does everything you need, compiles insanely quickly.
Oh, and it's cross platform.
Some of them overlap. Almost all of them are using some version of XAML. But the XAML you've done in WPF has nothing to do with the XAML were using in UWP. For example, Data Binding in UWP is compile-time, while in WPF, it's run-time-based. So you can't port your code that easily.
I really liked to use some these Frameworks, but nowadays I think one would be better off choosing something that's HTML-based instead.
https://github.com/dotnet/wpf/discussions/7130#discussioncom...
> Our primary goal is to ensure reduced turn-around-times for new PRs as well as clear the pending backlog of existing PRs. To that end, we are working on putting appropriate automation in place to reduce the dependency on manual testing as much as we can.
See also the recently updated WPF roadmap:
https://github.com/dotnet/wpf/blob/main/roadmap.md
If you look at the history of this file you can over the years tests have been always been in the backlog.
As for “where projects go to die”, they have 3 features planned for this year: Windows 11 Theming, a new type of folder browser, and null ability annotations. And they say they don’t think they can do them all. Maybe I’m underestimating, but that’s not a lot.
I would bet good money that a theming overhaul won't happen this year or next. WPF's currently staffed by a skeleton crew, and they have not demonstrated an ability to deliver features anywhere near that size.
Dreaming for a day that desktop and data rich applications become first class citizens of gui toolkits again. Even Microsoft, historically a leader in this area, is letting us down.
https://github.com/prasannavl/WinApi
There are several samples included that should give you a good starting point.
The performance of this approach in modern C#/.NET is pretty close to native. Ref returns and what not.