#### Archived

This topic is now archived and is closed to further replies.

# MFC is Challenging :: C++

This topic is 5826 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi. I posted a topic regarding GUI programming using C++ a week ago. I was wonder about the best tool to learn GUI programming using C++. Most members said MFC is the best tool to for GUI programming in Windows because of it is from Microsoft. However, many members said Qt is a much easier, and ultimately, more practically GUI tool in windows. I bought a MFC book by Jess Prosise and I read the first chapter. I want to said MFC is challenging. First, I like the idea of having inherance and virtual functions and classes to control every specefic GUI feature. However, I am overwhelmed with the number of MFC classes and derived classes. There are too many classes to remember! There is not no way to really know the classes, their member functions, and the parameters for member functions. I thought it over and decided to try Qt. From its interface, Qt look much easier than MFC because the GUI items are manageable via drag-drop. The negative side I Qt is *expensive*. It is too expensive (~$2k). Secondly, I do not think the free version Qt 2.3 is not Visual C++ .NET compatible. Now I am basically left with MFC. Yes, it is intimidating me right now. I do not have problems with OOP. I am very comfortable with STL and enjoy using it to improve whatever I work on. MFC is different. Prosise present MFC as though I have to know everything about it as well as how Windows programs work. MFC is challenging to learn and implement at first. Does it get easier and *faster*? I am seriously considering using Borland C++ Builder. It has the RAD feature and I believe the GUI programming is similar to Qt. At least they look similar (drag-drop). Kuphryn #### Share this post ##### Link to post ##### Share on other sites Advertisement Most people who get the chance to use Borland C++ Builder wouldn''t touch MFC again. The only downside to C++ Builder is that the IDE isn''t quite as good as Microsoft''s. But I can''t fault it for letting me get GUI code up and running as soon as possible. [ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ] #### Share this post ##### Link to post ##### Share on other sites I agree that MFC is very challenging, mostly because there doesn''t seem to be a good source of information about all the nuances. I have the Prosise book, and it is very good, but still it takes a while to figure out how to do things. However, once you''re past the learning curve (which is steep), you can do a lot with less effort than Borland. But, you have to put a lot into it to get to that point. So, if you''re willing to make a time investment, it may pay later on. Once you''re proficient, you can use MFC to knock out a utility tool in literally hours. You definitely wouldn''t want to use it for any non-business app that involves any sort of games graphics, tho. #### Share this post ##### Link to post ##### Share on other sites You can toss an OpenGL or DirectX rendering frame onto/into any MFC window. If you were making a tool for a game, this is probably what you would _want to do. The only problem I have with BCB, is that you have to buy the$2k version to get good type library support. It comes with the $50 version from M$.

MFC definetly gets easier and faster - much like the STL.

##### Share on other sites
Yeah, there''s a lot to know in MFC. That''s because it does a lot, too. There''s a lot to remember when you learn (say) French, or Japanese for the first time; there''s a lot to learn when you learn C++ for the first time; there''s a lot to learn when you learn MFC for the first time. It''s the way of the world.

I think it''s worth it.

##### Share on other sites
To learn MFC : know it''s basic architecture tree, know its posibilities.
After this, the reference is your brother...

##### Share on other sites
MFC ain''t the end all be all (imo). For a much better argument than I could put down in a few minutes, check out Reliable Software on MFC.

##### Share on other sites
I think the answer to this question is, like most, based on what you are trying to do.

If you are just writing simple straight-forward windows ( or soon - Linux ) GUI apps I would go with BCB. It will get the job done the fastest and will look good.

If you are writing a complex, large GUI application, I''m not so sure I''d recommend BCB. The way the VCL works makes things very white-box design and would likely become very difficult to maintain.

If you separated your domain code from your GUI it would be better suited to adapting to BCB.

However, if you did that, you could adapt the domain code to any GUI framework.

Finally, if you want to write a cross-platform application, you will have to look elsewhere for GUI support.

My biggest gripe with MFC is that essentially it''s design goal: a think wrapper over the Win32 API. This means you don''t necessarily have a good abstraction. So porting in the future involves using some kind of 3rd party porting library.

