23

https://stackoverflow.com/questions/149698/what-is-a-good-mfc-starting-book

A lot of the upvoted comments claim there are much better alternatives. I'd like to know what they might be.

My main requirement is that the UI use the native widgets so that our automation software can work. Owner drawn windows are much harder to drive.

I'm not particularly liking the design of MFC so an alternative would be good. Only one I've found is WX, which is the one we've already tried and are considering abandoning. We need something that doesn't force us to fight with a bunch of cross-platform wrapping we don't care about. We're writing a Windows application and marketing doesn't give one single crap about targeting Mac or Linux (yeah, it makes my butt hurt too).

I've looked at the .NET option a little bit. Problem is I don't know much about it but from what I can tell we'd have to use C# to get a lot of the options readily available with MFC. The C++/CLI toolkit doesn't seem to have docking windows on first glance for instance. In fact, a straight up WinFroms option doesn't seem to either. It looks like we'd have to make a WPF project and that doesn't appear to be at all what we really want (and we'd have a huge bunch of crap to learn besides just another toolkit). Moving out of C++ would also require a lot of wrapping and I don't particularly like the results I've seen from automated wrappers.

The other issue I have with the .NET option is that we've got a pretty drawing intense application (in addition to requiring a lot of forms). I know that you can get similar results with JIT languages like .NET but I also know you've got to be a lot more careful to do so. It's an issue I'd like to avoid worrying about at this time.

The other, and probably most important issue with .NET (at least switching languages) is that we've got a huge supply of interface logic that though should be API agnostic, is very much written in C++.

So what are the other options? Do these people really have points or are they just yelling against anything that isn't their favorite language or toolkit?

NOTE:
What is the issue here?? I said specifically that porting to other platforms is NOT even remotely a consideration and that I HAVE TO HAVE something that uses the native widget set so we don't have to completely change everything that testing uses to automate the product!!!! Did anyone actually read my question?

Community
  • 1
  • 1
