Best approach to porting MFC GUI to Qt
-
I have a few moderately large projects that I'd like to port to use Qt instead of MFC - that sounds like a plan :)
So how should I go about this? I've quite a few questions:
-
Can I leave the project being started from WinMain() (for the MFC stuff) and only change to using main() once all the MFC code has been removed?
-
Do I then add a QApplication object inside WinMain?
-
Can I then convert each GUI component one by one?
-
What issues do I have to watch out for - I'm sure there are loads!
-
Are there any useful/essential tools to get this done? I've seen a mention of something called "Windows Migration Framework" - is this still appropriate?
I looked for a White Paper or Red Book or similar on how to approach this but failed - surely this is a pretty common requirement?
Many thanks
David -
-
Hi,
Did you already come around the QtWinMigrate module ?
-
Is that the same as the "Windows Migration Framework" - I updated my post at about the time you replied.
Are there any extended docs on using it apart from the readme, or do I get "get stuck in"?
Is this the same as I would get from : https://github.com/qtproject/qt-solutions
David
-
I went through porting a humongous app from MFC to Qt and while it's not a very pleasant process it's quite doable. Depending on the size and complexity of your app it might range anywhere from easy to not worth the effort. In my case it took about 2 years and cost me pretty much most of my hair. After 5 years there are stil bits and pieces of MFC left but that's just because nobody has energy left to clean it up :P To answer your questions:
Can I leave the project being started from WinMain() (for the MFC stuff) and only change to using main() once all the MFC code has been removed?
Yes. You need to provide the standard argc and argv params to QApplication object though. You can fabricate them using e.g. GetCommandLineA(). The tricky part is that you can't just start Qt's event loop with
exec()as it would shut off MFC, and you can't leave the MFC event processing as is because it would swallow events targeted for Qt. For the transition period you need to devise an event dispatching solution that will sort through events and send them to the correct framework. The mentioned QtWinMigrate is a good starting point for that.Do I then add a QApplication object inside WinMain?
QApplication object must outlive any other QObejcts in your app. Apart from that there are no restrictions on where you put it.
WinMainis as good place as any. I had it created inCWinApp::InitInstanceand destroyed inCWinApp::ExitInstancebut I don't see a reason not to place it somewhere else.Can I then convert each GUI component one by one?
That's what I did. In my case it was a large app with dozens of docking windows so I started by creating an empty top level QMainWIndow, embedding entire MFC window as the central widget and then gradually, one by one, porting MFC windows to Qt docks and dialogs. It's tedious but keeps the app in working condition throughout the process.
What issues do I have to watch out for - I'm sure there are loads!
Too many to list. Seriously, it's nerve wrecking. The problem is that you have two large frameworks constantly fighting for system events and Windows messages. The toughest ones for me were focus related - widgets loosing focus, focus switching endlessly in loops etc. The other annoying type were window ordering related - modal dialogs stuck under the main window, MFC windows flickering, Qt overpainting parts of MFC windows, that sort of things. The third is events getting directed to the wrong system and vanishing without trace. Really hard ones to debug.
Are there any useful/essential tools to get this done? I've seen a mention of something called "Windows Migration Framework" - is this still appropriate?
I started with that QtWinMigrate lib from the repo you mentioned but it's old and not maintained. At the time I needed it it didn't even support Qt5 (I think it was later updated a bit) so I had to add that myself. I had to modify it so much that soon I basically knew it by heart and decided to get rid of it entirely and use my own custom helper functions cut for my specific needs.
Are there any extended docs on using it apart from the readme, or do I get "get stuck in"?
Maybe. I don't know any. I'd suggest to just read and learn the code of that library. There's not that much of it but it touches upon a lot of stuff that you'll have to internalize anyway if you plan on having that Frankenstein's monster for some time.
-
I went through porting a humongous app from MFC to Qt and while it's not a very pleasant process it's quite doable. Depending on the size and complexity of your app it might range anywhere from easy to not worth the effort. In my case it took about 2 years and cost me pretty much most of my hair. After 5 years there are stil bits and pieces of MFC left but that's just because nobody has energy left to clean it up :P To answer your questions:
Can I leave the project being started from WinMain() (for the MFC stuff) and only change to using main() once all the MFC code has been removed?
Yes. You need to provide the standard argc and argv params to QApplication object though. You can fabricate them using e.g. GetCommandLineA(). The tricky part is that you can't just start Qt's event loop with
exec()as it would shut off MFC, and you can't leave the MFC event processing as is because it would swallow events targeted for Qt. For the transition period you need to devise an event dispatching solution that will sort through events and send them to the correct framework. The mentioned QtWinMigrate is a good starting point for that.Do I then add a QApplication object inside WinMain?
QApplication object must outlive any other QObejcts in your app. Apart from that there are no restrictions on where you put it.
WinMainis as good place as any. I had it created inCWinApp::InitInstanceand destroyed inCWinApp::ExitInstancebut I don't see a reason not to place it somewhere else.Can I then convert each GUI component one by one?
That's what I did. In my case it was a large app with dozens of docking windows so I started by creating an empty top level QMainWIndow, embedding entire MFC window as the central widget and then gradually, one by one, porting MFC windows to Qt docks and dialogs. It's tedious but keeps the app in working condition throughout the process.
What issues do I have to watch out for - I'm sure there are loads!
Too many to list. Seriously, it's nerve wrecking. The problem is that you have two large frameworks constantly fighting for system events and Windows messages. The toughest ones for me were focus related - widgets loosing focus, focus switching endlessly in loops etc. The other annoying type were window ordering related - modal dialogs stuck under the main window, MFC windows flickering, Qt overpainting parts of MFC windows, that sort of things. The third is events getting directed to the wrong system and vanishing without trace. Really hard ones to debug.
Are there any useful/essential tools to get this done? I've seen a mention of something called "Windows Migration Framework" - is this still appropriate?
I started with that QtWinMigrate lib from the repo you mentioned but it's old and not maintained. At the time I needed it it didn't even support Qt5 (I think it was later updated a bit) so I had to add that myself. I had to modify it so much that soon I basically knew it by heart and decided to get rid of it entirely and use my own custom helper functions cut for my specific needs.
Are there any extended docs on using it apart from the readme, or do I get "get stuck in"?
Maybe. I don't know any. I'd suggest to just read and learn the code of that library. There's not that much of it but it touches upon a lot of stuff that you'll have to internalize anyway if you plan on having that Frankenstein's monster for some time.
Dear @Chris-Kawa
I have very similar project, a very old project in MFC (maybe ~20 years) that is run on WinCE need to migrate to Qt6 to be able to run on Linux on different hardware too (Toradex board).
Here are numbers about this code:
~79k LOC VC++/MFC
~500 source files across 4 modules
~35% UI-heavy MFC code requiring redesign
~65% potentially re-usable backend C++ logic, but on different hardware can be challengeNot sure how big was your project that was needed to be migrated 2 years. If you will be remember, how big was your project in LOC, I will appreciated it a lot, just to know for orientation.
And does your migration was only in the code, or maybe you have needed to change the operation system or other environment during this migration?
Thanks in advance for your assist here
-
Dear @Chris-Kawa
I have very similar project, a very old project in MFC (maybe ~20 years) that is run on WinCE need to migrate to Qt6 to be able to run on Linux on different hardware too (Toradex board).
Here are numbers about this code:
~79k LOC VC++/MFC
~500 source files across 4 modules
~35% UI-heavy MFC code requiring redesign
~65% potentially re-usable backend C++ logic, but on different hardware can be challengeNot sure how big was your project that was needed to be migrated 2 years. If you will be remember, how big was your project in LOC, I will appreciated it a lot, just to know for orientation.
And does your migration was only in the code, or maybe you have needed to change the operation system or other environment during this migration?
Thanks in advance for your assist here
I no longer work in that code base, so can't give you numbers, but it was the editor part of a AAA game engine developed for over 20 years. It was significantly larger than the numbers you quoted for sure. I'd say probably around 100 windows with very custom controls, like timelines, graphs, complicated property lists, tree views, and interop with things like DirectX (way before it was directly supported in Qt). It was Windows only, no switching platforms or OSes. The logic was reasonably well separated from the MFC UI, but the whole system was getting a redesign, so we rewrote I'd say 70% of it anyway. It was also a jump from C++98 to C++11 and C++17 later on. The build environment also changed during the switch to Qt (from custom inhouse solution to a heavily customized premake variant), so there was some work there too, but peanuts compared to the port itself.
You could probably look up LOC numbers for similar projects like Unreal Engine or Unity for a size estimate.On the bright side I heard from colleagues who still work there that they finished the port (removed MFC entirely), and even ported further from Qt 5 to 6, so it's possible :)
