关于如何换肤、子类化的解决方案

核心提示：第六种：使用第三方的库Skin++(www.uipower.com)实现换肤第七种：用第三方应用程序给整个windows换肤(windowblinds)以上七种方式各有优缺点，我在使用过程中也遇到不少问题，关于如何换肤、子类化的解决方案(3)，现在一一道来，希望和大家共同解决问题，在 MessageBox 弹出的对话框

第六种：使用第三方的库Skin++(www.uipower.com)实现换肤

第七种：用第三方应用程序给整个windows换肤(windowblinds)

以上七种方式各有优缺点。我在使用过程中也遇到不少问题，现在一一道来，希望和大家共同解决问题。先排除几种不准备深入探讨的方式：

第五种，manifest 方式最快速和简洁，但是功能有限，存在严重的平台限制，不过好处在于应用程序可以和windows共一种风格。

第六种，使用第三方的库 Skin++(www.uipower.com) 实现换肤方式使用起来很简单，定制性也不错，可供选择的皮肤种类非常的多，支持的语言非常广泛，可以称得上是换肤功能的终结者，对于共享软件开发者和注重界面的企业来说是个不错的解决方案，他的换肤理念很新，有些地方做得很独特，比如可以对 BCG 换肤等，有些技术点，很多同类产品都没有做到，比如 ComboBox 的滚动条，系统对话框（open or close Dialog）的菜单等等。

第七种，属于自娱性质的，也就不多说了。

第一种，直接使用现成的类，属于很常见的一种用法，一般来说使用上不会出什么问题，缺点就不说了，如果这种方式让我满意，我就不必发这篇帖子了。

下面看看第二三四种：

第二种是用 HOOK+ 窗口类，实现起来比较方便，和做一个自绘控件的工作量其实是一样的。

第三种是用HOOK+窗口过程，实现起来比较麻烦，需要自己处理一堆switch case, 自己转换消息参数，自己找地方维护一堆状态变量，工作量很大。

第四种不用 HOOK 的方式，有个缺点：对被换肤的程序的源代码的修改比较多。当然，直接到进程中去找窗口句柄，然后子类化那么就不用源代码了，不过这样的话还不如用HOOK呢。

实际上，HOOK机制和枚举窗体虽然过程不同，不过最终目的是一样的，都是为了子类化窗口。所以在此不去探讨孰优孰劣了。现在切入正题，谈谈在子类化过程中遇到的问题：

一个是重复 subclass 的问题，上面提到，子类化的两种方式：用窗口类或者用窗口过程。使用窗口类是从CWnd派生一个类，调用CWnd 的 protected 函数 SubclassWindow。可是如果正常使用一个窗口类(声明成员变量，加入DDX_Control)，实际上在 DDX_Control 中也是是用了 SubclassWindow 的。假如为一个控件声明变量，而在 Hook 中又进行了子类化，结果会怎么样呢？答案是：程序崩溃或弹出消息框"不支持的操作"。因为 SubclassWindow 函数调用前是要先 Attach 到一个HWND上去的。重复的 Attach 看来是不允许。要避免程序崩溃也有办法：

1、只为控件声明一个指针变量，动态的去获取CWnd类的实例，但是这样就达不到换肤的目的了。

2、还有一种方法，经过我试验，如果两个SubclassWindow的调用位于不同的模块，例如一个位于exe，一个位于dll(我是通过exe中调用dll中的函数显示该dll中的对话框来测试的)，那么就不会出现问题。在还没有找到更好的方法之前，这也姑且算是一种解决方法吧。

但是如果使用窗口过程来子类化，就不存在重复subclass的问题了，只要小心处理，子类化无数次都没问题，但是对于复杂的自绘事件，在一个窗口过程中来写switch语句，好像很麻烦。

我尝试过自己写一个新的SubclassWindow函数来尝试借用CWnd的窗口过程，这样就可以按照MFC的方式来写消息响应函数了。只可惜，最终还是无功而返，因为SubclassWindow不是虚函数，而CWnd的窗口过程是作为一个protected成员存在的。所以没法在外部借用MFC的消息机制。所以，自己写代码处理 wParam 和 lParam 看来在所难免。

零一个是子类化系统对话框的问题，系统的对话框和自己的对话框表现的总不一样。目前我还没有对所有的系统对话框进行测试。在 MessageBox 弹出的对话框中遇到的问题可以见我这一片帖子：http://community.csdn.net/Expert/To....asp?id=3103399

在文件对话框中我遇到一个问题，子类化过的 CStatic 的背景好像没有重绘一样，照理说应该由CStatic的父窗体负责背景的。