Programming MFC applications

June 7, 2009 3:16 AM

Where can I find good information about programming with C++/MFC in Visual Studio?

I've currently found myself in a job where I'm doing a lot more (small-scale) software development than I expected. This is not too bad, as I have a reasonable programming background. However, one of the things I haven't done much/any of is gui-based programming.

Where I'm working currently seems to mainly focus on MFC-based programs, which I have minimal clues about, so I'm looking for resources to help me get going. I tend to work best off of basic sample code sets, and can extrapolate pretty well once I've figured out the baseline things like "How do I get this button to open up a new window?" (this is a particular sticking point for me at the moment) or "How do I make a slider bar that will affect this picture here?"

I'd prefer digital resources, as I'm in Japan and getting English books is a bit of a pain (and I'm not sure I'm up to the level of comprehension that's required for Japanese programming manuals), but if there's one out there that's really good, I would be up for considering it.

posted by that girl to Computers & Internet (16 answers total)

I wrote a few MFC apps like, maybe 12 or 13 years ago. I don't even remember how I learned it, I think it was mostly just from the documentation and the fact that VC++ would generate some of the code for you. I moved to java soon after that and never really went back to MFC. If I needed to do some windows programming, I just stuck with pure win32, rather then trying to use various frameworks (but opening windows and creating guis that way is a pain)

You really should consider other options as far as doing GUIs. Doing a simple form based GUI in C# is so easy, and you can always link to your C++ code using a DLL.

I realize if you've got to maintain old code, you've got to maintain old code, but you really should try to escape!
posted by delmoi at 3:28 AM on June 7, 2009

Nota bene: MFC is a world of pain, but is the language of 90%+ of what was written in the 90s, especially in Japan.

If you want books you could try O'Reilly Safari Online. Looking at their MFC Programming search category returns I see two books:

Programming with Microsoft Visual C++ .NET
by George Shepherd; David Kruglinski
Publisher: Microsoft Press
Pub Date: October 25, 2002
Print ISBN-10: 0-7356-1549-7

Visual C++® 6 Unleashed
by Mickey Williams; David Bennett
Publisher: Sams
Pub Date: July 24, 2000
Print ISBN-10: 0-672-31241-7

The only people programming in MFC these days are people who have to.

For me, just googling functions and issues got me enough answers. That's the good side of MFC, everything's already been done in it and the code is out there somewhere.
posted by @troy at 4:04 AM on June 7, 2009

Response by poster: I realized the "Ugh, why are you programming with MFC?!" questions would pop up. I am also dealing with a mysterious proprietary API and some other code written in MFC, and no wherewithal to get development software for another language. Also OpenGL. Which I have pretty minimal knowledge of.
posted by that girl at 4:28 AM on June 7, 2009

The Petzold book got me through some rough patches. There's a good reason why it used to be called "the Bible" of Windows programming. It's mostly about the Win32 SDK but has a few chapters on the MFC. I also learned enough about GDI from it to become a danger to myself and others. It's definitely good enough to have shipped to Japan and I doubt there's a digital version of it (although...torrent?). It also makes a great weight if you're gluing something - that sumbitch is heavy!

A lot of your this-or-that problems can likely be solved with stuff like groups.google.com or forums geared specifically toward MFC/Win32. They're out there. MSDN is good, too. You can blow the cobwebs off their MFC reference section. Then there's this.

If you realized the "ugh, why MFC" responses would come up, why didn't you deflect them in the original question? MFC pretty much sucked ass to begin with, and it sure hasn't gotten better with age. From a broader perspective: development in any long-abandoned framework sounds like an extremely bad idea. You're not doing new development in it, are you? You're maintaining old code, right? You're much, much better off using VB (not .NET..blechh) or some other RAD tool instead of going on archaeological digs through ancient, scary Microsoft cruft.
posted by ostranenie at 5:57 AM on June 7, 2009

Response by poster: I guess I got the impression they would show up, but I don't really know enough about GUI programming to know just how much people would object to MFC.

So, to take this another direction, if I wanted to use some other framework for GUI programming that would play nice with OpenGL and a C++ API, what would be a reasonable choice that wouldn't require me trying to get my employers to pay for a software license for me (Large Japanese company bureaucracy is even worse than large US company bureaucracy)? Since I know so little about MFC, and I do have to do some other original development, I am open up to better suggestions that have good sets of sample code and documentation.
posted by that girl at 6:27 AM on June 7, 2009

if I wanted to use some other framework for GUI programming that would play nice with OpenGL and a C++ API, what would be a reasonable choice that wouldn't require me trying to get my employers to pay for a software license for me

Qt 4.5 is free, written in C++, runs well on Windows, and is far and away the best GUI toolkit since the BeOS API.
posted by cmonkey at 7:31 AM on June 7, 2009

Oh, and it has OpenGL support, too.
posted by cmonkey at 7:34 AM on June 7, 2009

If we're going to be recommending stuff that isn't MFC, DevC++ is my first choice. OpenGL is semi-supported as well. It's also free. Debugger, linker, compiler, all-inclusive. You do have to know just a little about Win32 SDK development, though.

C++ isn't an API--it's a language
posted by ostranenie at 8:23 AM on June 7, 2009

The MSDN documentation has always been a good reference. The website has the same content but if you have access to the local install, that's better. CodeProject.com has been a staple as well. Unlike Qt, MFC was so widely used there's tons of online resources out there.

For OpenGL, the Blue Book and Red Book are the official documentation I think. MeFi mail me if you think they'd be useful. CodeProject and CodeGuru sites had some examples/tutorials on integrating OpenGL with MFC last time I used it. Same as MFC, it has a large enough development base that there's lots of tutorials online.
posted by hungrysquirrels at 8:53 AM on June 7, 2009

ostranenie, are you comparing apples and oranges? DevC++ appears to be an IDE, but that's not a direct alternative to the MFC library. Am I missing something? (On the other hand, DevC++ might make a fine alternative to Visual Studio.)

(Also, on "C++ isn't an API comment": libraries may have APIs in many language, one of which may be C++, which that girl is saying is a requirement.)
posted by IvyMike at 12:46 PM on June 7, 2009

MFC is a major pain. I hacked on a pretty established MFC codebase for a while, and in some ways it's easier than trying to start a project from scratch - following examples already in the code is really the best thing to do, because most things you'll do in maintaining an old system will be simple extensions & bug fixes. Every book on MFC I've seen has been crap. Just read MSDN and look through their samples, and try to find someone who's been doing MFC for a while to ask conceptual questions. Make sure you understand all the different views, make sure you understand MVC, etc. Re your current sticking point, there's no one way to do this. It's easy if you're opening up a dialog. It's easy if you're making a new document through MVC. It's not so easy if the window you want to put up doesn't conform to one of these ideas. Basically, MFC wants every application you write to be like Excel or Word, so if you think about it in terms of that context you'll do a lot better.

For OpenGL, the red book & blue book are actually very good. Getting used to the state-based nature of it can be a struggle, but once you do that the rest is really just looking up functions and seeing what other people use.
posted by devilsbrigade at 1:08 PM on June 7, 2009

Also, Qt is very nice, but I think they're still charging for commercial licenses (i.e. if you your program can't be GPL). If this is for internal use, GPL will be fine and Qt would be a good alternative. Commercial licensing gets spendy fast, though, so if you're distributing these as closed-source you may run into trouble there. It also introduces an extra build step, which some people really dislike. It does have good integration with OpenGL, though.
posted by devilsbrigade at 1:14 PM on June 7, 2009

