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.
MFC is Challenging :: C++
Author
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
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
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.
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.
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
ForgEd3D world editor
Having used MFC professionally for 2.5years, and studying it at least a year longer, I would say "stay away from it".
SPECIFICALLY in the case of large projects with a lot of UI that may have to be customised to certain specifications, and that has to interact with things that aren''t necessarily supported directly by MFC.
We used it in a COM-based project of a visual development tool for an embedded system.
COM and MFC don''t mix. Some things (connection points) REQUIRE the use of undocumented features or they simply won''t work. You won''t find it in the MSDN though, no way, in the MSDN they suggest everything is just fine and dandy.
MFC hides a lot of things that you may need to see when you''re debugging. I had a lot of problems with a customized tree control that normally connected to other data, but could get disconnected and then had to be regenerated. The problem turned out to be that deletion of a tree item causes a selection of all its child items (!!). Hard to see if you''re using MFC, good thing I had the MFC source installed to see what the Tree Control was doing on the inside, or I might have taken months to find it.
In the end, like the article posted on the first page said, to use MFC in depth properly you need to know so much about how it works, that you''d be better off learning all about the WIN32 API, and then doing things yourself. You could then still go back to using MFC features (but this time understanding EXACTLY what they do).
You''d be a better programmer, because you can safely say "If I can''t get it to do what I want in MFC, I''ll just write it myself".
People might not remember what you said, or what you did, but they will always remember how you made them feel.
SPECIFICALLY in the case of large projects with a lot of UI that may have to be customised to certain specifications, and that has to interact with things that aren''t necessarily supported directly by MFC.
We used it in a COM-based project of a visual development tool for an embedded system.
COM and MFC don''t mix. Some things (connection points) REQUIRE the use of undocumented features or they simply won''t work. You won''t find it in the MSDN though, no way, in the MSDN they suggest everything is just fine and dandy.
MFC hides a lot of things that you may need to see when you''re debugging. I had a lot of problems with a customized tree control that normally connected to other data, but could get disconnected and then had to be regenerated. The problem turned out to be that deletion of a tree item causes a selection of all its child items (!!). Hard to see if you''re using MFC, good thing I had the MFC source installed to see what the Tree Control was doing on the inside, or I might have taken months to find it.
In the end, like the article posted on the first page said, to use MFC in depth properly you need to know so much about how it works, that you''d be better off learning all about the WIN32 API, and then doing things yourself. You could then still go back to using MFC features (but this time understanding EXACTLY what they do).
You''d be a better programmer, because you can safely say "If I can''t get it to do what I want in MFC, I''ll just write it myself".
People might not remember what you said, or what you did, but they will always remember how you made them feel.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
