• Advertisement

Archived

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

MFC is Challenging :: C++

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

If you intended to correct an error in the post then please contact us.

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
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 this post


Link to post
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 this post


Link to post
Share on other sites
Guest Anonymous Poster
To learn MFC : know it''s basic architecture tree, know its posibilities.
After this, the reference is your brother...

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites

  • Advertisement