Beginning MFC (Prosise) Part III - Now What? :: C++
-
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
Hello I think you might start creating some sample apps and when you get stuck you might post a doubt here or on any other C++ forum online. I guess people would be able to help you with individual issues a lot better than they'd be able to help you assimilate MFC as a whole. And good luck... :-) 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
-
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 don't think the book is the problem. I suspect you're reading it and hoping to have some sort of epiphany where it suddenly makes sense. No-one seriously does not use the wizards, the point is more that you should, in time, know how to do what the wizards do without them. But the only way to learn is not to read, just create some projects and experiment with them. Like Nish said, ask questions here, and look at samples here as well. Buying more books will not help you, because you already have a good book. But you won't learn anything until you start to write some code. kuphryn wrote: One reason, I think, is because there are *too many tools* in MFC I don't think MFC has as many tools as C++ does, and a lot of the time MFC has inferior tools to C++, such as MFC RTTI and MFC containers. What's more the point is that you get so many classes with an MFC app. You should start with a document based app, because it's simpler, and work your way up. The first time I looked at an MFC app I considered giving up, but in hindsight it's not that hard, it just can be hard to break into bite sized pieces. The thing is it doesn't matter if you don't know what a lot of the framework is doing, so long as you understand the parts you are working in - you can learn the rest with time. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
-
I don't think the book is the problem. I suspect you're reading it and hoping to have some sort of epiphany where it suddenly makes sense. No-one seriously does not use the wizards, the point is more that you should, in time, know how to do what the wizards do without them. But the only way to learn is not to read, just create some projects and experiment with them. Like Nish said, ask questions here, and look at samples here as well. Buying more books will not help you, because you already have a good book. But you won't learn anything until you start to write some code. kuphryn wrote: One reason, I think, is because there are *too many tools* in MFC I don't think MFC has as many tools as C++ does, and a lot of the time MFC has inferior tools to C++, such as MFC RTTI and MFC containers. What's more the point is that you get so many classes with an MFC app. You should start with a document based app, because it's simpler, and work your way up. The first time I looked at an MFC app I considered giving up, but in hindsight it's not that hard, it just can be hard to break into bite sized pieces. The thing is it doesn't matter if you don't know what a lot of the framework is doing, so long as you understand the parts you are working in - you can learn the rest with time. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
First, thanks for your thoughts. You are definitely on the right track about an epiphany. However, I am wait for an epiphany on those missing pieces I mentioned. I do not know how to achieve that next step, which I believe is the determining stage of my becoming a serious windows programming. I am scared. I do not feel the same confident with MFC as I did when I was learning C++. You mentioned Prosise's book as being the best. Yes, it undoubtedly the best MFC reference. How about teaching MFC. The reason I do not feel the same confident now with MFC as when I was learning C++ is because MFC is more restrictive. With C++, I can approach any problem and just look up tools. With MFC, not only do I have to determine the right tools, but I also have understand the tools since everything is part of the one huge MFC framework. It is overwhelming right now. Kuphryn
-
First, thanks for your thoughts. You are definitely on the right track about an epiphany. However, I am wait for an epiphany on those missing pieces I mentioned. I do not know how to achieve that next step, which I believe is the determining stage of my becoming a serious windows programming. I am scared. I do not feel the same confident with MFC as I did when I was learning C++. You mentioned Prosise's book as being the best. Yes, it undoubtedly the best MFC reference. How about teaching MFC. The reason I do not feel the same confident now with MFC as when I was learning C++ is because MFC is more restrictive. With C++, I can approach any problem and just look up tools. With MFC, not only do I have to determine the right tools, but I also have understand the tools since everything is part of the one huge MFC framework. It is overwhelming right now. Kuphryn
kuphryn wrote: However, I am wait for an epiphany on those missing pieces I mentioned. It's not coming, I promise :-) Seriously, what bits worry you ? kuphryn wrote: I do not feel the same confident with MFC as I did when I was learning C++. That's not surprising. 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. You also inherit (pardon the pun) about five classes for an SDI application, so it can be hard just figuring out which bit does what. A dialog app is only two classes in size though. kuphryn wrote: You mentioned Prosise's book as being the best. Yes, it undoubtedly the best MFC reference. How about teaching MFC. It could be that you're not so well suited to learning from books. Personally I hate being taught by another person, it's just a preference thing. So I can't really comment, because it's subjective. kuphryn wrote: With MFC, not only do I have to determine the right tools, but I also have understand the tools since everything is part of the one huge MFC framework. It is overwhelming right now. Like I said, you don't need to completely understand them to use them, you only need to understand the part you are using. So what is troubling you ? Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
-
kuphryn wrote: However, I am wait for an epiphany on those missing pieces I mentioned. It's not coming, I promise :-) Seriously, what bits worry you ? kuphryn wrote: I do not feel the same confident with MFC as I did when I was learning C++. That's not surprising. 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. You also inherit (pardon the pun) about five classes for an SDI application, so it can be hard just figuring out which bit does what. A dialog app is only two classes in size though. kuphryn wrote: You mentioned Prosise's book as being the best. Yes, it undoubtedly the best MFC reference. How about teaching MFC. It could be that you're not so well suited to learning from books. Personally I hate being taught by another person, it's just a preference thing. So I can't really comment, because it's subjective. kuphryn wrote: With MFC, not only do I have to determine the right tools, but I also have understand the tools since everything is part of the one huge MFC framework. It is overwhelming right now. Like I said, you don't need to completely understand them to use them, you only need to understand the part you are using. So what is troubling you ? Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
Christian Graus wrote: You also inherit (pardon the pun) about five classes for an SDI application LOL But the funny thing is most often you only need to manipulate one of those inherited classes :-) 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
-
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 would suggest reading up on the SDK API...without a firm understanding of they work, it'll be really hard to pick MFC. It took me about 3 years to consider using MFC and actually try it, before that it was a failed attempt at OWL. SDK is easy to follow...top to bottom...like a DOS program with messages. MFC hides so much crap from you, but once you understand it, app development is sooo much faster. Considering you don't get stuck on goofy problems. I've only been dickin around in MFC for about 1 year and a bit and I can accomplish anything I would want probably not the best MFC way!!! but when it's compiled it all looks and acts the same. Yup...definetly understand SDK then migrate into MFC, but it sounds like you've already started with MFC so maybe try and intergrate the two togather. Ciao! "An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
-
I would suggest reading up on the SDK API...without a firm understanding of they work, it'll be really hard to pick MFC. It took me about 3 years to consider using MFC and actually try it, before that it was a failed attempt at OWL. SDK is easy to follow...top to bottom...like a DOS program with messages. MFC hides so much crap from you, but once you understand it, app development is sooo much faster. Considering you don't get stuck on goofy problems. I've only been dickin around in MFC for about 1 year and a bit and I can accomplish anything I would want probably not the best MFC way!!! but when it's compiled it all looks and acts the same. Yup...definetly understand SDK then migrate into MFC, but it sounds like you've already started with MFC so maybe try and intergrate the two togather. Ciao! "An expert is someone who has made all the mistakes in his or her field" - Niels Bohr
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.
-
kuphryn wrote: However, I am wait for an epiphany on those missing pieces I mentioned. It's not coming, I promise :-) Seriously, what bits worry you ? kuphryn wrote: I do not feel the same confident with MFC as I did when I was learning C++. That's not surprising. 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. You also inherit (pardon the pun) about five classes for an SDI application, so it can be hard just figuring out which bit does what. A dialog app is only two classes in size though. kuphryn wrote: You mentioned Prosise's book as being the best. Yes, it undoubtedly the best MFC reference. How about teaching MFC. It could be that you're not so well suited to learning from books. Personally I hate being taught by another person, it's just a preference thing. So I can't really comment, because it's subjective. kuphryn wrote: With MFC, not only do I have to determine the right tools, but I also have understand the tools since everything is part of the one huge MFC framework. It is overwhelming right now. Like I said, you don't need to completely understand them to use them, you only need to understand the part you are using. So what is troubling you ? Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little.
Okay. I will begin with one general issue. I am not exactly sure where to map command and command UI, but most important, messages in general. Mainframe and documents can only handle command/UI messages. I cannot decide where to map command/UI mainframe, view, or documents. I am very rusty on classifying different messages, but that is not a problem because I can always look them up in Promise's book. The last issue I am not certain of is all the painting tools. Promise discussed a lot of core materials in the first five chapters. I lost sight of all th painting tools along the way. Yes, I read everything very carefully. There were just too many new materials to remember without having any prior knowledge MFC to use each tool as Prosise present it. When I was learning C++, I was able to read the new material and immediately apply it in a real program. That is how I learn, and it is when I am at my best. With MFC, I learn that "k" is a letter, but that is it. I have no idea that "i" and "j" are before and after "k." I really enjoy reading about document/view because it is something I caught on quick. I understand that architecture. It is the tools around MFC classes that I do not understand. The two pages of classes and functions in the first two pages of Promise's book hurts my brain. Now, 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. Thanks, Kuphryn
-
Okay. I will begin with one general issue. I am not exactly sure where to map command and command UI, but most important, messages in general. Mainframe and documents can only handle command/UI messages. I cannot decide where to map command/UI mainframe, view, or documents. I am very rusty on classifying different messages, but that is not a problem because I can always look them up in Promise's book. The last issue I am not certain of is all the painting tools. Promise discussed a lot of core materials in the first five chapters. I lost sight of all th painting tools along the way. Yes, I read everything very carefully. There were just too many new materials to remember without having any prior knowledge MFC to use each tool as Prosise present it. When I was learning C++, I was able to read the new material and immediately apply it in a real program. That is how I learn, and it is when I am at my best. With MFC, I learn that "k" is a letter, but that is it. I have no idea that "i" and "j" are before and after "k." I really enjoy reading about document/view because it is something I caught on quick. I understand that architecture. It is the tools around MFC classes that I do not understand. The two pages of classes and functions in the first two pages of Promise's book hurts my brain. Now, 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. Thanks, Kuphryn
kuphryn wrote: I will begin with one general issue. I am not exactly sure where to map command and command UI, but most important, messages in general. Mainframe and documents can only handle command/UI messages. I cannot decide where to map command/UI mainframe, view, or documents. Messages are generally mapped in the class that relates to them - in other words, map messages to do with loading and saving files in your document class, map paint messages in your view or dialog class. As far as internal messages go, it's a non-issue because the class wizard will only show you the messages you can use anyhow. Command/UI messages should be mapped in the mainframe, because it's always there to process them, a view or document may not be. kuphryn wrote: The last issue I am not certain of is all the painting tools. Promise discussed a lot of core materials in the first five chapters. I lost sight of all th painting tools along the way. Well, which paint tools do you need to know about ? Painting always occurs in OnEraseBackground, OnPaint, OnDraw, or OnPrepareDC, and I'd suggest all the different tools, such as ExtFloodFill, Polygon, etc. are stuff you can learn one by one as you need them. kuphryn wrote: Yes, I read everything very carefully. There were just too many new materials to remember without having any prior knowledge MFC to use each tool as Prosise present it. When I was learning C++, I was able to read the new material and immediately apply it in a real program. That is how I learn, and it is when I am at my best. With MFC, I learn that "k" is a letter, but that is it. I have no idea that "i" and "j" are before and after "k." As an example, once you know that OnPaint is where a dialog is drawn, why can't you create a vanilla dialog app, override OnPaint and experiment, even though you have no idea how the framework gets to the point of processing that message ? kuphryn wrote: Now, 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. First of all I would still use std iostreams to read the file, and then I wo
-
kuphryn wrote: I will begin with one general issue. I am not exactly sure where to map command and command UI, but most important, messages in general. Mainframe and documents can only handle command/UI messages. I cannot decide where to map command/UI mainframe, view, or documents. Messages are generally mapped in the class that relates to them - in other words, map messages to do with loading and saving files in your document class, map paint messages in your view or dialog class. As far as internal messages go, it's a non-issue because the class wizard will only show you the messages you can use anyhow. Command/UI messages should be mapped in the mainframe, because it's always there to process them, a view or document may not be. kuphryn wrote: The last issue I am not certain of is all the painting tools. Promise discussed a lot of core materials in the first five chapters. I lost sight of all th painting tools along the way. Well, which paint tools do you need to know about ? Painting always occurs in OnEraseBackground, OnPaint, OnDraw, or OnPrepareDC, and I'd suggest all the different tools, such as ExtFloodFill, Polygon, etc. are stuff you can learn one by one as you need them. kuphryn wrote: Yes, I read everything very carefully. There were just too many new materials to remember without having any prior knowledge MFC to use each tool as Prosise present it. When I was learning C++, I was able to read the new material and immediately apply it in a real program. That is how I learn, and it is when I am at my best. With MFC, I learn that "k" is a letter, but that is it. I have no idea that "i" and "j" are before and after "k." As an example, once you know that OnPaint is where a dialog is drawn, why can't you create a vanilla dialog app, override OnPaint and experiment, even though you have no idea how the framework gets to the point of processing that message ? kuphryn wrote: Now, 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. First of all I would still use std iostreams to read the file, and then I wo
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
-
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