MFC? WinForms? I gotta ask... why?

[glennPattonWork3]

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!!):~

[rallets]

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.

[snoopy001]

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.

[atverweij]

For your first and last (bonus) question: I write in VB and mostly Winforms. Why still WinForms or other older technologies? Because older technologies are proven. And invested in. I have build a complete ecosystem around Winforms during my career, that will cost a fortune to migrate to WPF or any other GUI framework. Further, the ease of the designer and also the ease of runtime generated UI code - not matched by any other GUI framework. And, as most of my software will run on Remote Desktop - al lot of them with high latency and none with GPU acceleration - no other framework gives the same userexperience (performance) as WinForms. Why VB? Because I started out as a Basic Programmer in the nineties, and VB does all I need. The Bonus question - why you don't see much VB on Code Project or anywhere else. That's because we learned. As soon as you ask your question in VB, you are not taken seriously. So, we just convert anything to C# before we ask a question. The same for an article. If it's VB, the chance is really small that it will be allowed. So, also in this case, we convert it to C# and publish it without a problem. Or just gave up and do not try to share anymore.

[Member 3349609]

While Microsoft denies it, they have largely abandoned VB.NET developers. I'm a VB.NET web developer, and there is no way forward with Microsoft's newer .NET Core framework and VB.NET. Razor Pages or Blazor would be great for me if I could code in VB.NET, but instead I have to switch to C#. It also means my web applications have no migration path. Sure, I can switch to C#, but it truly pisses me off that they have left me hanging in this way. So why am I still choosing this older technology? * There is nothing wrong with it. * I have a LOT of existing VB.NET projects that I support for clients, and with no migration path, I'm leaving them as is. My clients don't pay me to rewrite apps just to change the language/technology with no tangible benefit for them. * I have some C# projects that I support, but I don't enjoy it. VB.NET is a joy to me, which makes me very productive. * I am stubborn. --Pissed off VB.NET web programmer

[Colin Humphries]

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.

[CodeZombie62]

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.

[MikeCO10]

Stacy, being semi-retired (which has been a fail, lol) I think one of the reasons I've seen is that basically we're often assigned to build things and it's not worth the learning curve to accomplish the given task. So, the default is using the tools you know. I live in my odd world of C#/VB .NET, PHP, and JS along with some of its variants. One project is an 'agile-RAD' large desktop app using WinForms and VB.net. There's no budget to recode in C# or anything else, and no real reason to do so since there's no scalability requirement; the number of users will never be greater than a few dozen. Their needs change regularly with quick implementation required. Their apps are heavily data-driven pulling from Postgres and DB changes aren't unusual. The datagridview control is a staple for their needs, which has both pros and cons to its WPF counterpart. Oops, back to your question. If someone asked me for a desktop app today from scratch, it would be in VS; likely C# but I wouldn't totally rule out VB depending on the specs. I know there's differences, but for a lot of things they can be negligible. Winforms vs WPF is a deeper design consideration. In truth today, it's rare to see a 'from scratch' app that doesn't have interaction with either existing DBs, the web or some other requirements. I use more contract work where required in some cases to maintain sanity. Though... I'm working on a project that has a large PHP codebase and a proposed new piece requires it to play nice with a Node-JS API app. My colleague of 30 years told me that "I'm crossing over to the dark side". :laugh:

[BryanFazekas]

Stacy Dudovitz wrote:

One group notably missing from those that responded are VB/VB.NET developers. It's very easy to take cheap shots at both, but I would think at least VB.NET would be a popular choice given its similarities to WinForms, and the fact that many of us cut our teeth on some form of interpreted BASIC on older vintage hardware.

About 75% of my work assignments in the 90's were VB (v2 through v6), and it was THE way to produce solid business applications for Windows quickly. Friends who worked in other technologies looked down upon VB, but I was producing in 3 months what they were taking a year+ to do. And I had my pick of assignments there was so much work. Fast forward to 2003 -- VB.NET had been out 2 years and VB6 work was slowing down. I had ridden the bleeding edge since graduation, so I jumped on the VB.NET bandwagon, assuming it was the logical progression. It wasn't. There was no progression, it was a BASIC-like language that had nothing to do with Visual Basic. MS published an "upgrade wizard" ... :wtf: anyone who tried it knows how well it [didn't] work. After a year or so, I switched to C#, as it was getting solid support from MS AND there was a good job market. It's been 20 years and I do not regret that decision. The skillset has kept me employed and will do so until I retire. Yes, I keep up with other technologies and if there's a downturn in the C# market, I'll jump ship. WinForms is the follow-on to what made VB so useful. It works and works well -- if developing Windows desktop applications. With the Click-Once installers, we deploy to SharePoint and our installation problems are about 5% of what they are in other technologies. Regarding CORE and new C# versions? Both change way too quickly for business needs, and a lot of what's released is not necessary or useful to folks whose primary job is solving business problems quickly and efficiently.

[rtischer8277]

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?

[BryanFazekas]

COBOL didn't make a comeback. It's been there all along, doing its job. In 1981 I was told that COBOL was a dead language and no one should learn it ... 40+ years later it's still the backbone of many large organizations, both government and private sector. IIRC, it hit the news because too many of the programmers were retiring without replacements. That's a serious problem -- a friend of mine came out of retirement 3 time for mainframe projects. My group is ready to retire its last MF program, replacing it with a web app. The primary MF programmer retired 6 years ago and his understudy retired in December, so we're on the edge. I watch the VB news, simply out of curiosity. There are (or were) several groups trying to revive it. And there are VB6 and VBA jobs out there. I wouldn't recommend it for new grads as the future looks negative, but ya never know. In the mid-90's I didn't think Java was viable ... :laugh:

[snorkie]

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

[Jacquers]

Understandable. WPF can do drag and drop too, but if Winforms is easier for a simple ui then use what you're familiar with :)

[Peter Moore Chicago]

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. :D 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

[Member 110323]

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.

[iplaykeys]

but then there's the DPI issue, which is the main reason I started to work more with WPF...then I fell in love with how WPF does databinding (yes, I know it can be done in Winforms too, but it was more of an afterthought and doesn't work quite as cleanly, IMHO)

[MSBassSinger]

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.

[iplaykeys]

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.

[PSU Steve]

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.

[HobbyProggy]

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.

Rules for the FOSW ![^]

MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found");