|
I guess, being honest to yourself will also provide a valid answer.
They just didn't die yet
WinForms and WPF were said dead by MS, then they grabbed them back from the dead with .NET 8 (at least for me).
I'd suppose the C++ stuff was handled the same way, there might not be a "newer" option.
And after all, Xamarin now MAUI, Blazor, UWP and what else they came up with, how long did or will that last?
It seems like MS is focusing on what they have, Desktop -> you'll stick to WPF and WinForms, Web -> you'll probably use Blazor if you like an easy transation to the web instead of learning Typescript and Angular.
I mean, the heck, WPF still has no own file browser and needs to rely on WinForms there!
And MAUI... well you wanna play the app game then eh?
Just my 2 Cents on that 
Rules for the FOSW ![ ^]
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found");
|
|
|
|
|
I have been working in WPF for over 10 years and still using the standard .NET Frameworks such as 4.6. I like WPF since it is like developing with "WebForms". However, and admittedly, it is somewhat harder to use than "WinForms".
All I have seen with the introduction of the new .NET Core Frameworks is what they no longer support. "WebForms", the best web development environment ever created despite its issues; dropped. WCF, for distributed development; dropped and told to use someone else's distributed development tools. WPF Designer; still struggling to be as good as it was. VB.NET; evolutionary development dropped. C#; so many new features that I find the editor in Visual Studio 2022 too bloody annoying to use, so I went back to Visual Studio 2019. ASP.NET Core is a mess as Blazor can't seem to make up its mind whether it is going to maintain its MVC roots are move back to a "WebForms" style of development paradigm.
"WinForms" is still probably the most stable platform in all of the frameworks mentioned so why wouldn't developers continue to use it?
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftware@outlook.com
|
|
|
|
|
Greetings,
Organizations don't want to fund migrating from older methods to something newer until they absolutely have to. My last company had apps using VB (Classic), VB.Net, and C# with Winforms and a few WPF and MFC apps as well as COBOL and Salesforce. There were a few inhouse apps using Access.
Some of the clients were all about using the newer tech however balked at the cost of training and converting.
Cegarman
document code? If it's not intuitive, you're in the wrong field 
Welcome to my Chaos and Confusion!
|
|
|
|
|
I think a better question is why not? Why should we always jump on the latest bandwagon du jour?
ETA: Especially when there is no compelling reason to do so. That is where I am - I have read all these great things about the latest stuff and I have not been convinced that I should or need to rewrite the extensive code base I have.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Unsure what MFC is, but I can tell you that the last company I worked for who insisted upon C++ Winforms was a good company, but their code took forever to build and was half C# and half C++. It wasn't difficult to understand, there was just tons of C++ boilerplate. One notable bug was their indexing: `some_business_array.Rows[0].Value ...`, which would sometimes throw an index out of bounds exception. Instead of assigning a temp var for index 0, then checking for valid rows, this would just be left as indexing the 0th place for hundreds of lines. I would think that a more meaningful bug and error would be important to C++/C# coders, especially senior ones. It's for this reason I did not trust their code, nor their decision to remain on Windows Forms and C++. Another reason was they tried to implement their own MVP observer pattern for Windows Forms, caching important data using Reflection in C# (which was written inefficiently in an O(m x n) foreach loop). In my opinion, they should have fully committed to C#, at minimum.
I don't have much against Windows Forms, except to say that it's boring to have to manually set `.Text` and `.Color` through events and drag-and-drop (then later have to dig through mounds of spaghetti to update it years later) when we have more convenient tech like HTML and many ways to bind UI components to their updates with just one command. Coder preference? Oh, and HTML is more secure than Windows will ever be, so there.
|
|
|
|
|
In terms of article content on the site, I see 26 articles tagged WPF in past 12 months .. but only 5 tagged WinForms and 12 tagged MFC.
But ok yes that is still a lot more MFC content than I expected, in the year 2023.
|
|
|
|
|
WinForms is very “mature” and fast/easy.
It may look old and clunky compared to newer, more modern frameworks. But, it just works, and is even supported in .NET Core! Hell, if it is a simple LOB utility or something, I would even consider (and have used) a TUI - Like Terminal.GUI[^]
With that being said, I would only use WinForms for a LOB/internal apps with the following caveats: styling doesn’t matter, short term and/or smaller app, and cross platform not needed. In my current company, about half of the employees are using Mac’s so, that last one is a consideration.
If I needed a prettier UI, these days I might consider AvaloniaUI instead of WPF. The XAML is nicer/cleaner; the project has more development activity, and it makes a cross platform product (plus the project has been around for over 10 years, and probably isn’t going anywhere). I wish they had a Rich Text Edit, but they are transparent, and in my mind a better choice than WPF or MAUI.
What I would REALLY consider, moving forward would be Tauri[^], or maybe JetBrains Compose Desktop[^]. Both cross platform, flexible and using mature systems.
BTW: WinForms designer is sad, and locks you in to VS. I started a more modern, fluent syntax for WinForms with WinFormMarkup[^] (provided as is).
Thomas Baker
Sr. Software Engineer
W.w. Grainger, Inc.
|
|
|
|
|
Just to add one point to Tom's reply, Tom and I worked together back in the day on a very large WPF Point of Sale application for Grainger. Given that it was a very dynamic UI with no specific fixed "form", WPF was (and is) the logical choice for this LoB application.
That being said, when I worked at Citibank back in the very early 90's, we needed a very similar (in idea) type of dynamic UI presentation, and Win32 was the only game in town (MFC was only in alpha at the point). If anyone from that era remembers, dialog boxes and its ilk were created in the Dialog Editor, produced .RC files, and had to run through a Resource Compiler.
We made that application sing, and it would rival any WinForms or WPF LoB application today. It was, in a word, a thing of beauty, all written entirely in C.
When you're a software developer, you have to mix in a little magic into the mix! 
|
|
|
|
|
For an app with a complex UI, I prefer Qt. For quick UI utilities, for me nothing beats MFC.
About ten years ago, I was tasked to write a GUI utility to support a feature on the embedded system I worked on. The app to configure the back end was a WinForms/C# app. IF they eventually wanted to integrate my utility, we felt it best if I wrote it in C#/WinForms.
I ported our base C++ code to C#, which was a giant pain due to so much p/invoke and having to write a layer of COM code (in C++, we could could use IOCTL since we didn't need as much functionality.) After spending about 30 hours on the WinForms UI, I got frustrated implementing a feature and spent a weekend writing an MFC version. It took me less than 15 hours. It did clear my mind, though it took another three or so days to finish the WinForms version.
So, 15 hours for MFC vs 45 for WinForms though, to be fair, the WinForms version was fully resizable; the MFC version was not.
|
|
|
|
|
Stacy Dudovitz wrote: Bonus Question: What's also noticeably absent is VB6 and VB.NET. Have those platforms truly bitten the dust (for good)?
I've only had a quick look at some of the responses, but...was there a single one that brought this up?
I don't know about VB.NET, but I believe MS, after decades of inactivity, has finally said VB6 was very much over. And not a moment too soon.
I mean, knowing MS's backwards compatibility history, I'm sure the runtime still works on newer versions of Windows (the runtime is 32-bit, so that's not about to get killed even though 64-bit OSes have pretty much fully taken over), and VB6 itself might still install (and if not, use a VM with an older OS), so I suppose there's little that prevents some poor, sadistic soul from writing new code with it today...but that person would deserve a beating.
|
|
|
|
|
We have a number of older products built using C++ and MFC, along with an inhouse tool started in 2000 and under active maintenance today. Our newer products use C# and WPF for the UI.
For complex UI or UI constructed dynamically in code WPF is the way to go. Doing the same thing in MFC is tedious, requires a lot more plumbing, and sometimes simply isn't feasible. For what it's worth, I find WPF to have a simpler mental model for constructing user interfaces. I've found the key to using it effectively is to ignore the "declarative" purists and build what works.
On the other hand if you're doing something with a lot of Windows API calls ("system programming" back in the day), C/C++ is a better approach. While it's true you can call most of the API using Platform/Invoke, some things are just a pain to translate (access control lists for example).
As always, it's a matter of choosing the proper tool for the job.
Software Zen: delete this;
|
|
|
|
|
For those that require many calls to the OS, I found that writing COM objects in C++ to access the OS is far easier than PInvoke calls. You access the COM objects through .Net RCWs.
Just watch out to correctly implement IDisposable on classes that host your COM/RCW objects, especially if you are managing unmanaged resources.
|
|
|
|
|
You're not wrong about the learning curve part. WPF's learning curve isn't horrific, but it's more work than not using it.
But the biggest reason IMO is how long it takes to do things in WPF. What is your app for? Will a shiny WPF interface make it work better or more productive? I'm gonna go out on a limb and say that the majority of the time the answer is no.
Yoda knew the answer: Winforms is "quicker, easier, more seductive."
|
|
|
|
|
That's actually context dependent which is more difficult. Even the most basic Forms and Custom Controls, which can be a requirement in even the simplest data entry/LOB applications, are far more difficult to write and implement in WinForms than in WPF.
One of the very core strengths, which is also its weakness vis-à-vis learning curve, is the emphasis on reusability. Control templates, data templates, triggers, etc. are very powerful paradigms that are very difficult to implement in WinForms, and lead to overly complicated code.
|
|
|
|
|
Yes, well ... very witty.
(Remind me people, why don't we have a "Sarcasm" emoji?)
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
Recently, a very public comments section let me use "p*ssed (off)" (with the *) in a sentence. Surprised me too. It still maintains a cerain standard (IMO).
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Eh ?
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
It's a response to a deleted thread starter message: a pictogram of a stickman with a turd emoji for a head ...
If you check the "parent" indicator on the left when you hover you'll see it goes into the abyss.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I don't see the parent indicator on the original post
In a closed society where everybody's guilty, the only crime is getting caught. In a world of thieves, the only final sin is stupidity. - Hunter S Thompson - RIP
|
|
|
|
|
Hover your mouse over the message I wrote, and the "parent" indicator appears: a thin vertical line. If you follow it up, it points above all messages which indicates the thread started has been deleted. Normally it stops at the parent message.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
The other thing you can do is "View Thread" which displays a Message Closed message at the root.
|
|
|
|
|
So, what's your SQL resources for beginners and related to JOINs ?
I'm kind of stuck on request that should use JOIN and can't figure out how to make it work.
I somewhat understand how it works, but there's something missing in my understanding of the universe.
Thanks.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
|
If SQL Server... For simple things, you could try using SSMS' visual designer for creating a view.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