You might want to search for something called ''paragui'' a cross-platform gui framework based on SDL.

Its kind of preliminary, but at least it''s GPL ( or LGPL )

##### Share on other sites
quote:

MFC ain''t the end all be all (imo). For a much better argument than I could put down in a few minutes, check out Reliable Software on MFC.

No, it''s not the end all be all. But it''s better than writing things in Win32 (imo). I''m sure that there are still people out there who think that electric lights "ain''t the end all be all" and are still pouring there own candles. That''s fine. Do what makes you happy.

Take care,
Bill

##### Share on other sites
Whoever wrote that anti MFC article must have never written any serious GUI application. I started writing a level editor in Win32 and it was a constant pain. Certain things in Win32 can be a nightmare while in MFC it can be a click using the appwizard. Besides that, you get pages and pages of WIn32 code just to manage simple controls. Its a mess.

The overhead and bloat of MFC is negligable in my experiences. The ease of development greatly outways any speed descrease.

Keep in mind, I say to use MFC for GUI intensive appz. Use Win32 if you only need to throw up a window for your engine / game.

ECKILLER

##### Share on other sites
I will definitely stick with MFC. I find it challenge, but one can easily master MFC with a lot of intensive reading, GUI design and MFC implementation. I will approach it that way.

I like MFC because it is from Microsoft. If I am going to design programming for Microsoft windows using C++, I might as well master a tool that is designed by the developers behind the OS for the OS.

Oldguys: You said, "You definitely wouldn't want to use it for any non-business app that involves any sort of games graphics, tho." Why?

ECKILLER: You said, "Keep in mind, I say to use MFC for GUI intensive appz. Use Win32 if you only need to throw up a window for your engine / game." Why?

Kuphryn

Edited by - kuphryn on February 3, 2002 12:47:39 PM

##### Share on other sites
I''ve been a professional MFC developer for about 3 years now, and I think the key to MFC is to sort of learn how the people who wrote it think. One of my best tools in doing this has been a book by Mike Blaszczak (Professional MFC I believe it''s called, big red book), as he was one of the people who wrote MFC. He discusses how to do things but also goes into why things are that way, which really helps... when you know what to expect MFC to be capable of, and when you know what to expect as the way things happen, it''s a lot easier to figure out what you should look for or where you should slip things in for what you''re trying to do.

Yes, it''s challenging, but it''s also used by the majority of companies who write business applications, so it''s very good on your resume.

Another of my favorite resources is www.codeguru.com, as I''m one of those people who learns best from seeing the actual code.

-fel

##### Share on other sites
quote:
Oldguys: You said, "You definitely wouldn't want to use it for any non-business app that involves any sort of games graphics, tho." Why?

May have been too harsh a statement. You can't easily (if at all) use MFC in a full-screen, exclusive DirectX mode. Also, MFC controls the drawing of a lot of it's controls, and makes it difficult, if not impossible, to change certain things (like the appearance of scrollbars).

I suppose that MFC is ok for games that don't require a lot of specialized graphics, and don't require fast redraw. I wrote a simple Civ-type game DirectX, and used MFC for the map editor.

MFC tends to make programs look a little 'business like'. Maybe I just haven't learned enough tricks...

Edited by - OldGuy on February 3, 2002 2:16:51 PM

##### Share on other sites
kuphryn: because if all you need is to throw up a window then you don''t need MFC. Thus in this case your adding MFC overhead for no reason at all.

ECKILLER

##### Share on other sites
quote:

kuphryn: because if all you need is to throw up a window then you don''t need MFC. Thus in this case your adding MFC overhead for no reason at all.

Hmmm...you''ve got me thinking now. If you built an MFC project by hand, you might get some benefit. Skip the document/view stuff and just use CWnds directly. You''d get the nice debugging support, serialization, other benefits. I think I''ll slap a quick test together and see.

Take care,
Bill

##### Share on other sites
We all know MFC is bloated... Personally I have seen better self written wrapper classes around the WIN32 API, bu ppl on this news group , then what MFC does...