> are you comparing apples and oranges

No, the OP opened it up to non-MFC recommendations for "frameworks." I took that to mean IDE. Someone else recommended Qt.

C++ still isn't, nor will it ever be, an API.
posted by ostranenie at 1:35 PM on June 7, 2009

Also, Qt is very nice, but I think they're still charging for commercial licenses (i.e. if you your program can't be GPL).

They eliminated the "commercial licensing component" with 4.5. As the download page says, the LGPL version can freely be used to create proprietary software. The only time someone needs a commercial license now is if they wish to modify the Qt codebase and not distribute those changes.
posted by cmonkey at 1:40 PM on June 7, 2009 [1 favorite]

Response by poster: ostranenie: I am very aware that C++ isn't an API, but the API I have to work with is written in/for C++, which is what I was trying to get across.
posted by that girl at 4:06 PM on June 7, 2009

DevC++, Qt, and Visual Studio (ugh..megabloat) all should work for your C++-requiring API. I recommend DevC++ because I was able to fire it up and change one line of code from an old VS6 project I hadn't worked on in years, and needed to work in an OMG!emergency, and it compiled and linked with zero problems. I am never going back to MS unless I have to. But then I don't develop software for a living, so...trailoff.

You might have some luck with The Code Project. That place has saved my bacon on more than one occasion with their examples on how to do things like interface with the MS Video For Windows API and use ActiveX controls in C++ without resorting to using MFC. It's got some pretty amazing tutorials on every level and typically has an individual support forum for submitted projects. static_cast<> once got me out of an annoying jam, and I probably wouldn't have 'gotten' it nearly as quick if not for the pros on codeproject.com.

