Beginning MFC (Prosise) Part III - Now What? :: C++
-
Thanks! You brought up something very important. You brought up the issue of not having to use CFILE and serialize. I thought all data read from and written to a file must be "serialized." How can I read a file using using CFILE? I agree TextOut is the way to go too. Kuphryn
kuphryn wrote: How can I read a file using using CFILE? I only vaguely know, because iostream is not broken, and I prefer to use the standard library. I believe the mechanism is very similar. kuphryn wrote: I thought all data read from and written to a file must be "serialized." No, Prosise would present that only because it's part of MFC, but all the standard library is still there at your disposal. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
-
Thanks! You brought up something very important. You brought up the issue of not having to use CFILE and serialize. I thought all data read from and written to a file must be "serialized." How can I read a file using using CFILE? I agree TextOut is the way to go too. Kuphryn
use CFile::Read and CFile::Write Nish It's seven o'clock On the dot I'm in my drop top Cruisin' the streets - Oh yeah I got a real pretty, pretty little thing that's waiting for me
-
use CFile::Read and CFile::Write Nish It's seven o'clock On the dot I'm in my drop top Cruisin' the streets - Oh yeah I got a real pretty, pretty little thing that's waiting for me
Nish [BusterBoy] wrote: It's seven o'clock On the dot I'm in my drop top Cruisin' the streets - Oh yeah I got a real pretty, pretty little thing that's waiting for me I've asked before - who wrote the above ? Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
-
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
kuphryn wrote: 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. Don't worry, this is not a problem only with you. This is the same problem every newbie of MFC/VC++ encounters. And among many reasons of the popularity of JAVA this is also the one. There is absolutely no fault of the writers of books you named above. The main reason is the complexity of MFC and the absence of CodeDOM in VC++. Imran Farooqui
-
Nish [BusterBoy] wrote: It's seven o'clock On the dot I'm in my drop top Cruisin' the streets - Oh yeah I got a real pretty, pretty little thing that's waiting for me I've asked before - who wrote the above ? Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
It's a song by Usher called Nice and slow. http://display.lyrics.astraweb.com:2000/display.cgi?usher..my\_way..nice\_and\_slow Nish It's seven o'clock On the dot I'm in my drop top Cruisin' the streets - Oh yeah I got a real pretty, pretty little thing that's waiting for me
-
Nish [BusterBoy] wrote: It's seven o'clock On the dot I'm in my drop top Cruisin' the streets - Oh yeah I got a real pretty, pretty little thing that's waiting for me I've asked before - who wrote the above ? Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
Christian Graus wrote: I've asked before - who wrote the above ? You didnt seriously think that I wrote those words, did you? Nish :omg: It's seven o'clock On the dot I'm in my drop top Cruisin' the streets - Oh yeah I got a real pretty, pretty little thing that's waiting for me
-
Christian Graus wrote: I've asked before - who wrote the above ? You didnt seriously think that I wrote those words, did you? Nish :omg: It's seven o'clock On the dot I'm in my drop top Cruisin' the streets - Oh yeah I got a real pretty, pretty little thing that's waiting for me
Nish [BusterBoy] wrote: You didnt seriously think that I wrote those words, did you? No, I presumed it was a song, I just wondered which. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
-
kuphryn wrote: 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. Don't worry, this is not a problem only with you. This is the same problem every newbie of MFC/VC++ encounters. And among many reasons of the popularity of JAVA this is also the one. There is absolutely no fault of the writers of books you named above. The main reason is the complexity of MFC and the absence of CodeDOM in VC++. Imran Farooqui
Imran Farooqui wrote: And among many reasons of the popularity of JAVA this is also the one. Did you say this with a straight face ? Popularity of Java amongst whom ? :laugh: Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
-
Imran Farooqui wrote: And among many reasons of the popularity of JAVA this is also the one. Did you say this with a straight face ? Popularity of Java amongst whom ? :laugh: Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
I mean that complexities involve in MFC and its HUGE learning curve are also some reason that many people looks towards JAVA. (Personally i dislike JAVA as I am a proud CPian). But if you ask one group of students to learn JAVA and other to learn MFC. Then after 6/7 months you give them a mini project. The group of people that learn Java will make this project much more quicker and easily than the people who are learning VC++. Imran Farooqui
-
Nish [BusterBoy] wrote: You didnt seriously think that I wrote those words, did you? No, I presumed it was a song, I just wondered which. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
Christian Graus wrote: No, I presumed it was a song, I just wondered which. Whew! I am glad of that :-) Nish p.s. I can't connect to sonork now! It's seven o'clock On the dot I'm in my drop top Cruisin' the streets - Oh yeah I got a real pretty, pretty little thing that's waiting for me
-
kuphryn wrote: 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. Don't worry, this is not a problem only with you. This is the same problem every newbie of MFC/VC++ encounters. And among many reasons of the popularity of JAVA this is also the one. There is absolutely no fault of the writers of books you named above. The main reason is the complexity of MFC and the absence of CodeDOM in VC++. Imran Farooqui
Imran Farooqui wrote: And among many reasons of the popularity of JAVA this is also the one Imran Farooqui wrote: The main reason is the complexity of MFC and the absence of CodeDOM in VC++. :confused: :confused: Java has CodeDOM???? I thought the better java programmers used emacs and linux. It was always the poor ones who used VJ++. Nish It's seven o'clock On the dot I'm in my drop top Cruisin' the streets - Oh yeah I got a real pretty, pretty little thing that's waiting for me
-
HockeyDude wrote: would suggest reading up on the SDK API...without a firm understanding of they work, it'll be really hard to pick MFC. Do you really think so ? To me, having done it in reverse, that's like learning C before C++, doing it the hard way before the easy way. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
I think the advantage to learning the WIN32 APIs through raw SDK programming is that you learn the purpose of each of the functions, messages and other pieces that make up a Windows application. With that said, MFC and WTL are structured around the SDK in an object-oriented way and are surely a superior way to develop Windows applications, but by knowing and thouroughly understanding the SDK, it can be understood what these two frameworks are trying to accomplish. Then when you want to try to implement something that the original designers of MFC and WTL had not anticipated, you can tackle the problem with your base knowledge. While I agree that SDK programming is the harder way to develop a Windows application, I think that the comparison of "C : C++ is like SDK : MFC" falls apart because going from C to object-oriented programming in C++ is a completely new way of thinking. MFC is simply an object-oriented wrapper around concepts and restraints that are created in the SDK. This is just my opinion though.
-
I mean that complexities involve in MFC and its HUGE learning curve are also some reason that many people looks towards JAVA. (Personally i dislike JAVA as I am a proud CPian). But if you ask one group of students to learn JAVA and other to learn MFC. Then after 6/7 months you give them a mini project. The group of people that learn Java will make this project much more quicker and easily than the people who are learning VC++. Imran Farooqui
Imran Farooqui wrote: But if you ask one group of students to learn JAVA and other to learn MFC This is not a fair comparison. java is a programming language. MFC is a class library. Tell them to study java and c++, one for each group. or actually tell them all to study both. The ones who dont get good at C++ in 6 months would be bad anyway, so let them learn java :-) Let the others then start with MFC or ATL or whatever Nish It's seven o'clock On the dot I'm in my drop top Cruisin' the streets - Oh yeah I got a real pretty, pretty little thing that's waiting for me
-
I think the advantage to learning the WIN32 APIs through raw SDK programming is that you learn the purpose of each of the functions, messages and other pieces that make up a Windows application. With that said, MFC and WTL are structured around the SDK in an object-oriented way and are surely a superior way to develop Windows applications, but by knowing and thouroughly understanding the SDK, it can be understood what these two frameworks are trying to accomplish. Then when you want to try to implement something that the original designers of MFC and WTL had not anticipated, you can tackle the problem with your base knowledge. While I agree that SDK programming is the harder way to develop a Windows application, I think that the comparison of "C : C++ is like SDK : MFC" falls apart because going from C to object-oriented programming in C++ is a completely new way of thinking. MFC is simply an object-oriented wrapper around concepts and restraints that are created in the SDK. This is just my opinion though.
kilowatt wrote: While I agree that SDK programming is the harder way to develop a Windows application, I think that the comparison of "C : C++ is like SDK : MFC" falls apart because going from C to object-oriented programming in C++ is a completely new way of thinking. MFC is simply an object-oriented wrapper around concepts and restraints that are created in the SDK. This is just my opinion though. You're right, of course, but the example is there, in both cases people suggest the harder alternative should be learned first. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
-
HockeyDude wrote: would suggest reading up on the SDK API...without a firm understanding of they work, it'll be really hard to pick MFC. Do you really think so ? To me, having done it in reverse, that's like learning C before C++, doing it the hard way before the easy way. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
I made the initial transition from VB to Borland C++...OWL was chinese to me...I picked up the C++ lanuage constructs(??) quick cuz they're the same in most langs...the OWL really through me off though...The createWindow functions compared to VB's click and drag were very foriegn to me. I later bought (without really knowning what it was) Win 95 programming API bible, which was much easier to follow. The code samples taugh me all the in and outs of windows programming. Once I understood what the CreateWindow function actually did...and the parameters actually meant...MFC was much easier to learn then when I tried OWL withouth knowledge of the API... Everybody's different though...I don't imagine my experience in VB helped, cuz it really only made me think....god...programming is easy...which...is a totally different story in C++. Cheers! :) "An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
-
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
Thanks guys. Christian Graus made a good point. He said, "C++ is a well designed language that is made to be non-restrictive, to leave the design to the programmer. MFC is a framework in which you need to do things the MFC way." Is API programming *similar* to C++? I thinking the best way for me to learn windows programming is to approach it from *low-level*. In other words, I think I would master it if I can just start coding everything from scratch instead of using classes from MFC. I believe one reason I cannot understand all MFC classes and functions is because I do not know what *they actually do* and how. I am used to designing and implementing my own classes. I prefer to design my own classes for later use, like a personal C++ library. With MFC, I have to not only learn a huge framework of classes, but I have to follow a rule that the design have set. That is very limiting. I do not have problems with the framework. It is the vast number of classes in MFC that makes it difficult for me to see everything that is going on. For example, I know class X handles a specific job. I can tell instantiate an object X or override class X, but I lack the knowledge of how things surrounding class X relate to it. Moreover, I do not know class X well enough to see its potential. Kuphryn P.S. I think I have to change track because I just cannot produce anything with MFC right now. Something has gone very wrong during the last two months of my studying from Prosise's. Part III of his book is about discusses topics beyond basics. So according to his agenda, I should be able to produce result by now. So that leaves two choice: Jones' or API. I will most likely try Jones' first. If that too leads me nowhere, then API will it is. Kuphryn
-
Thanks guys. Christian Graus made a good point. He said, "C++ is a well designed language that is made to be non-restrictive, to leave the design to the programmer. MFC is a framework in which you need to do things the MFC way." Is API programming *similar* to C++? I thinking the best way for me to learn windows programming is to approach it from *low-level*. In other words, I think I would master it if I can just start coding everything from scratch instead of using classes from MFC. I believe one reason I cannot understand all MFC classes and functions is because I do not know what *they actually do* and how. I am used to designing and implementing my own classes. I prefer to design my own classes for later use, like a personal C++ library. With MFC, I have to not only learn a huge framework of classes, but I have to follow a rule that the design have set. That is very limiting. I do not have problems with the framework. It is the vast number of classes in MFC that makes it difficult for me to see everything that is going on. For example, I know class X handles a specific job. I can tell instantiate an object X or override class X, but I lack the knowledge of how things surrounding class X relate to it. Moreover, I do not know class X well enough to see its potential. Kuphryn P.S. I think I have to change track because I just cannot produce anything with MFC right now. Something has gone very wrong during the last two months of my studying from Prosise's. Part III of his book is about discusses topics beyond basics. So according to his agenda, I should be able to produce result by now. So that leaves two choice: Jones' or API. I will most likely try Jones' first. If that too leads me nowhere, then API will it is. Kuphryn
Have a look at http://www.codeproject.com/wtl/ I found it easier to learn WTL than MFC first. With MFC I found it hard to get the bigger picture with all the wizards and generated code. WTL is smaller and simpler. I plan to learn MFC 7 though. Note I've only written some simple windows apps.
-
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
I looked at the API code at http://www.winprog.org/tutorial/ and I understood it easily. It looked just like the kind of C++ programming style that I use with my Win32 console programs. This is weird. MFC code confuses me. There are too many intantiations and function calls. However, I have no idea what those objects and functions do. I hear Petzold's API is the best. However, it is in C. What is the best *beginnger* API that emphasizes C++? Thanks, 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
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
-
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
kuphryn wrote: For example, looking about at C++, I am impress with myself knowing C++ is itself huge. I learned C++ in two months. Completely ? Did you understand how iostreams work in that time ( so that you could write your own stream/stream handler for a new class ? Did you know enough about STL that you could write your own containers, iterators and algorithms ? If so, MFC would be a doddle - two weeks tops. If not, then you know what I mean, knowing a subset that makes you able to use a tool is not the same as knowing it, and the former is the cost of entry to start building the latter. Good luck. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.