Hello. I have been trying Qt for a few days in order to quickly get an interface for my applications. It reminds me of the old VB6 which allowed us to quickly put buttons, slidebars, input text and more features. However (like a real retro dev :) I say to myself that I should focus more my efforts on MFC and its code implementations for a clean interface. For both of those alternatives, there are always many pluses and cons - and finally I have no idea which could be better than the other...
I am wondering what you use for your applications on Windows? I know that MFC is not dead, but maybe someone did the U-turn in order to dev his applications under Qt. Every comment will be appreciated. Thanks ++

PS : maybe you know some better solution(s) under Windows? Let me know.

MFC was sort of replaced by managed c++ and .net framework or whatever the 'new' MFC technical name is.
but that makes for some weird, horrible c++ so a lot of devs write the UI in C# and call C++ behind it. MFC is fine esp for simple / small projects: its not going anywhere for a long, long while and its at least C like rather than made up syntax like the new stuff.

All that aside, all the M$ stuff is married to windows or has to run in virtual machines (clunky, slow, prone to not working) on other OS. If you want to run the code off windows, QT is your friend.

At the end of the day, if you decouple the work from the UI entirely, you can always redo the UI and that really isnt too hard until you get deep into graphics, usually into 3d or very advanced 2d. If you tie the work to the UI, it becomes very difficult to change, though. Keeping them apart can cost you some performance as some shortcuts become unavailable -- usually this is a non issue. If you are making a game or game-like program, its a whole new discussion anyway.

Definitely Qt. Microsoft has this habit of bringing out a new GUI framework every 5-10 years that's supposed to revolutionize how people make GUIs, expose a few basic controls for it but not 90% the legacy stuff, and then abandon it in just a few years. MFC's turn on the Microsoft tech treadmill was way back in the 90s, so its time is long gone. Nobody is starting new projects in it, nor is it being updated. Unless you're doing it as a learning exercise (which can be profitable, become someone has to maintain all those antiquated codebases), stay away from it. Actually, stay away from any Microsoft API that has yet to gain traction in the developer community, because you know it's not going to have any new features added to it.

MFC was indeed superseded by WindowsForms from .NET. Although Microsoft basically abandoned WindowsForms as well, at least the community did embrace it, unlike MFC, so you can find a lot of code online for it.

Thank you for your comments which confirm my own point of view. Qt seems interesting, but I would like to know more about WindowsForm - just a first approach. I will try it. However I have an alternative in my mind which I would like to share with you. Do you think that Unity can be a way to get an interface for some C++ applications? This is not a technical question because I know how to "link" a console application to Unity... Does it make sense or not? For me, it could really simplify some solid projects ++

https://docs.unity3d.com/Packages/[email protected]/manual/index.html

Do you think that Unity can be a way to get an interface for some C++ applications?

Sure, in the same way that you can kill a mosquito with a bundle of dynamite.

For me, it could really simplify some solid projects ++

Well, doing a GUI (and nothing else) with a game engine will make your final program one or two orders of magnitude larger than it would otherwise be, and immediate-mode GUIs (the kind typically used in games) demand structuring your code completely differently, compared to event-driven GUIs. In what way do you think you're simplifying things?

Sure, in the same way that you can kill a mosquito with a bundle of dynamite.

Thank you for all your comments - again clever and efficient. Unity could simplify my work because I have a lot of experience with it - more than 10 years. I don't know many things about WindowsForm or MFC (just some rudimentaries). There is another opportunity with the OLC::PixelGameEngine which can be a good way to add a custom GUI into applications, but you have to create everything - buttons, sliders, etc. Really I don't know which way to take ++

There is another opportunity with the OLC::PixelGameEngine which can be a good way to add a custom GUI into applications, but you have to create everything - buttons, sliders, etc.

You definitely don't want to do that. GUIs do a ton of heavy lifting, particularly with regards to text rendering. If you're starting at the pixel level you're effectively increasing your work many, many times. Consider the simplest of tasks: there's text on the window and the user wants to select it, copy it to the clipboard, and paste it on a different application. Try to think about all you'd need to do to support that. Bonus: the text may not be in English. See for example what happens as you progressively select this text:

I enjoyed staying -- באמת! -- at his house.

A GUI toolkit handles all that nonsense for you.

I agree. I used OLC::PixelGameEngine in order to create a basic GUI with buttons, a custom slider (which is bugged), a text input field... It works (more or less) as expected, but it is a hard code. Definitely I have to find a good template for GUI - maybe imGui ++

https://github.com/ocornut/imgui

FWIW, I'm working on a VS Solution at work that uses MFC, COM/ATL. That code project was developed about 20 years ago and we still support it because it continues to work in a Windows 10 environment. I think it's kinda impressive that code from an old framework has worked on several OSes, with changes to hardware (storage technology: HDD -> SSD, RAM, HID, etc). Can we switch to Qt? Functionally, yes, but MFC is free :)

That said, it's kinda difficult to find developer/community tutorials/articles on how to use it.

Just googling around, a lot of folks think that although MFC isn't worth learning, what it abstracts over, Win32 API, is still relevant. I wonder if Qt makes use of Win32 under the hood.