I can't recommend the Petzold book enough - it helped me understand Windows and they way it works on more than one occasion. Although the material in it wasn't so widely available back when it was published, I'm sure you can find everything and then some on the internet nowadays.

For GUI things in Win32 (non-MFC) - it's not as hard as it seems, although it's sort of antiquated what with all the .NETtery and such going around. The resource manager in VS is similar to the one in DevC++ and I'm guessing Qt has something similar. If you're doing straight-up Win32, you need to know that all the controls in a window have handles (unique identifiers or HWNDs) and they are themselves "windows" that are children of other "windows." You open a dialog window with a function like DialogBox that references a resource ID in your resource manager in your workspace. You send messages to and get feedback from all of the separate dialog controls with calls like SendMessage and GetWindowText. You figure out their HWNDs are with things like GetDlgItem. (And then there's WM_PAINT, which is a whole 'nother nightmare.) Typically a dialog has a procedure associated with it that has a switch() statement that figures out what control was pushed/moved/whatever and gets further data from that control (like what position on the slider bar you moved the slider to, or whether the checkbox was checked). As painful as all this is, it'll never be as bad as locking yourself into the MFC and finding out you just can't do something the way you want it to be done.

MFC GUI programming is much different and much more 'direct.' You typically 'push to' and 'pull from' dialogs' controls with a function called UpdateData. It was supposed to solve problems with portability and abstract away some of the more complicated parts of the Win32 API but sometimes caused bizarre hard-to-explain compile-time errors, especially when you modified the automatically generated code the compiler put out. Glancing at the Wikipedia article, apparently the MFC is still around (unfortunately).

The MSDN (online and offline) has examples galore of doing things like setting properties and displays for progress bars, image windows, buttons, combo boxes, list boxes and the like. You know, or you could just go with something like WxWidgets or FastGraph or Windows Forms and sidestep the whole "help, my GUI programming is stuck in 1997" thing.

Personally, I suggest you fire up DevC++ (which takes almost no time to install) and write some stub test code that interfaces with your mystery guest API. If it compiles, links and debugs with no problem, keep going down that road. If that doesn't work, maybe look into Microsoft Visual C++ Express along with the Windows Template Library (WTL) and its associated help files.

Or you might consider writing an ActiveX DLL in C++ that interfaces with your mystery API, and call same from a VB or RealBasic program.

Run, run from the MFC!
posted by ostranenie at 8:13 PM on June 9, 2009