WPF Begins Its Long Goodbye
medium.com
medium.com
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.
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.
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.
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.
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 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...
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.
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.
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.
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.
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.