You have to give it to MS. They care about backwards compatibility. Although they haven't done anything to MFC for years, they still continue to provide it as an option in VS, and as you say, the applications still work perfectly.

I wonder if Qt makes use of Win32 under the hood.

Qt in particular no, for the most part. It only uses the Windows API to set up the window (obviously, since there's no other way), but once that's done it takes over the drawing completely. Yes, when you use a Qt application, Qt is replicating the behavior of the native controls; that's why if you pay close attention sometimes you'll notice subtle differences in animations and such. It also means that if you wanted you could tell Qt to use controls for a completely different platform. You could make your Windows application look like an OSX or KDE application, if you wanted. If the application was designed correctly Qt will even adjust things such as the order of OK/Cancel buttons to reflect the platform's conventions.

Some other toolkits do use native controls, though. wxWidgets, for example. IIRC wxWidgets was originally conceived as a sort of open source alternative to MFC, but I could be wrong.

what turned me off on alternates is their wysiwyg capability. MFC, you drop a button on a form, double click it, edit the code that appears, and it works and looks exactly like what you did in the editor. Its been a while, but the others did not, maybe still do not, have that 100% down. If they have it now, good, then it matters a lot less. I remember QT, some years ago, specifically the form editor didn't look like the real form at all.

I haven't looked closely because I spent 6 years in no-gui land coding followed by an MFC only code base.

For Qt in particular, no, that doesn't quite work, but it's close. If you only use standard widgets it works as expected, but if you use derived widgets with custom behavior, you need to tell the designer which classes they inherit from, and it draws them based on the classes it knows. If you've customized the drawing the designer will show the look it knows about, not how it will look when running. If you've added custom properties the designer will not show them in the properties box. I'm not sure if you can manually edit the .ui with those properties to have the code generator initialize the properties correctly. Although at that point you may as well just do it in the constructor.

The only designer I've seen that's able to handle custom controls with more or less arbitrary modifications in a WYSIWYG manner is VS's for Windows Forms.

RAD used to be the "in" thing for doing apps. Delphi and C++Builder were truly WYSIWYG IDEs. Primarily for Windows they could create cross-platform apps that ran on Linux, macOS, Android or iOS.

Delphi was based on Object Pascal, C++B was C/C++. The IDEs are still being developed, but lately they've become bloat-ware.

https://en.wikipedia.org/wiki/Delphi_(software)
https://en.wikipedia.org/wiki/C%2B%2BBuilder

One major plus for the IDEs was the sheer number of 3rd party components available, many for free but were of high quality. Another plus was the interoperability between Delphi and C++B.

MFC isn't just a GUI framework, it is a C++ encapsulation of the C-based Windows API.

If looking for cross-platform GUI frameworks there are wxWidgets or FLTK, amongst other offerings.

FLTK is used by Bjarne Stroustrup in his Uni C++ lectures, and in his "Programming Principles and Practices Using C++" book that's adapted from his Uni lectures.

I loved c++ builder, even bought a personal copy. But no one used it at any job I ever applied for. It made it so easy.

When Delphi and C++B were Borland products they were great. After Embarcadero acquired them they were bloated up with a lot of cross-platform features that never really worked. Plus the purchase price went through the roof.

I had "for evaluation" full feature copies of Delphi/C++B 5 & 6, at the time I was working for a US computer retail store. I really like C++B, though learning C++ using C++B was a PITA.

I tried the "Community" (free) versions of D/C++B a couple of years ago and both crashed my computer when trying to install them. *foo(e)!*

When MS released VS 2015 Community I never looked back.

It is rather amusing the only fully compliant C++20 compiler at this time is Visual Studio 2019/2022. I remember when VS lagged behind the other compiler suites, sometimes for quite a time.

Borland's C++ Builder had it's own framework - OWL (Object Windows Library) - which at the time was in competition with MFC. OWL was more high-level than MFC and was easier to use. It even had it's 'own style' controls which differed in appearance to MS. You could usually tell which compiler had been used to create a program by how buttons etc looked. I used Builder back in the 1990's for Windows 3 and 95 and quite liked it.

MFC is a "pain in the a..." and not portable at all!

If you have the choice, definitely go with a decent and portable GUI Toolkit, such as Qt or wxWidgets.

If .NET is an option, consider using Windows Presentation Foundation (WPF).

I think I mentioned it before: I once was assigned the task to "fix" an application written in MFC, and gave up unnerved after about ~2 weeks of trying to work around its endless quirks. Re-created the whole UI with Qt in one evening, even though this was my first Qt project. Never looked back... Qt just does the things that you need a GUI Toolkit to do, and things simply work the way you'd expect them work.

MFC in it's day was a step up from using basic WIN32 APIs - although I preferred Borland's OWL. I reckoned it took about 18 months - 2 years to become really familiar with MFC. But MFC's day has been and gone. Unless you're got in-depth knowledge of MFC I won't suggest starting a new major MFC project (or indeed a WIN32 one).

And I'd only suggest getting to grips with MFC if you envisage a career maintaining existing MFC code (boring but valid as there's absolutely loads of existing MFC code about).