##### Share on other sites
My MFC course used Jeff Prosise as our textbook and we followed it to the letter. I already knew Win32 programming, and I found the going easy. The other students couldn''t really make heads or tails of MFC until around chapter 5ish. Everything just seems to be unconnected and random at first, but later it all clicks into place. The coding will be really slow too until you do some appwizard examples and dialogs, which really didn''t come until chapter 8 to 10ish if I remember correctly. So things will become faster.

Doing MFC stuff is usually about changing one or two lines in app wizard code. You just have to know which two lines and where they are

Will things become easier? No, not imho. MFC was supposed to abstract many things and hide them behind C++ wrappers, so you didn''t have to worry about things that MFC was doing behind the scenes. But the only way (for me) to understand MFC, was to completely understand what MFC was hiding.

MFC blows.

##### Share on other sites
MFC is most definitely not the answer for Win32 GUI. It has one or two nice features, such as the document/view model, but is a constant pain to use. Simple things are made too fiddly, nothing''s simple with it and you''re constantly exposed to its workings. It forces you to work the way it does, and melds you into its twisted world.

If you are after GUI applications, use one of the following:

* Borland C++ Builder
* Visual Basic
* Delphi

If you use MFC then fine, but don''t say you weren''t warned.

##### Share on other sites
I''ve been using MFC and OpenGL together for tool development for years. It works like a charm after you figure it out once. You can knock out a new GUI in no time. If it is bloated, who cares? I just said that I use it for the tools. The "bloat" is often stuff you want in tools, for example, solid printing code.

An alternative that is not at all bloated, slick, polished, and technically not really supported by MS (but they use it) is WTL. This is a little tricky to use (it involves templates and multiple inheritance from the get go), but yields wonderful results once you get past the learning curve.

##### Share on other sites
Thanks everyone.

I hear two sides including MFC is bloated and MFC is powerful once the developer learns its working. Both sounds valid.

One thing I see is MFC developers like MFC, while developers that user other GUI tools and/or are in the process of learning MFC seem criticize it. Both situations are understandable.

As I this topic reads, I find MFC challenging mainly because there are many specific "tweaks," which are difficult for a beginner to learn, design around, and implement.

As I said before, I will definitely go through this process and learn MFC. I will give all I got into Prosise book. My goal is to first finish reading the book. My goal is to gain as much insight as I possibly can throughout the process. It will take some time, but very doable.

Are there some tips you have for gaining the most insights as possible during the process of learning MFC? I learning C++ quick. I can certainly apply the same technique I used throughout the process of learning C++.

Thanks,
Kuphryn

##### Share on other sites
You might also spend some time learning about some of the tools and techniques inside the MSVC++ IDE/debugger, if you haven''t already. Things like Spy, exceptions, etc. Sometimes you get stuck trying to do something in MFC, and you think it MUST work, but it doesn''t. Knowing the debugging tricks, such as watching messages, will help you first see what is going on, then understand what MFC is doing.

Another source of info is the MSDN library. They used to sell it separately, but I believe you get it now with MSVC++ 6.0. Also, there may be updates and other articles on the MSFT website. MSFT is notorious for having lots of information that never seems to be quite in the right place, but sometimes browsing through the MFC articles can be useful.

Good luck.

##### Share on other sites
If you go to my website you''ll see two pictures of the editor app one done in win32 the other in mfc. The reason I went with pure win32 in the beginning was because I understood the api and didn''t understand mfc too well. I then ported the win32 app into mfc. Took about a month to do since I was newbie at mfc but yes the first week I spent reading mfc docs, the technical docs, the c++ columns in msdn library, basically I wanted to really find if the porting was worth it. In the end I am glad I did it. It''s easier now to do things with mfc than with win32. I really like the win32 encapsulation into c++ objects. I use STL, mfc containers and win32 api functions since some don''t exists under mfc all meshed together and it works nice. Don''t be afraid to look into mfc source code for answers. Majority of the time you won''t have to. The most important class in mfc for gui is CWnd. It contains almost everything including dialog box functions. Then all the other more specialized objects derive from it. Good luck!

ForgEd3D world editor