MFC? WinForms? I gotta ask... why?
-
I've noticed a trend here on the site where authors/developers are still writing GUI applications in MFC (for C++) and/or WinForms. What's noticeably absent is WPF in either Framework or .NET Core. So I pose the question (this is not snark, I genuinely want to know) why authors/developers are still choosing old(er) technology? I used to think it was the learning curve, but I suspect there's more to this story. Bonus Question: What's also noticeably absent is VB6 and VB.NET. Have those platforms truly bitten the dust (for good)?
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 :)
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found"); -
I hear you! I'm one of those rare folks that like the VB.net/WPF combination. I actually went from VBA to VB.net and pretty much skipped classic VB all together. I've never understood how C# became the defacto MS language other than it's [only slightly] less verbose. The case sensitivity in C# is the thing that really makes me not want to use it...Of course, this is just my humble opinion. I'm sure there are reasons that C# works better for others. But with all that said, these days I'm in a role where I don't do any coding, and with the current software development landscape, I'm pretty okay with that.
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.
-
And you found out WPF can also bind data async right? That made a huge impact on my work before i had to switch to blazor and angular for the front end.
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found"); -
I've noticed a trend here on the site where authors/developers are still writing GUI applications in MFC (for C++) and/or WinForms. What's noticeably absent is WPF in either Framework or .NET Core. So I pose the question (this is not snark, I genuinely want to know) why authors/developers are still choosing old(er) technology? I used to think it was the learning curve, but I suspect there's more to this story. Bonus Question: What's also noticeably absent is VB6 and VB.NET. Have those platforms truly bitten the dust (for good)?
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
-
I've noticed a trend here on the site where authors/developers are still writing GUI applications in MFC (for C++) and/or WinForms. What's noticeably absent is WPF in either Framework or .NET Core. So I pose the question (this is not snark, I genuinely want to know) why authors/developers are still choosing old(er) technology? I used to think it was the learning curve, but I suspect there's more to this story. Bonus Question: What's also noticeably absent is VB6 and VB.NET. Have those platforms truly bitten the dust (for good)?
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?"
-
I've noticed a trend here on the site where authors/developers are still writing GUI applications in MFC (for C++) and/or WinForms. What's noticeably absent is WPF in either Framework or .NET Core. So I pose the question (this is not snark, I genuinely want to know) why authors/developers are still choosing old(er) technology? I used to think it was the learning curve, but I suspect there's more to this story. Bonus Question: What's also noticeably absent is VB6 and VB.NET. Have those platforms truly bitten the dust (for good)?
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.
-
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 :D Welcome to my Chaos and Confusion!
-
I've noticed a trend here on the site where authors/developers are still writing GUI applications in MFC (for C++) and/or WinForms. What's noticeably absent is WPF in either Framework or .NET Core. So I pose the question (this is not snark, I genuinely want to know) why authors/developers are still choosing old(er) technology? I used to think it was the learning curve, but I suspect there's more to this story. Bonus Question: What's also noticeably absent is VB6 and VB.NET. Have those platforms truly bitten the dust (for good)?
-
I've noticed a trend here on the site where authors/developers are still writing GUI applications in MFC (for C++) and/or WinForms. What's noticeably absent is WPF in either Framework or .NET Core. So I pose the question (this is not snark, I genuinely want to know) why authors/developers are still choosing old(er) technology? I used to think it was the learning curve, but I suspect there's more to this story. Bonus Question: What's also noticeably absent is VB6 and VB.NET. Have those platforms truly bitten the dust (for good)?
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.
-
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 can create applications faster in Winforms than I can in WPF, because the designers in WPF were created at gunpoint.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
Let's admit that your priority isn't creating "engaging user interfaces". Others seem only interested in delivering "fast". Nowhere have I seen a statement that one does what one does because it's what the "user wants". I only create software that I would use personally; and that does not mean taking "short cuts". I said I "like" my tools; but that is only because they can deliver everything the user has asked for to date. Which includes "shiny".
"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
-
Let's admit that your priority isn't creating "engaging user interfaces". Others seem only interested in delivering "fast". Nowhere have I seen a statement that one does what one does because it's what the "user wants". I only create software that I would use personally; and that does not mean taking "short cuts". I said I "like" my tools; but that is only because they can deliver everything the user has asked for to date. Which includes "shiny".
"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
If I wanted to build "engaging user interfaces" I'd use AvaloniaUI or something, not WPF, which is already dated. You sound like a snob. My apps are fine. Sometimes less is more.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
This is exactly why I use WinForms. I don't want to style or customize. I'm a back end dev mostly. Dragging and dropping elements and using the mouse to resize is the most customization I want. From there, I can focus on writing code that actually completes the task I started with.
Hogan
(And where is the "user" in all this? "I don't want to ...") With "flexibility" comes complexity. UWP and WPF are more "flexible" than Windows Forms. They actually have a "model" for the UI; it's called the "visual tree"; and it gives the whole thing meaning. Versus "drag and drop" (or drop and drag). The "designers" are "flat and 2d" and cannot intelligently construct "complex" (hierarchical) graphic interfaces. WPF and UWP requires a mental shift that "dabbling" doesn't scratch.
"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
-
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! ;) :)
-
If I wanted to build "engaging user interfaces" I'd use AvaloniaUI or something, not WPF, which is already dated. You sound like a snob. My apps are fine. Sometimes less is more.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
A "snob"? I find you arrogant. I can see why people leave. The "honey" mutual admiration society.
"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
-
Lots of good answers, and from my 4+ decades of experience as a professional developer (now retired), I suspect its a combination. So, allow me to weigh in with some of my own thoughts: My experience includes Win16/Win32 APIs (C), MFC (C,C++), WinForms (C#) and WPF (C#, Framework and Core). While I agree with the sentiment that one must keep moving forward in a professional setting (i.e. clients as the end users), I also have endured the pain of being unable to upgrade because of client budget, incompatibilities, and developer culture. In addition, much of the move from C/C++ to .NET and across GUI platforms was made both easier and more difficult with COM, remoting, COM InterOp (RCWs/CCWs), as well as XML and JSON. When I was heavily invested in COM, I used WTL (Windows Template Library) for my GUIs when working in C++. WTL cannot replace MFC (it was never meant to), but for most applications it can hold it's own. Here's the thing... I still love C/C++, it's often the only choice for me when I worked on embedded projects (think Eclipse IDE, etc.). That being said, C# is soooo much easier to work with, is in many ways more powerful and is as performant. That leaves me wondering why C/C++ for a Windows GUI project. When it comes to which GUI platform in the C# world, WinForms "strength" is also it's weakness. If you have ever tried to implement components, or have to copy/reuse/resize a form and its subsequent components, you know how incredibly difficult that can be. Add in language support and it becomes a night mare. On the other hand, WPF is indeed a steep learning curve, but what you trade for in return is extensibility and full theming and language support in XAML through control and data templates, styles, etc. Once you use and master WPF, there's no going back! :) One could punt and use WPF in a minimalist way by using a Grid control and just plop controls in fixed positions. One could avoid learning a large part of WPF, but that's like buying a Ferrari only to transport people around by dragging it behind a tow truck. So I do get it's context dependent, such that there are still a great many developers that choose alternate paths. Sometimes there's no compelling reason when, for example, supporting a legacy application that no longer is viable to port or upgrade. I also do defend the right of hobbyists to pick their poison. I still love, now again, to fire up my Trash80, if for no other reason, than to see if ChatGPT ports to Z-80 really work! ;P :laugh: One group notabl
Brilliant post. (VB is an odd duck; it's component based; not object oriented; but it gained my interest in components that I fashion extensively to this day).
"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
-
A "snob"? I find you arrogant. I can see why people leave. The "honey" mutual admiration society.
"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
I only create software that I would use personally; and that does not mean taking "short cuts".
Implying I do. Maybe pay more attention to what you write. Then you won't seem like a hypocrite for taking offense after being insulting and being responded to in kind. Just sayin' Edit: If you're implying I'm the one that made Randor leave, you couldn't be more wrong. He and I are in contact on Reddit.
Check out my IoT graphics library here: https://honeythecodewitch.com/gfx And my IoT UI/User Experience library here: https://honeythecodewitch.com/uix
-
(And where is the "user" in all this? "I don't want to ...") With "flexibility" comes complexity. UWP and WPF are more "flexible" than Windows Forms. They actually have a "model" for the UI; it's called the "visual tree"; and it gives the whole thing meaning. Versus "drag and drop" (or drop and drag). The "designers" are "flat and 2d" and cannot intelligently construct "complex" (hierarchical) graphic interfaces. WPF and UWP requires a mental shift that "dabbling" doesn't scratch.
"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
-
I've noticed a trend here on the site where authors/developers are still writing GUI applications in MFC (for C++) and/or WinForms. What's noticeably absent is WPF in either Framework or .NET Core. So I pose the question (this is not snark, I genuinely want to know) why authors/developers are still choosing old(er) technology? I used to think it was the learning curve, but I suspect there's more to this story. Bonus Question: What's also noticeably absent is VB6 and VB.NET. Have those platforms truly bitten the dust (for good)?
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.
-
I've noticed a trend here on the site where authors/developers are still writing GUI applications in MFC (for C++) and/or WinForms. What's noticeably absent is WPF in either Framework or .NET Core. So I pose the question (this is not snark, I genuinely want to know) why authors/developers are still choosing old(er) technology? I used to think it was the learning curve, but I suspect there's more to this story. Bonus Question: What's also noticeably absent is VB6 and VB.NET. Have those platforms truly bitten the dust (for good)?
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.