> I literally have no idea what I’d use to develop a Windows desktop app nowadays
C#/.NET and WinForms is still a viable choice. Though for a new project I might try WPF, for a slightly more modern appearance.
C#/.NET and WinForms is still a viable choice. Though for a new project I might try WPF, for a slightly more modern appearance.
Reasons? OK, this is going back about 20 years but, and without going on a massive ranty screed [EDIT: oops, failed], compare something like Swing's JTable to WinForms' DataGrid. One is a really nicely designed and abstracted component with a fully pluggable architecture and an out of the box capability to deal with an arbitrarily large data model (perhaps within the limits of 32-bit integers) and the other... isn't. I tried with DataGrid, I really did. I thought other developers at my employer were "doing it wrong" by reaching for third party controls from the likes of DevExpress and Actipro but... they weren't: I was wrong. If you wanted a proper table/grid control that was easy to customise and extend and wouldn't chunder on millions and millions of rows of data you forked over the money to DevExpress for their control and then you got on with your day solving your real problems that you could charge customers actual money for.
We leaned hard on third party control libraries from DevExpress (particularly grid and tree), Actipro (wizard), and Syncfusion (again, grid). To me, with WinForms, and bearing in mind I'd come from Java Swing (which is by no means perfect) it was really weird working with a UI toolkit where what came in the box wasn't sufficient to build any arbitrarily complex UI I might desire. Weird. And frustrating. Same for the lack of abstraction/separation of concerns. In my Java days, when I wanted a wizard I ripped the one out of NetBeans: I did that in at least two prior jobs using it as the basis for multiple wizards across the relevant applications.
And WPF... although architecturally a lot better, IIRC it didn't even have a proper table/grid control: you had to build your own, and when you start thinking about how rich a proper table/grid is, taking into account accessibility, keyboard shortcuts, picking up OS level settings (palette, scaling, etc.), making it behave like a table in any other application on Windows, I just couldn't be bothered building all that... so then it's back to third parties again.
I don't know what third party support for these frameworks is like nowadays but, fundamentally, for the sort of independent experiments I'm working on I don't want to either (i) fork over hundreds or thousands of dollars to third parties for (I think) basic functionality that (I think) should be available as part of the framework and should have been there since day one, or (ii) spend time wrangling the framework to implement this basic functionality because it isn't a core part of the problem I'm trying to solve or the value I'm trying to deliver.
I'd rather just use Qt or something, which at least has what I need.
Do you actually mean the DataGrid? Because the WinForms "DataGrid" was deprecated in 2002 with .NET 2.0 which added the DataGridView. The software I work on is Windows Forms and I can't say I've had any issues like you describe with the DataGridView. I was able to create a control derived from it that does all the heavy lifting for customizations(Visual, interaction, cell spanning, etc.), of which we had a lot. Enough that we were exploring third party controls, but found we would have to customize those ourselves anyway, so I just wrote my own control based on DataGridView to save us the licensing.
WPF had it's own DataGrid control from the start, though I can't comment from experience on it's versatility, I'd assume given WPF's nested-content approach it is surely at least more flexible than the DataGridView.
In any case that didn't really matter. In mid-2004, when I started, the company was still targeting .NET 1.0 for all apps because it meant we could guarantee customers would have that runtime installed on their machines without the need for another dependency. The business model was download -> try -> buy so we wanted as little friction as possible and having a newer version of .NET that might require another download and install wasn't worth the dropout rate we'd experience.
That being said, .NET 1.0 also meant we were using Visual Studio.NET 2002 which was... incredibly painful to work with. I'd come from the world of IntelliJ IDEA which had all manner of code navigation, inspection, refactoring, and testing functionality built in. Not to mention Java already had generics and a much better and more comprehensive framework class library and more mature OSS scene covering whatever was missing from that. .NET 1.0 and VS2002 had none of it and, I forget, was it that VS2002 had no extension model or was it just that ReSharper didn't support it? Either way it felt like stepping back into the mid 1990s and I wasn't happy.
Eventually, sometime in summer or autumn of 2005, I managed to persuade leadership that at least allowing us to use .NET 1.1 and Visual Studio.NET 2003 would be a good idea, and would enable us to use ReSharper, which at least brought us on par with IntelliJ IDEA circa 2003 or so. I can't remember but it might have been that .NET 1.1 had been rolled out over Windows Update or enough service packs for Windows 2000 or Windows XP that we deemed the likely loss of purchases to be negligible.
Our first products developed with .NET 2.0 we didn't start working on until the back half of 2006 and this was really only because we were developing products that plugged in to SQL Server Management Studio which, again IIRC (long time ago), was based on the Visual Studio 2005 shell and required .NET 2.0.
We were always lagging on .NET versions because we wanted to make sure someone could just download, install, and run our products without needing to do anything else.