VC向导自动生成的东东（**，**Doc，**View等）它们之间都是什么关系？

[angelcool]

VC向导自动生成的东东（**，**Doc,**View等）它们之间都是什么关系？
每个文档都负责什么职能？
比如：我要获取窗口的消息，应该在哪里接收又在哪里处理？

这些文档的功能在针对对话框、单文档、多文档时，是完全一样还是又各不相同呢？

[老夏Max]

这个东东还是好好看看《深入浅出MFC》吧。
这些东东就是MFC所谓的框架！联系比较紧密。

[zcpingx]

（一）、了解文档/视结构
MFC应用程序模型历经多年以有了相当大的发展。有一个时期，它只是个使用应用程序对象和主窗口对象的简单模型。在这个模型中，应用程序的数据作为成员变量保持在框架窗口类中，在框架窗口的客户区中，该数据被提交显示器。随着MFC2。0的问世，一种应用程序结构的新方式----MFC文档/视结构出现了。在这种结构中，CFrameWnd繁重的任务被委派给几个不同类，实现了数据存储和显示的分离。一般情况下，采用文档/视结构的应用程序至少应由以下对象组成：
。应用程序是一个CwinApp派生对象，它充当全部应用程序的容器。应用程序沿消息映射网络分配消息给它的所有子程序。
。框架窗口是一CfrmeWnd派生对象。
。文档是一个CDocument派生对象，它存储应用程序的数据，并把这些信息提供给应用程序的其余部分。
。视窗是Cview派生对象，它与其父框架窗口用户区对齐。视窗接受用户对应用程序的输入并显示相关联的文档数据。
通常，应用程序数据存在于简单模型中的框架窗口中。在文档/视方式中，该数据移入称为document的独立数据对象。当然，文档不一定是文字，文档是可以表现应用程序使用的数据集的抽象术语。而用户输入处理及图形输出功能从框架窗口转向视图。单独的视窗完全遮蔽框架窗口的客户区，这意味着即使程序员直接绘画至框架窗口的客户区，视图仍遮蔽绘画，在屏幕上不出现任何信息。所以输出必须通过视图。框架窗口仅仅是个视图容器。
CDocument类对文档的建立及归档提供支持并提供应用程序用于控制其数据的接口。MDI应用程序可以处理多个类型的文档，每个类型的文档拥有一个相关联的文档模板对象。文档对象驻留在场景后面，提供由视图对象显示的信息。文档至少有一个相关联的视图。视图只能与一个文档相关联。
在文档/视方式中，对象的建立是由文档模板来管理的，它是CDocTemplate派生对象，建立并维护框架窗口，文档及视。
MFC调用命令处理程序以响应发生在应用程序中的事件。命令发送的优先级是：
活动的视图->框架窗口->文档->应用程序->默认窗口过程(DefWindowsProc)
总之，在文档/视方式中，文档和视是分离的，即：文档用于保存数据，而视是用来显示这些数据。文档模板维护它们之间的关西。这种文档/视结构在开发大型软件项目时特别有用。
（二）、了解与文档/视结构有关的各种类之间的关系。
在文档/视应用程序中，CWinApp对象拥有并控制文档模板，后者产生文档、框架窗口及视窗。这种相互关系如图（1）所示：

[angelcool]

to vcleaner(我没当大哥很久了.......)
你还真爱占一楼！！！
不过我也会继续看这本牛书，就是太难懂了，希望你们这些牛人时时提点

to zcpingx(横屋)
多谢！
请继续

[老夏Max]

呵呵，那本牛书不是一遍就能看懂的。俺看了4遍，写了一些测试程序，那本牛书虽然列举了很多MFC的源代码，但是要弄清楚本质那点源代码还是不够的，自己到VC的安装目录下多看看源代码。或者写一个程序，单步跟踪到MFC源代码中看看它到底做了什么。一切就是那么简单！

[老夏Max]

我现在觉得那本牛书给我的帮助并不是了解了MFC，其实它教会我们学习的方法才最为重要。以前俺也是App Wizard生成程序，使用MFC的函数修改，完成我需要的功能，但是只能知其然，不能知其所以然，看了这本书以后让我养成一个好的习惯就是一切都要知道根本，习惯看MFC的源代码。ATL也提供了源代码，所以学习这个东东都是一种习惯而已！

[angelcool]

难道就没有什么快捷的方法或是什么好书能帮助我们这些菜鸟早日高飞吗？
不过回过来想，要真有这样的方法或好书也就不是难倒终生的VC了！！

不过经验还是要与人分享的，所以牛人们请不要吝啬你的财富！！
多谢！！

[sjcode]

深入浅出mfc里，后面，说的非常清楚，你一边看，一边debug,进到mfc代码里，一看就懂了

[meloncocoo]

:)

[angelcool]

hello!!!