Edward Strange
  • 40,307
  • 7
  • 73
  • 125
  • 5
    Personally I don't find MFC that bad. It's a little outdated and it's documentation isn't always great but I like the source code compared to Qt which I think is a mess to understand. When having to debug, being able to understand how it work under the hood can be nice (even if you loose some of it when MFC call windows functions which don't have sources). I don't have experience with other framework but I just wanted to say to not discredit MFC too fast. It's not really that great but it's not bad either. – n1ckp Nov 03 '10 at 17:53
  • Mostly I'm trying to find alternatives. There is one thing that bothers me a great deal about MFC though and that's the fact that you can't seem to attach external handlers to it. "Message" handlers have to not only be in static maps, they have to be members of the visual class you're creating. You can't create compiler firewalls by having behavior governed by objects invisible outside the .cpp file. True encapsulation is not available. Also not a fan of some objects being self-deleting and others not...just learned that one yesterday. Lack of layout managers isn't great either. – Edward Strange Nov 03 '10 at 18:07
  • Roberts: Well, I'm not totally sure about your objection but I think you can bypass using static map with overidding some MFC function (take a look at http://stackoverflow.com/questions/978071/how-to-redirect-mfc-messages-to-another-object). Also for the object self-deleting, I think Qt is worse on that aspect. I'm not trying to sell you MFC though, I would be happy to have a good alternative too. My experience with Qt was from taking over from poor programmers using it so I have a little bias but it didn't really convince me it was better (I'd say equivalent maybe?). – n1ckp Nov 03 '10 at 22:08
  • sorry of this is too late. Qt has a bunch of Gui testing tools I think the leading one is called squish. The signal/slot mechanism is perfect for allowing a testing tool to hook into gui events at run time – Martin Beckett Dec 02 '10 at 17:42
  • The other annoyance with MFC is that you have to use a Pro version of Visual Studio, not one of the free ones. With Qt you can use Visual Studio Express or Qt Creator (their own IDE) and they're all free. – parsley72 Dec 04 '13 at 19:42
  • Better late than never! wxWidgets is cross platform, and still maintained. http://www.wxwidgets.org/ – SingleStepper Jul 23 '14 at 14:03
  • 1
    I would recommend Win32++ ([win32-framework.sourceforge](http://win32-framework.sourceforge.net/)). –  Nov 10 '10 at 20:23
  • I just ran into this post a bit too late in the day but have you considered this? http://torjo.com/win32gui/ – ForeverLearning Feb 03 '11 at 13:28
  • In my opinion, Qt is so much better than MFC. – shan Sep 18 '20 at 06:05

6 Answers6

13

Qt is the only real answer for a C++ based gui toolkit at the moment (at least for full desktop apps). Even for purely windows apps it's worth it - it also has excellent integration with visual studio (get the vs-addin) and is very well documented

wx has some nice points, one being it's very similar to MFC in use, but with Qt going LGPL wx's real advantage has been lost.

Edit Qt widgets aren't native HOWEVER they do use the native styling APIs so that they are indistinguishable from native widgets - if you use the default styles.

Martin Beckett
  • 94,801
  • 28
  • 188
  • 263
  • Does QT use the native widget set? – Edward Strange Nov 02 '10 at 17:53
  • 1
    @Noah: no, Qt has it's own set of widgets, its a very good one. – Paulo Scardine Nov 02 '10 at 18:03
  • @Noah, Qt doesn't use native widgets, but it renders the widgets Windows-like by default, on Windows. – Nick Dandoulakis Nov 02 '10 at 18:04
  • 3
    Then this answer is a non-answer. Why is it upvoted? – Edward Strange Nov 02 '10 at 18:06
  • If a widget looks like a native widget and behaves like a native widget is it still a duck (sorry got my metaphors mixed up there) – Martin Beckett Nov 02 '10 at 18:36
  • 11
    You forgot to mention the other negatives of Qt: ugly auto-generated source files, the extra build step for MOC, need to use custom build or makefile for all projects in VS, no use of RAII, tries to reimplement the entire standard library, etc. etc. – Inverse Nov 02 '10 at 18:50
  • @Inverse - almost every UI toolkit I've run into has most of those problems. The only exception is that the moc step is fairly unique to Qt. Not a huge deal if VS can drive it from the command line (build server still has to work). The main issue is whether or not spy tools and such work effectively on it, which I am checking but I'm seriously doubting. No other owner drawn widget set has managed it. – Edward Strange Nov 02 '10 at 19:06
  • 3
    You don't have to use the Qt collection classes, and MFC also implements it's own version the STL (badly). The moc step is no issue with the VSS addin and is less of a problem than MFC resource compiler - at least the output of the Qt one is executable code. Yes today there are boost alternatives to signal/slot but Qt is still nicer and a lot more capable than MFC macros. – Martin Beckett Nov 02 '10 at 19:33
  • Well, it looks like Qt might actually be a viable answer. It does indeed implement enough to be drivable, or so the testers are telling me. – Edward Strange Nov 02 '10 at 20:12
  • @noah - buy the book "c++ gui programming with qt4" it's worth it. Take a look at some of the sample apps. The program structure app->frame->widget is a little different to MFC and the signal/slot stuff is new until you get it. – Martin Beckett Nov 02 '10 at 20:16
  • The accessibility plugin has to be used to enable testing and some widgets, like MDI, are broken when that plugin is used (easy enough to roll our own with the tab widget instead). The VS plugin isn't what I'd call "excellent", but it's OK and certainly better than hand/entering all the custom build steps. I was able to convince the PHBes to choose it. – Edward Strange Nov 17 '10 at 20:39
  • I really think that the Qt does not have alternatives. It's layout managers are amazing... – shan Sep 18 '20 at 06:17
4

Windows forms will work just fine with C++/CLI. Windows forms also happens to be a wrapper around WIN32 handles.

There's no difference in the capabilities of C#/Windows Forms compared to C++/Windows Forms. (They just compile differently) Just like you can do the same things with C# and VB.NET...

If you're looking for docking windows, there are a number of third party libraries that do this. (Some are open source, some you can buy.) Because of the CLR, you can directly include assemblies written in a different language.

Matt Brunell
  • 10,141
  • 3
  • 34
  • 46
3

MFC wasn't bad in its day but it is getting a bit old. A good example would be the collections which have been replaced wit the much better STL collections. However you were asking about GUI stuff. There's the WTL (Windows Template Library) which I believe has now been open sourced. Much lighter footprint than MFC but it is designed to work the same way - eg. Most of the classes have the same names and method names.

On the downside I've found documentation relative scant and it doesn't seem to work well with the Visual Studio Wizards. This could be my problem though - getting it work with the VS wizards would be quite important IMHO.

winwaed
  • 7,645
  • 6
  • 36
  • 81
  • 3
    It is my understanding that WTL is actually a wrapper for ATL, which is made primarily to make writing COM things easier. We'll need to converse with COM objects in a few very localized areas but not as a whole. The lack of support and documentation worry me. I'm also concerned that it doesn't include support for the "2008 feature pack" elements, which we're definitely going to use a lot. Am I wrong about any of these things? – Edward Strange Nov 02 '10 at 18:11
  • 1
    +1 for actually answering the question asked. – Edward Strange Nov 02 '10 at 18:11
  • Re. Support for new features: Quite possibly, I haven't used WTL in anger for a few years, so I couldn't say either way. For new dev I switched to the dark side (C#) which has some nice GUI elements. – winwaed Nov 02 '10 at 18:25
3

I'm in roughly the same position: large app, native code, using MFC for the front-end. I don't see any really compelling alternatives, or reasons to switch to anything else.

That being said, let me offer an opinion. If I were doing a new project, which needed to preserve/inherit a lot of native code, I'd consider trying to do a WPF front-end with a largely native (C++/CLI) main application. This was done with Visual Studio 2010, and it's mostly performant, so it's at least possible. WPF has some UI benefits, and it might be easier to work on and test (from an automation perspective), since it is CLR code. I'm not sure it would be worth the investment and learning curve, but it's the alternative I would consider for a modern pure-Windows application with lots of native code.

Hope that helps.

Nick
  • 6,808
  • 1
  • 22
  • 34
2

To offer something I didn't see mentioned in the other answers:

From the sound of it, your only reason for needing native controls is that automation software. And the only reason for needing that automation software to work is for testing. I would assume some series of automated tests are being used to ensure the software works as intended.

If that's the case, then here is something to consider: There is a reasonably popular design pattern in the C#/WPF realm called Model-View-ViewModel. Without getting into excessive detail here, the basic idea is that you can separate the actual GUI controls (the View) from the code that handles how those controls interact with the rest of the business logic in the application. That code is the so-called ViewModel. Among other things, this lends itself to designs where that ViewModel (and all the rest logic of the application) can be tested through typical unit-testing methods without actually needing GUI controls to be present.

So whatever testing the automation software is used for could potentially be replaced by straight unit-testing code.

However, my own experience in this realm is not nearly as extensive as I would like. So if you consider this at all, I strongly suggest further research. As a start, googling terms like "Model-View-ViewModel" and "MVVM" should eventually yield some more detailed discussions about that part.

TheUndeadFish
  • 8,058
  • 1
  • 23
  • 17
  • MVC is a very common and old method and we use it quite a bit. It would be unit tested if I hadn't been told to cut corners :\ But even with all the unit testing in the world there are two issues: 1) The view code cannot be unit tested. 2) you still need acceptance and integration testing. Like unit tests they should be automated and run at least on every potential release (which is every night or so in an agile method). Even with everything seemingly working perfectly when apart you can miss stuff that only turns up in use and you still want that fast feedback that automation offers. – Edward Strange Nov 05 '10 at 15:57
1

I've seen Qt used fairly extensively. I personally have not used Qt, but I see a lot of questions about it, far more than wXwidgets or MFC. I'd start with that.

Puppy
  • 144,682
  • 38
  • 256
  • 465