MFC框架应用.net界面

问题：

MS生产的VS2005真的是一副超级庞大且复杂的开发机器，不说别的，光说C++语言它就支持MFC、ATL和CLR等几种类库和开发框架，它的复杂性不言而喻。按常理来说，一件事物一旦复杂到一定程度，总会有它隐藏起来的缺陷，说缺陷有些不好听，对于开发工具来说就是有一些令人费解的地方，比如我们要讨论的一个问题，开发一个界面，对于Windows界面来说，界面有旧的Windows风格和新的Windows风格，这里新的风格就是XP风格，也就是.net开发用到的界面风格。不要说新风格一定就比旧风格漂亮，每个人的看法不一样，很多人就喜欢旧的风格。开发工具应该支持很多种风格，应该很容易地在哪个地方设置，结果VS2005把这些都藏到不知道什么地方去了，用MFC开发出来的程序界面如果使用多字节字符集编译就会产生旧的Windows风格，如果使用Unicode字符集编译就会产生新的Windows风格，如果用CLR开发的话做出来都是新风格。这里最让人不解的是界面风格竟然和编码字符集有关。虽然一种字符集对应一种界面风格，但总有它不方便的地方，比如我就是要用多字节来编码，同时还要产生新的界面风格，这一招就不好使了，况且，当我要用MFC开发控件的时候，不管用什么字符集编码都只产生旧风格，这一招也不管用，这时就得想另外的招了。

解决方法一：

有一个广为流传且非常好用的简单方法是用一个manifest文件(也称为清单文件)放在应用程序的目录下，并且起一个和应用程序一样的名字，这样风格立马就改了。这个文件的内容在网上随便一搜就有了。这一招对旧开发工具(比如VC6)做出来的程序特别管用。但有一个不好的地方是多出来一个manifest文件，怎么看怎么别扭，有人称之为“负担”。所以有牛人就找出一种方法把manifest文件嵌到了exe程序里去了。

方法一局限：

但这个方法对于VS2005开发就不管用了，这一块有很多东西要说。同时这个方法只对exe文件管用，对于dll及控件文件等也不起作用了，仍然有它非常局限的一面。

前面说manifest文件产生新Windows风格对于VS2005开发不管用，是因为VS2005本身就产生manifest文件，并且可以单独存在，也可以嵌入到exe中，对于dll及ocx文件也一样，这样外来的那个manifest文件，要也没用，不要也不行，就没法办了。

灵感：

这时，某个人灵光一闪，忽然想到，为什么不能把外来的manifest文件换掉要嵌入最终程序的manifest文件呢？如果能这样的话，不就行了。

解决方法二：

VS2005虽然很庞大，但是生成最终程序的时候也是一步一步执行的，先干什么，后干什么，每一步都可能是由某一小工具来完成的，最后一步就是嵌入清单这个过程。经过查资料后，某人发现这个工具放在VS2005的工具目录下，叫做mt.exe，是在命令行下运行的，用于把一个程序文件(exe/dll/ocx)和一个清单文件合并。也就是说VS2005可以设置为不嵌入清单的，产生的文件包括程序文件和清单文件，也可以设置为嵌入清单的，那VS2005帮我们做了合并应用程序和清单这一步工作了，最终就是一个程序文件。这时我们可以在最后一步上做手脚，先生成不嵌入清单的文件，包括程序文件和清单文件，然后我们用产生新窗口风格的清单文件来替换自动生成的清单文件，最后用mt.exe来合并它们。呵呵，这样直接替换估计不行，不管怎么说，先试试再说，一试，果然，程序崩溃了。

最终解决方法：

看来要在清单文件内部做手术，把生成风格的清单文件的核心部分截取出来，然后安到自动生成的清单文件内部，这么一整合，既没有破坏原来的清单结构，又加上了生成风格的部分。来，试试，经过mt.exe再一整，果然成功！试完exe的再试ocx的，哈哈，非常完美！

一点心得：

如果没有弄懂界面显示的原理，最好不要深究其内部，当产生这个问题时，我曾经深陷到MFC框架中不能自拔，在频频碰壁且不得要领之后，把目光转向了相似问题的解决方法，最终使用了比较“非代码化”的解决方法并解决了问题。

后记和感想：

在当今社会，一切工作都在围绕着效率转，技术人员有了问题，首要的解决方式就是百度或谷歌，当遇到一般的问题时，往往会很快解决，但是当遇到深入开发架构内部的问题时就一筹莫展了。造成这个现象的原因之一是软件开发行业进入到了“快餐时代”，各种开发框架过度的封装，使得开发者不需要掌握太多的软件知识就可以编写相当不错的程序。一个软件公司只要稍微懂得一点软件工程，就可以组织多人实施中小型项目。这种模块化、高效率的软件开发模式受益的是老板和客户，不太受益的是软件开发者，虽然一些刚刚入门的程序员不那么认为，因为软件开发者的核心利益是知识和技术水平。打个比方来说，会开机器的工人不是很牛的工人，而会修机器甚至会造机器的工人才是真正厉害的工人。即使对客户和老板来说，目前的开发方式也有它不利的一面，因为这些开发框架和封闭的类库隐藏了太多的底层细节，且这些底层程序也不可能是无所不能且完美无瑕的，一旦有客户（或老板）提出一些比较有个性的需求时，这些框架有可能就无能为力了。或者说当偶尔出现开发框架底层的错误时，（特别是Bug不算少的框架，比如VS2005），沉迷于此的程序员也就束手无策了。

所以程序员要抓紧一切机会学习任何知识，特别是出现问题的时候，利用解决问题的这个绝佳的机会学习任何涉及到的知识，尤其是平时工作很少涉及到的底层知识。以这样的方式获得的印象会比较深刻，也许只有通过这种方式，一个普通程序员才能进化为内外兼修的大牛级程序员。