Migration from MFC to CopperSpice

[w.liebhart@web.de]

Hi there.

I have some questions about migrating our code from MFC to copperSpice.

Our company, Cremer Programmentwicklung GmbH (cremer.software), has been developing and marketing a surveying and civil engineering CAD program for over 25 years.
We use the Windows MFC libraries and would like to migrate to a more modern, platform-independent framework.
We have a fairly large program with more than 800 dialogs and there is a fairly strong interlocking of our interface with the viewing windows.
We are aware that migrating the MFC libraries to your framework is a huge task, but it is necessary.
How much experience do you have in this area with other customers?
Do you think it is possible to migrate our code bit by bit and we can provide new features to our customers at the same time? So our whole program is available with the new interface and there are both new and old dialogs in this package?
Are there any detailed guidelines for the migration? Can we expect support from the community?
Are there any examples of CAD like programs developed with CopperSpice

Thanks for your answers,
Best,
Werner

[barbara]

Werner,

Thank you for reaching out to our team. We are looking forward to working with you and your company.

I have migrated an application from MFC to use the CopperSpice libraries. All of the GUI windows had to be re-implemented and there are two ways to do this. I choose to use our CsDesigner program which is a drag and drop GUI design tool. The other approach is to lay out each window by hand. Both work and you can mix and match. This is really about preference.

The business logic can usually be carried over. Since this code is typically old, it might make sense to take this as an opportunity to improve and optimize the business code.

We have a lot of experience in the area of migration and can provide guidance or consulting services if that is something your company is looking for. Support contracts are also available for CopperSpice at a variety of different levels.

Do you think it is possible to migrate our code bit by bit and we can provide new features to our customers at the same time?

As you may know, you can not link an application with both MFC and CopperSpice. You can migrate parts of your older application to use CopperSpice based on which sections your users need more quickly. One consideration is if the two projects will need to share user data.

Yes, you can always add new features or capabilities to the CopperSpice application which are not present in the MFC project. This is in fact what I did when migrating from MFC.

Are there any detailed guidelines for the migration?

We have documented how to migrate a Qt application to CopperSpice and this is available in our CS Overview documentation.

https://www.copperspice.com/docs/cs_overview/cs-migration.html

Can we expect support from the community?

There is a community of other developers available to answer questions. As you proceed with this project we can ask other users to provide some input.

Please feel free to ask any other questions which you may have.

Barbara
CopperSpice Co-Founder

[w.liebhart@web.de]

Thank you very much for your intresting reply, Barbara.

You wrote:
"As you may know, you can not link an application with both MFC and CopperSpice. You can migrate parts of your older application to use CopperSpice based on which sections your users need more quickly. One consideration is if the two projects will need to share user data.
"
Do I understand correctly that there is no possibility to migrate our complete code including the MFC application to CopperSpice? It would be good if there was a possibility of a smooth transition: We would like to be able to compile our complete source code in the CopperSpice application. We will then gradually translate the most important parts of the program. Our customers can continue to use our complete program, partly with the old MFC dialogs and partly with the new CopperSpice dialogs.
If I understand you correctly, this is not possible?

Are there examples of Copperspice applications in the field of CAD? 3D Applications?
Are there any Links with examples of appearence of the CopperSpice Userinterface?

Thank you very much,
best,
Werner

[ansel]

CopperSpice is a set of libraries. The GUI library contains a large number of widgets and controls. Our KitchenSink application consists of over 30 different examples showing how to use things like a text box, calendar, list view, sliders, group box, buttons, and a lot more.

You can download a pre-built version of KS from our download page or build it from source via github.

https://download.copperspice.com/kitchensink/binary
https://github.com/copperspice/kitchensink

We also have our “CopperSpice Journal” which is a blog containing articles about using the CopperSpice libraries. We have over 40 entries with full source code and text explanations. The following is a partial list of the samples.

• User application with a Menu Bar and a Toolbar
• Setting the Tab Order for Controls
• Render a Polygon and Other Shapes
• Syntax Highlighting
• Resource Files (.qrc)
• Split Screen, Tab Control, Calendar
• Language Translations
• Spin Box, Progress Bar, Slider, and a Dial
• How to compile a CopperSpice Application

https://journal.copperspice.com

The complexity of a CopperSpice UI is determined by the requirements of your application and the imagination of your team.

[barbara]

Do I understand correctly that there is no possibility to migrate our complete code including the MFC application to CopperSpice? It would be good if there was a possibility of a smooth transition: We would like to be able to compile our complete source code in the CopperSpice application.

MFC is a C++ library which contains classes, methods, and functions. This library, like almost every other GUI library, has functionality to dispatch messages (often referred to as events) for processing things like mouse clicks, a keyboard press, drag and drop, timers, screen painting, etc.

