CODEWITHSUNDEEP
c++visual-c++user-interfacemfctouch
Fastuous
Fastuous

Reputation: 11

Porting C++ w/ MFC to a Touch Screen

Looking for a GUI framework to use with C++ to "modernize" an existing interface for touchscreen.

I'm a novice programmer with a background in C++/Java that was just assigned a project that involves taking an existing C++ program using MFC (3 data views, multiple text/radio controlled dialog boxes, etc.) and redesigning the interface to be "touch-screen friendly" such as larger button controls, sliders and whatnot.

I've been given pretty free-reign with instructions to make a "more modern looking interface" as opposed to the typical bare-bones MFC I've been given. I know I have quite a bit to learn either way, so any suggestions are helpful.

So far the options I've come up with are:

  1. MFC just tweak existing controls to accommodate touch input, keep crappy looking interface.
  2. Managed C++ or C++/CLI figure out how to keep the underlying C++ structure while being able to design a new interface with WPF or Windows Forms.
  3. Qt completely new to me, but seems a promising alternative.

Really I just need to find a way to make this program look like it wasn't written over 10 years ago, and so far in teaching myself MFC, it doesn't seem that flexible in terms of incorporating any sort of graphic-design/themes.

Are there other alternatives I should be looking into? Is there more to MFC than meets the eye and I just need to learn more about it? As I said, any suggestions of things to look into are helpful.

Upvotes: 1

Views: 2312

Answers (1)

Jerry Coffin
Jerry Coffin

Reputation: 490338

What you've listed as #1 could really be either of two approaches. One (call it 1a) is to continue using the same version of VC++ and MFC as the original, and do only the bare minimum of editing to increase the sizes of the controls where needed. Short of encountering some fairly bad luck in how the existing code is written, this might not involve any real programming at all, and would be relatively quick and easy.

The second (call it 1b) would be to do the update using the current version of VC++, MFC, etc. This would probably involve some code updates, but probably not anything terrible (though if it's much more than 10 years old, significant code updates could be needed as well). With some care, you may be able to update the UI quite a bit (e.g., change from menus to ribbons, include color theme support), still with fairly minimal investment.

Your #2 could easily end up as nearly a complete rewrite. Despite superficial similarities, C++/CLI is a completely different language from C++. The only way this really makes sense is if you have quite a bit of non-UI code you can leave alone completely, and use C++/CLI exclusively as a "bridge" between existing C++ and a .NET UI (and the UI is fairly minimal, so the rather mediocre tool support for C++/CLI doesn't cause a big problem). If your UI is any more than fairly trivial, C# has enough better tool support that it may easily be a better choice than C++/CLI.

Your #3 will probably require only marginally less rewriting than 2, at least of the code that's related to the UI. While the code would remain C++, Qt is quite a lot different from MFC. The big advantage would be if you (might soon) want to support something other than Windows (e.g., iOS or Android). For portability, Qt has a huge advantage over any of the alternatives you've named.

A lot comes back to a question of how much C++ code you can retain intact. If you have a lot of code in an "engine" that's cleanly separated from the UI, and a fairly simple UI, then retaining that existing code make a lot of sense, and rewriting the UI from the ground up isn't all that terrible of a problem. On the other hand, if the UI and business logic code are heavily intertwined (fairly common) then any more than really minor tweaks to the UI is likely to me significant rewriting of the rest of the code as well.

Conclusion: if the UI is heavily intertwined with other code, your only real choice is between 1a and 1b. If the UI is easily detached from other code, the choice between 2 and 3 is (at least to me) primarily one of whether portability is at all likely to matter (now or any time soon).

Upvotes: 3

Related Questions