MFC? WinForms? I gotta ask... why?
-
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
Violently agree. I use WinForms to build desktop apps because that's the quickest way for me to bring a tool or product UI to market with the smallest potential for bugs. And that's the same reason I use .NET Android to build native Android apps. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)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)?
Good question(s). I'll hazard a guess and say perhaps some C++/MFC devs chose to not want to have to learn a new language and UI framework. In 2005, after a couple of years of using C# and .NET, I ported my MFC apps to WinForms and have never looked back. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)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)?
To get a developer to change is very difficult. Mainly they can do it faster the old way and most of the time they don't have the time to learn the new way. I worked for a mayor company, a long time ago that used C as their main language. When I came along and developed libraries, gave classes and tried to spend time teaching them C++ I had no takers. Just an old hippie and don't know what to do; Should I hang on to the old or grab on to the new? Bellamy Brothers
"Ten men in the country could buy the world and ten million can’t buy enough to eat." Will Rogers PartsBin an Electronics Part Organizer - Release Version 1.3.1 JaxCoder.com Latest Article: EventAggregator
-
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)?
At "my" company we create a lot of small applications. Many of them have data grids to display e.g. a bill of material, tree-views, little bit of drag and drop, etc. We wire this up way faster with Winforms than with WPF. The WinForms data binding isn't that bad. And there are almost never surprises that make you google for hours how to solve this weirdness. Maybe if we would use 3rd party controls like we do in WinForms (DevExpress), it would be easier. But plain WPF takes a ridiculous amount of time to make things work. We also have two teams which work on big WPF projects for years now. They created awesome UIs. But the effort they put in for this is tremendous. So, if your customer is willing to pay for WPF, go for it. If you need it yesterday, go with Winforms ;-)
-
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)?
...and our core development team is using C++ and MFC. It's an ECAD system which is in devolopment for over 20 years. Was once ported from HP workstations to windows (Electrical Design Software | E3.series | Zuken EN[^]) There is no way to rebuild all of this in WPF, MAUI or what ever.
-
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
Unfortunately, Embarcadero (formerly Borland) never managed to break through into the market. But I don't know of any other tool that supports, among other things, inheritance of visual and data components as transparently and perfectly as they do. But unfortunately they never managed to produce a reasonably stable version or a community or an Embarcadero ecosystem. And of course this relatively small company Embarcadero has no chance of providing something equivalent to the .NET Framework. :(
-
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 does what I need when I need a GUI, which is rare.
-
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)?
Some people just aren't life long learners. They learn, get complacent, and stop. Happens in all walks of life. Necessity is the mother of invention after all. If there's no longer an apparent need... And the more emotional they are about this topic, the better the odds they're not a lifelong learner despite whatever falsehoods they feed themselves. Remember, lotta peeps lack self-awareness. Which is fine btw, if you're retiring or it's a hobby. Not so much if you're a professional. And that's not to say every new whizzbang thing that comes out should be learned. New tech should be scrutinized. For instance, I don't know Python and I never will. Learning it offers me zero benefit. But that doesn't mean one should live in the past and just stop their learning, when being selective about what to learn. And is say this as an old and crusty dude who still loves C (4eva). But that's no reason to not learn anything new... unless again you're retired or just gave up on life or something. History repeats, I knew people still using COBOL** not too long ago despite the world leaving them behind. Some people refuse to change or learn after a certain point. And as long as there's enough other peeps in agreement, they can live the rest of their days in denial and be blind to it. **If someone's gonna reply saying but the banking industry uses COBOL still, blah blah blah. Don't waste your time. I was having that level of chat 20 years ago. It bores me now.
Jeremy Falcon
-
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)?
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
-
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
-
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:
So I pose the question (this is not snark, I genuinely want to know) why authors/developers are still choosing old(er) technology?
Is there an assumption there that newer technology is better? If so it's an assumption I would question - if something works well why replace it?
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
Maybe because none of the new technologies really survive for more than a few years (months) and are replaced by the next hype? :laugh: [Edit] It now seems to be extremely time-consuming to switch from one VS/C# V xyz to the next. In other words, we are mainly busy migrating from a VS/c#/xyz version to the current version (with all the inconveniences that this entails) without achieving any real benefit for our applications. [Edit 1] Btw. forgot to mention, your question is a good question :-D
Perhaps because a lot of my time as a developer is spent sorting out and fixing config issues with some newer technologies when I can do the same work in 1/10th of the time with an older technology including debugging being easier in some cases with the older ways.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
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)?
WPF was the last product of the Old Microsoft. It has a steep learning curve, it's purpose is to make a Windows application not looking like a Windows application (formerly known as skinning), so it is not really for LoB apps. The Cool Kids on the Code Block developed MVVM for it, which is a method to disrupt the normal way of the flow of information between the GUI and the backend (see validation), so it is not really for LoB apps. Everything beyond that is just the usual dumbing down of Windows to the UNIX/Machintos level.
-
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)?
About the bonus question: There are better platforms for VB6, for example VBForums. There are probably only a few questions for VB.Net syntax. Framework questions can also be answered via C# answers. That's how I do it.
-
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)?
A bunch of reasons: 1) In most cases WPF doesn't solve anything that WinForm can't solve. The amount of customizations and pipelines that you can make with WPF are useful on large interconnected desktop applications - which aren't many; 2) WPF and .NET documentation sucks terribly. It's a giant reference manual without any explanations on how the various pieces should be glued together. This situation is improving, too slowly. 3) WPF does not support native development, WinForms supports both native and .NET. It wins. 4) WPF is simple. Most of the time the real work is behind the scenes and you really need a UI only to interact, briefly, with the backend. The tool I'm maintaining to flash and operate on the equipment manifactured by my company for example would not benefit from the additional complexity of WPF: we need a bunch of buttons, a bunch of textboxes and some radio button or combobox, and the occasional slider.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
A bunch of reasons: 1) In most cases WPF doesn't solve anything that WinForm can't solve. The amount of customizations and pipelines that you can make with WPF are useful on large interconnected desktop applications - which aren't many; 2) WPF and .NET documentation sucks terribly. It's a giant reference manual without any explanations on how the various pieces should be glued together. This situation is improving, too slowly. 3) WPF does not support native development, WinForms supports both native and .NET. It wins. 4) WPF is simple. Most of the time the real work is behind the scenes and you really need a UI only to interact, briefly, with the backend. The tool I'm maintaining to flash and operate on the equipment manifactured by my company for example would not benefit from the additional complexity of WPF: we need a bunch of buttons, a bunch of textboxes and some radio button or combobox, and the occasional slider.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
Could you explain point #3 -- what you mean that WPF does not support native development? If you are referring to APIs such as Win32 (or any DLL with Exports), that's what PInvoke is for, and is GUI agnostic. COM and COM InterOp is also fully supported.
-
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 use WPF almost exclusively. I have to admit it was a very steep learning curve, but now I will not touch WinForms anymore. The new flavours of XAML are not fit for purpose. (UWP, WinUI, MAUI) This is the biggest mistake made by Microsoft: Having multiple dialects of XAML. Why incompatible versions of XAML. If we have a WPF project, we can't 'upgrade' it to something more modern without months (years) of work and bucketloads of money. C++ is for bare metal programming. We will NEVER use C++ with a GUI. And for VB6: I worked for a company that used VB6 for their main applications. They didn't want to rewrite in WPF, so I left.
-
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)?
VB6 Dead... I hope so... have a feeling as stuff breaks it will emerge from the depths to haunt us (COBOL made a comeback a few years ago!!):~
-
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)?
If you don't need advanced/fancy UI Microsoft itself suggest to use WinForms. WPF is for "media" applications, not for enterprises. Data centric desktop applications are super easy to build with WinForms, that is also revamped now in .Net Core. If you add to the recipe ReactiveUI then you will have a modern application, fully testable, protecting you investments for the next 10sh years.
-
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)?
The decision maker receives a prototype within 3 days. And then he can't understand that the final version (with a more maintainable GUI) should take 6 months. But we have hope. Maybe someone will build an AI that turns a WinForms application into a functioning, well-described and easy-to-extend WPF application.