Having two GUI libraries in the same application which are both trying to grab events simply does not work. This is not a flaw with CopperSpice or MFC. There needs to be one entity in charge of event handling and there is no way to share this responsibility. The bottom line is the MFC library can not interface or interact with the event handling of any other GUI library.

If your company is going to migrate from MFC (which we believe would be very beneficial) then you need to consider how to do this in smaller pieces. I have done this several times and it does work. We are happy to continue discussing this process with you.

Barbara

[w.liebhart@web.de]

Having two GUI libraries in the same application which are both trying to grab events simply does not work. This is not a flaw with CopperSpice or MFC. There needs to be one entity in charge of event handling and there is no way to share this responsibility. The bottom line is the MFC library can not interface or interact with the event handling of any other GUI library.

I'm quite surprised about this answer.
I found a quite detaild description of migrating MFC to WxWidgets (https://www.youtube.com/watch?v=f3wgn6vP_XQ) and migrating MFC to Qt (https://www.youtube.com/watch?v=mlEbOcC1GJI). Both talks describe how to have parts of the old code (whole dialogs) in a running application of Qt or WxWidget. There is also discussed the problem of event handling. So it should be possible to migrate our source code (more than one million (> 1 000 000) lines of source code) incrementally to the new framework.

What is so different with CopperSpice?

[barbara]

As you may know CopperSpice is a derivative project of Qt. They diverged over time but their origins are similar.

Let me summarize some of the missing details.

(1) Libraries like MFC and WxWidgets will draw objects using native calls. Libraries like CopperSpice use custom drawing which is more flexible. This might result in having some widgets which do not have the exact same look and feel.

This will not be an issue when all of your Windows are moved to the new library. However, having a user see Window A and Window B with some differences or a few pixels off, will look a bit unprofessional.


(2) Think about what happens during a drag and drop event and now add the complexity that you want to drag from a Window drawn with CS onto a Window drawn with MFC. Will the two libraries use the same data format? How are you going to tell CS not to process this and let MFC handle everything?

First issue is how to pass the information. This can be solved using COM or some other interchange protocol. The CS application may need to reformat the event and then pass it. Then you need to update your existing MFC code to receive the drag/drop event and process it. What if you need to pass something back to the CS application?

This is doable however you will need to keep changing your MFC application to handle anything that should not be worked out in the CS application.

All of this would apply just the same if you move to WxWidgets or Qt.


(3) Using a foreign window might sound like a simple solution, however now you are dealing with embedding windows and passing more data back and forth. It could work but for our many years of experience in the GUI world the amount of testing is through the roof.

You can create a Window in CopperSpice and pass the native window id, just like in Qt. However we discourage using this approach.


(4) Did you create your Window layouts using direct calls to MFC? If so, translating the GUI part might only require writing a small parser. If you used a drag and drop layout it could be a bit more complicated, but not impossible.


(5) We did more research and in almost every case someone reported getting just so far and then encountering data which did not match, undefined behavior, or inconsistencies. We understand there are videos which claim this will be an easy processes. In theory it is. However when you get down to doing the work it will get complicated very fast.

Do you really want to use COM and spend your time working on the MFC application? There will be no way around this item and it will involve a lot of re-testing on MFC side.

We understand you are tying to make a good business choice and our aim is to help you navigate this process. Feel free to ask more questions.

[janwilmans]

Dear Werner,

I hope this message finds you well.
Just a copperspice user pitching in my 2 cents:

My company did attempt a hybrid MFC - Copperspice application similar to what I think is described in the videos you linked.
While at first it seemed to work, it was very difficult to maintain and full of side-effects would could not explain or work around.
We though it might be specific to Copperspice, but we also try the same with Qt5 and the experience was really the same. So I believe it is not a Qt or Copperspice specific problem.

In the end we split the application in parts, where certain workflows where handed off to a separate process. That worked well for us and allowed us to migrate gradually, without 'mixing' the two UI libraries.

Hope this helps,

Jan

[ansel]

My company did attempt a hybrid MFC - Copperspice application similar to what I think is described in the videos you linked.
...
In the end we split the application in parts, where certain workflows where handed off to a separate process. That worked well for us and allowed us to migrate gradually, without 'mixing' the two UI libraries.

So if I understand correctly, your team decided that integrating MFC and CopperSpice in the same application was flaky and unreliable. Your solution was to migrate by splitting your application into smaller executables as the first step and then convert each independent application one at a time. Is that correct?

[w.liebhart@web.de]

Thank you very much Barbara and Jan for your opinion, there are very useful hints for me.
I'm not sure how to approach the migration and I will discuss that in my team.
Thanks,
Werner