The first thing to read a book is to read its table of contents.  There are 16 chapters in this book.  I'll list them below for better explanation of my thinking.
    1. Win32 application basic concepts.
    2. Important C++ features.
    3. Simulation of six MFC key techniques.
    4. Visual C++ SDK.
    5. Overview of application framework.
    6. The life cycle of an MFC application.
    7. The skeleton of an MFC application.
    8. Discussion of Document-View.
    9. Message mapping message relaying.
    10. MFC and dialogs.
    11. Improve on View and repainting features.
    12. Printing and previewing.
    13. Multiple files and multiple views.
    14. MFC multi-threading application design.
    15. Customizing an AppWizard.
    16. Using Components & ActiveX Controls.

When reading its table of contents, I put up a question: why did jjhour(the author) arrange his book in this way?  If I was taken back by time machine to several years ago, how should I start to learn such a complicated framework?

I recalled my first experience of doing an OLAP project using Mondrain and mysql in my training project two years ago.  Following was my original way to do the research.
    1. Get to know what is OLAP, Mondrain, and mysql.
    2. Read the help document of Mondrain and mysql chapter by chapter.
    3. After reading all those chapters, in fact I found there was no enough time thus only "picked" with no good reason of several chapters to read, try to do my project.

If I move what I did on OLAP project to MFC, I think the sequence might be:
    1. Study C++.
    2. Read msdn chapters on MFC one by one.
    3. After studying all the chapters, my study process is finished.

How different the learning process is!  With my original method, I guess I can never grasp MFC in my life.
Now I can list the differences below:
  1. jjhour uses two chapters to set up the basis for studying MFC.
  2. He selects and simulates 6 key technologies used in MFC.
  3. He then gives an introduction on the development tools.
  4. An overview.
  5. Detailed discussion of the six key technologies, then other important chapters.

Why jjhour's method is much better than mine?  I think the reasons should be:
  1. He can combine the study of tools and theories very well.
  2. He knows which are the key factors of MFC and put his focus on these key factors.
  3. His studying process is basics - key factors(of new tech) - tools - detailed key factors, which is very impressive.

Therefore, my first experience learned here is the process of learning a new technology.

Recently I've finished reading Effective C++.  Then, Eugene asked me to take charge of a senior C++ seminar.  However, my original plan was to read another book: Exceptional C++.  During the seminar, I found reviewing what I've learned before for the second time has a lot of benefit.  Those things I thought to have understood was not mastered by me at first indeed.  Through discussion and studying for the second time, I can improve my understanding for C++.

Now, since my project is not so tough, I'm facing the situation to choose something to learn.  Actually there might be only 6 weeks for me before going back to Shanghai.  After I go back, there won't be so much free time like here to learn what I want to learn.  I need to make fully use my time.  At this time, there are three choices for me: 
    1. To study Exceptional C++.
    2. To study Visual C# .NET.
    3. To study MFC.  (Which I studied a long, long time ago.)

I don't want to study Exceptional C++ at this stage because I'm already capable to do C++ project now.  I can read this book if I'm assigned to a C++ project after go back to Shanghai.  What is more important now is to learn sth else, in case I'm assigned to other MS related projects.  Therefore, C# and MFC are two good candidates.  

I chose MFC then.  Because I read it before, read it for the second time could save me time.  Furthermore, just like the experience of studing Effective C++, studying it for the second time can make me improve my understanding for it.  

When I read this book today, one of my colleague asked me, why did I read it.  He thought that MFC is not popular any more, only .NET(or J2EE) is popular.  He thought that I should learn those things.  This reminds me the experience from Kevin Zhou.  He's one of the best professors in my school focusing on database research.  Once he said, "We followed the hot research areas for so many years but got nothing, why?  Because we ignored the importance of the relative old basic things.  It is the old, basic area that make those foreign researchers so productive."  I think the same conclusion can be drawn here for the same reason.  It is the MFC the most basic thing to learn, before I take my time to learn C#.  Ignoring the importance of MFC will make me only a follower of new technology, not one who can really understand technology core.

Through studying Disecting MFC, I really grasped something new.  I'll keep them down in my following posts.

Last Friday Leonard had a dinner with us guys in BeiJing.  During the dinner, he asked us four who work on site about the differences we felt.  One of us said, the work load here in customer's company was light comparing to that in our company.  For confidential reason, I'll use C to represent our customer's name.

Then Leonard asked whether any of us can give a reason for the phenomenon.  After a short silence, I answered with what I heard from one customer.  "At the beginning, when C was built up in BeiJing, the workload in C was also heavy.  Often, employees in C were asked to give a demo at the next day, then they have to work overnight to get a demo.  Later, when C is getting bigger and employs more people, the workload gets lighter."

On hearing my answer, Leonard quickly told me that I was giving a description instead of the reason for the problem.  I had to admit that.  "Then could you give the reason for it?"  I was stuck.

Then Leonard asked me another question.  "How many people are there in C now?"
"200 to 300."  One of my colleagues said.
"How many people are there in our Shanghai office?"  
"800."  I answered.
"Then do you think our colleagues in Shanghai have a lighter workload than C?"
"Of coz not."

From the conversasion above, I find a big problem in my way to think.  I'm too easy to adopt a conclusion before putting the conclusion in a bigger environment.  A conclusion needs more test on more scenarios before I can create a model base on it.  This is a real example of our culture "Think out of box".  

Later Leonard added, every thing he heard, every thing he observed, he put them into his brain, in the most original form.  But never will he accept until he compares the new material with all the other and finds no confiction.  In this way, he builds models for every thing quickly.  With such a model, he can predict when meeting with a new problem.  It doesn't matter if there is a confict.  In that case, it means that the model might be wrong.  Then he'll adjust his original model and builds a new one.

On the question above, there is a difference between what I said and he observed in our company.  "When there is a difference, there is knowledge in that field.", Leonard said.  "Think why there is such a difference and you'll get your own knowledge."

On how to find out the root reason for a difference, Leonard gave us an example.  "When you find flowers and leaves are different, you cannot focus on the flowers and leaves themselves and think why.  You need to think from their root, the plant itself, to find out why.  That's where flowers and leaves come from."

Today when I read Effective C++, I read of an item which compares the difference between override of virtual member function and override of non-virtual member function.  On my way home, I put forward a question.  If Effective C++ does not exist, how can I find out the difference by myself?  

Then Leonard's words came into my mind.  First find out the difference (the virtual keyword) in code, then think why.  On thinking why, the motivation of virtual function is considered.  In this way, it is very natual to get a conclusion.

I'll end this post with Leonard's words.  "Change your mind.  Change the way you think.  You can find knowledge by yourself.  And the world will be totally different in your eyes."

1. Read the overview article.  Get to know the background of the topic.  Why the product was built? 
2. Find out differences between existing similar products.
3. Think how come the differences.  When researching on this problem, deduct from point 1.