MFC? WinForms? I gotta ask... why?
-
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.
-
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)?
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; -
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.
-
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)?
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."
-
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.