|
Yep, case sensitivity is pretty annoying to me, too.
Those of us who started with .NET 1.0 were told for years that selecting C# or VB.NET was a "lifestyle choice", and either was fine. And I believed them.
I can even understand that there is no easy migration path for the move from WebForms to MVC or Razor Pages. I get it. But now I'm supposed to not only completely rewrite all these web applications, I'm also supposed to do it in a completely different language? Not a chance.
You are lucky you are out of coding these days. While I love writing code, I don't love the current software development landscape, as you put it.
|
|
|
|
|
Our own heavy-duty native C++ scientific application is built around the MFC framework. Despite our toying with several shiny new things from Microsoft over the last couple of decades, we somehow continue to see MFC and Qt as being the only serious contenders. Please keep all those MFC tips and tweaks coming. Your audience is still very much out there.
|
|
|
|
|
I’ve never done anything in C++ or MFC or WPF so I can’t comment on any of those. For most of my career I’ve worked in some version of Basic (DEC Basic, GW Basic, Borland Turbo Basic, MS Access Basic, VB for DOS, VB6, VB.Net, VBA) and then more recently got into C#. Worked for over 13 years on a legacy app that was written mostly in VB6 with some com interop stuff written in VB.Net and C#.
Basic isn’t completely dead. After the 13 year gig ended I ended up working for a place that had some VB6 code that needed to be maintained while they were going through a conversion. A couple years ago I worked for a mortgage company who used a popular loan origination system called Encompass. It allows company to setup rules that look very much like Basic (actually, I think you can write them in C# as well but not sure about that).
I have to say that I actually enjoy working in C# way more than Basic but if I ever find myself unemployed, I won’t necessarily turn down a job just because it’s in Basic.
|
|
|
|
|
I've been programming in MFC C++ since its inception. And Microsoft has been maintaining it completely. MFC has survived and been significantly enhanced by all of the C++xx upgrades. Just yesterday, after working all day with Copilot, we finally solved a particular coding goal of being able to instantiate either a common implementation or a specialized implementation controlled by one explicit template line of code. All type safe. All ODR compliant. Anyway, my point is, MFC has always been the most future-protected choice for me and well as close-to-the-metal performance, all without inserting extra layers of indirection.
Ever since I read Jeff Prosise's book on MFC where he wrote about the speed and coding beauty of the low-lying connection to the OS, I was hooked. A layer of indirection means you are dependent on that vendor's development whims which jeopardizes your code. Yes, I am dependent on Microsoft, but my C++ code is by and large not and could be ported. That can't be said of my code if I were dependent on other layers and ephemeral programming languages. I want my code to survive forever. Is that so bad?
modified 3-Mar-24 8:06am.
|
|
|
|
|
I find Windows Forms' popularity in 2024 inexplicable, I'll be honest, but I will defend MFC and WPF.
If you want to use C++ and want to fully leverage Windows and aren't worried about cross-platform, there's still no better option than MFC. The thing to remember about MFC is it literally is a set of FOUNDATION classes. You can still utilize every modern Win32 API you want to. MFC just takes care of the most obnoxious parts of the scaffolding and UI interactions that you really don't want to be dealing with, and it's stuff in Windows that hasn't changed in decades. So MFC really by definition will continue to be relevant and usable indefinitely as long as Windows exists, most likely, and really needs no significant updates. Your alternative is to use pure Win32 with no helper framework. If you really want to do that, you might as well just write in assembly too. 
WPF is in a somewhat similar boat except it's C# and XAML. It is infinitely flexible and extensible. I mean, there's literally no application UI you can conceive that you can't do in WPF given that you can completely retemplate any control and even use Direct3D if you want to. You might be doing a lot of the work yourself, but it's doable, so again, it sort of by definition has an indefinite shelf life.
As for Forms, it's more or less the C# equivalent of MFC, but WPF offers far more flexibility in customizing UI, so unless you hate XAML for some reason (though you actually don't HAVE to use XAML if you really don't want to) I don't see why you'd pick Forms over WPF today. Nonetheless it is on par with MFC and WPF in terms of reliability and scalability so I also don't begrudge anyone who uses it.
Other than those three (MFC,WPF,and Forms), none of Microsoft's application frameworks are suitable for enterprise or commercial productivity applications. UWP is more or less on par (IMO) with Android and iOS for dinky consumer "apps" but out of the question for anything that needs to scale. WinUI3 came with a lot of hype but years later still suffers from stability problems, and not being open source I'm not going to let myself be 100% reliant on Microsoft to fix their bugs or find workarounds (wait, I guess it finally is open source as of late last year, so maybe that will be an option soon). MAUI (nee Xamarin Forms) is a sad parody of its former self. Blazor Hybrid, I don't even know what the @!%*% that's supposed to be.
And Visual Basic? Well remember VB.NET is just a programming language and is actually equivalent to C# line-by-line. Based on Stackoverflow questions people still use VB.NET both with WinForms and WPF. So it's not like VB is an alternative to WPF or Forms; it's an alternative to C# and still alive. It ain't my cup of tea but some people I imagine just find the syntax more approachable.
modified 28-Feb-24 14:41pm.
|
|
|
|
|
Can only speak for myself. The one project where I use C++/MFC is one that was started back in 1997 when MFC was state of the art. The project has grown to over half a million lines of code. No money/sponsor to recode the whole thing. It's only a small part of my job now.
I know lots of other languages/platforms, but when I want to quickly build a tool I reach for C# WinForms. If it ever gets to the point where I can't quickly make a program, I'll look elsewhere. But, I hope to be retired before then.
|
|
|
|
|
Speaking only for myself, when writing desktop apps, I use WinForms targeted to .NET 8, writing in C# as I have for the past 20+ years.
The main reason why, is that there is a UI designer for WinForms that allows me to spend a lot less time on creating a professional "look and feel" and more time on the other things that count, such as validation, efficiency, scalability, and making the backend (or libraries if it is stand-alone) better designed, coded, with good exception handling front end and backend.
The lack of a UI designer for XAML (Xamarin, MAUI, etc.) and HTML/CSS (Blazor) and for WinUI steers me away from them. Without a UI designer, even with "Hot Reload", the additional time to hand-code UIs is ridiculous. MS had a WinForms designer that did what it does now, back in the 1990s. A small team created that tool, and MS bought the app and hired the team. I don't know if this lack of a "visual" UI designer in "Visual Studio" does not speak well of MS, or the capabilities of the current crop of software engineers at MS, or both.
|
|
|
|
|
I am the lead for a WinForms app, still targeted for Framework 4.6.2, that is 90% VB.NET and 10% C#. Roughly 1.5 million LOC. This is an enterprise app supporting US Air Force electronic warfare. We started the app back in 2005 and it's still going strong and expanding today.
|
|
|
|
|
There are many legacy apps, that it just might not make sense to convert.
And that should be fine. And very pragmatic.
Although there is nothing saying you can't use WPF in a WinForms control[^] if you want.
Thomas Baker
Sr. Software Engineer
W.w. Grainger, Inc.
|
|
|
|
|
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!
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
