Beginning MFC (Prosise) Part III - Now What? :: C++

[kuphryn]

Hi.

I began study MFC programming from Prosise two months ago. I finished the first two part of the book and will begin Part III. To be honest, I still cannot design a program of *my own* and implement it using MFC.

I read reviews about MFC books including Prosise, Jones, and Deitel. I see again and again that one of the most difficult part of teaching MFC is to *not* discuss AppWizard and ClassWizard. Prosise does it by chapter 4. Nonetheless, Prosise's book is an ideal MFC *reference*.

Anyways, I learned quite a bit from reading the first two part. I really appreciate the document/view architecture. I want to start implementing my win32 console programs into MFC so bad. I can just *feel* it, but I cannot get it done. There are many missing pieces in this puzzle. I can picture the final results, but there are so many missing pieces (how?, why?, what?, when?). I have no idea how to gather all the missing pieces.

I first began programming (ever) as well as programming using C++ last fall semester. C++ caught my interest quick. Learning MFC, for some reason, is not the same. I cannot apply the same formula of *diving in*, which was how I became so proficient with C++ in both design and implementation. I can solve most problems using C++ (except for big projects). One reason, I think, is because there are *too many tools* in MFC. I can say I have seen close to just about everything there is to see in C++. I tried again and again to get apply the same strategy to MFC, but it does not seem to work.

So here I am, beginning Part III from Prosise's book and howing no is lost. What are my options?

I can considering Jones' Introduction to MFC Programming with
Visual C++. If nothing else works, I will most likely go a different direction (Jones) and then return to Promise.

Kuphryn

 

[Nothinman]

I don't want to discourage you, but I still don't see why you're fighting with MFC when there's other, better, cross-platform options out there.

 

[DaveSimmons]

I find it easier to learn new technology if I'm trying to solve a specific problem -- I also read articles in MSJ, WDJ, C/C++ journal, etc. but it's hard to really "get" something until you have to use it for real.

In your place I'd think up some interesting project that is big enough to use doc-view and complicated enough to make you use the rest of the framework as well.

Is there any program you'd like to have that doesn't already exist, or exists but doesn't work the way you'd like it to? Any interests or hobbies besides programming?

 

[kuphryn]

Thanks.

You're probably referring to Qt. My only problem with Qt is the fact that it is way too expensive. MFC.

Kuphryn

 

[Nothinman]

Develop on Linux and you can use the free version now =) I do believe a free Win32 version is in the works too.

You could also use GTK or wXWindows (however it's spelled). Or if you must use Windows technology use Borland C++ Builder, it's so simple you'll get to work on the program not the support libraries =)

 

[kuphryn]

The program I am working on has to do with read data from a text file, analyze the data, and output the modified data back to the file. For example, the program will read "a" and output "Letter: A."

I am not sure the exact CView I need (scroll, edit, etc.). I am not sure what message I need to consider and what to map them. In general, I am not ready to implement the win32 console program to windows using MFC.

Kuphryn

 

[DaveSimmons]

<< The program I am working on has to do with read data from a text file, analyze the data, and output the modified data back to the file. For example, the program will read "a" and output "Letter: A." >>



Hmm, that sounds too easy

Unless there is some decision-making involved with changing the data, settings you can adjust or enable/disable, I don't see much point in using doc-view. Were you thinking of using the view to do anything besides previewing the changed data? Also, does the "doc" part make sense if you essentially have 2 different "file formats" (before and after processing), or is the processing something that can be done more than once to a file (like WAV file editing)?

If the data is just text and I was doing this at work, I'd probably just create a dialog-only application with 2 multi-line edit or rich-edit controls, with labels like "before" and "after". I'd add an [Open] button to pick a file to process, a [Save] button to write back the processed changes, and use the CFileDialog class in the code for OnOpen to pick the file. If processing is not always the same I'd add buttons, check boxes, etc. to control processing, and maybe a [process] button to start processing.

Perhaps it's seeming hard because what you're doing doesn't fit the doc-view idea? Or are there more details that you haven't gone into yet?

 

[kuphryn]

The program does fit the doc/view architecture. I lack the knowledge and experience to really put everything together.

Kuphryn

 

[singh]

MFC is not that hard to master, and you are on the right path - your learning is goal-directed. So you want to read/analyze data from a file. Remember that the Document/View architecture is really Data/View Architecture. Since your data is TEXT, you will need some kind of view that can display text - CEditView is a good choice.

You also need to know when to open the file, read it, and display something if neccessary. Ideally, you want the user to use File->Open to open the file. So use Class Wizard and map the File->Open command to your Document class. In the handler, open the file as needed in the Serialize() method of the Document class. Once you're done loading, call UpdateAllViews(). Then, add a OnUpdate() handler in your View class, and get a pointer to the "Document". Then just display the data as you need.

Once you know the basics, *ALL* your learning should be goal-directed. Just try to make a program, and learn what you don't know.

 

[kuphryn]

Thanks for the encouragement.

I love C++. I love windows programming, but I just cannot get to a point where I feel confident solving problems and be able to implement the program as windows based.

I will still have hope of working with MFC. I believe I need to start from the beginner of MFC as when I was learning C++ (cout >> "Hello World." Again, MFC will not get any easier. My plan not rely on MFC become easier. Rather, I plan to be ready for MFC.

I decided to buy Richard Jones' introduction to MFC. I know Prosise
s book is the best. However, that does not mean it is the only way to learn MFC. For example, I believe Deitel&Deitel's C++ How to Program is the best book for learning C++. However, it was not the first book I read. By the time I read it, I was able to gain so many insights "advices" that they give because I understood the fundmentals of C++.

I will apply the same learning approach to MFC. I really should learn API first, but I feel MFC is very learnable. It is just that MFC is huge, and so I have trouble focusing and learning everything at once. For example, looking about at C++, I am impress with myself knowing C++ is itself huge. I learned C++ in two months.

Kuphryn