今天得闲，刚好又要处理OCX向下兼容性的问题，于是仔细查看了一下造成问题的原因，做了些简单测试，不打算从原理分析，我们暂且从表象上分析。

[问题描述]
    在使用MFC框架制作OCX时，存在向下兼容性问题。
    在旧控件的某个接口添加Property时，重新编译。你会发现原有的调用exe程序(VB编译所得)在调用该接口的Method时会出错。
    Why？按理，添加属性，不应该出现兼容问题。
    将旧有调用程序源码调出，采用新Ocx(tlb)关联，编译后，使用正常。
    当然，上述做法显然有问题，实际上如果调用者并不需要新功能，他是没有义务来做此操作的。
    所以，我们称之为向下兼容性问题。原因何在？

[查资料]
    相关书藉并未能直接找到答案。

[分析ocx特性]
    ActiveX Control是一个很特殊的COM，它使用了自动化技术。或者，更简单的说：它实现了IDispatch接口。属性以及方法也当然是由IDispath而来。我们当然应该从此接口的实现着手。IDispatch的具体略过(书上都有)，看看最关键的Invoke，GetIDsOfName。它要求每个方法/属性编号都有一个id号，通过名称找到id，然后查找相应的函数。这是IDispatch的标准。好，我们暂时只需知道这一点。其它先不管。

[分析 mfc框架代码]
    看看MFC框架做了些什么。

第1步：
    用ClassWizard添加一个属性a(非Stock)，
    嗯，在实现文件的分发映射表里加了如下：(头文件的声明略)
    BEGIN_DISPATCH_MAP(MyTest, CCmdTarget)
         //{{AFX_DISPATCH_MAP(MyTest)
         DISP_PROPERTY_EX(MyTest, "a", GetA, SetA, VT_I4)
         //}}AFX_DISPATCH_MAP
    END_DISPATCH_MAP()
在odl文件里添加了：
    properties:
        [id(1)] long a;
好了，?疑问来了：
    在odl里面的id值1，而在分发映射表里没有id值，mfc如何对应？

第2步：
    添加一个方法m，得到：
         DISP_PROPERTY_EX(MyTest, "a", GetA, SetA, VT_I4)
         DISP_FUNCTION(MyTest, "m", m, VT_EMPTY, VTS_NONE)
    methods:
         [id(2)] void m();
同样疑问，在old里有id值2，而在分发映射表里没有。

断定：
    我们可以初步断定，MFC为了偷懒，将映射表的先后次序与id值进行了隐性关联，

第3步：
    为了进一步证实这一点：我把odl中的m方法的id(2)改为id(3)，发现调用失败，
    将实现文件映射表中a与m调序，会出现类型调用错。
再次断定：
    在Ocx内部的Dispatch id值是按映射表中的次序确定。

第4步：
    接着，我们来验证再添加属性出错的问题：
    再添加属性b  在实现文件中得到：
    DISP_PROPERTY_EX(MyTest, "a", GetA, SetA, VT_I4)
    DISP_PROPERTY_EX(MyTest, "b", GetB, SetB, VT_I4)
    DISP_FUNCTION(MyTest, "m", m, VT_EMPTY, VTS_NONE)
    我们可以先猜测一下在odl中的变更：
       a的id应该是1,b的id应该是2,而m的id应该改为了3。
    打开odl，果然：
    properties:
       [id(1)] long a;
       [id(2)] long b;
    methods:
       [id(3)] void m();
再得到结论：
    MFC的ClassWizard在添加ocx的属性或方法时，首先变更的是它的实现(映射表)及头文件，
顺序按属性或方法进行大排序，新属性加在原有属性的后面，新方法加在原有方法后面。然后，
它按照映射表中的位置关系，更新了odl中的内容以及id值。
    利用MFC框架添加属性/方法时，会改变odl中方法的id值。

仔细试了一下：具体的次序应该是：
    按Notify Property、Property、Function、StockFunc、StockProp顺序

第5步：
    我们再看看Stock属性是如何处理的：
    添加一个Stock TEXT属性。
    映射表：
        DISP_STOCKPROP_TEXT()
    odl：
        [id(DISPID_TEXT), bindable, requestedit] BSTR Text;
    这似乎和上述结论有冲突，且慢，我们把DISP_STOCKPROP_TEXT展开：
    #define DISP_STOCKPROP_TEXT() \
         DISP_PROPERTY_STOCK(COleControl, "Text", DISPID_TEXT, \
         COleControl::GetText, COleControl::SetText, VT_BSTR)
    看到没有：DISPID_TEXT，它是有id值的，并且同odl里面的一样。
结论：
    利用MFC框架添加Stock属性/方法时，映射表中将存在与odl相同的预定义id值。并且不影响原有odl中的id值。
 
第6步：
    那么，改变id值为什么会造成原有代码无法正常使用呢。
    这个书上是有的，VB代码在编译，对自动化的IDispatch接口显然采用了早绑定类型库的
方式，也就是在编译时将名称转换为ID值，也就是说执行文件里已认定m的调用的id值为2。而
在新ocx中,2已经不是m，而是指向新的属性，由于类型不匹配，当然会出错。
    我们可以做个实例：
    添加属性long a, 方法 void test1(), void test2()
       (test1输出对话框"test1",test2输出对话框"test2").
    编写VB例，调用 test2，编译为exe。
       运行，得到"test2"输出。
    再添加属性b，编译ocx。
       运行先前的exe，得到 "test1"输出。
    重新编译源程序，得到”test2”输出。

结论：
    VB的早绑定，提早将id值纳入exe中，当ocx内的id发生变更时，会造成错位，即调用错误。
    (其实，如果你用VC的COleDipatchDriver方式调用，会有同样问题,id已写入代码)

总结：
    本来，按照COM、 Dispatch标准，只要名称不变，应该就能找到正确位置，id应该是个隐含值，不应成为关键。但MFC的实现显然为了偷懒，将id与映身表的次序挂上了钩，而其ClassWizard，在添加属性时，又错误的去变更了原有odl中的id值。所以造成已依赖于该id值编译的程序不兼容。

建议：
    用MFC编写OCX时，添加用户属性/方法时，不要使用ClassWizard，而是手工在映射表中添加，然后根据其相对位置，在odl中填写id值。
    添加Stock的属性和方法也要手工添加，因为它的变更，同样会触发ClassWiizard对映射表的排序和odl的同步，而造成你以往的手工编辑丢失。
    最好是将odl文件变为受控(以利于备份)，注意不接受添加属性/方法的ClassWizard的自动检出。减少误操作。如果经常需要变动属性/方法，或者也可以写一个简单的shell程序，来替代ClassWizard的相关功能，自动生成相关代码。

石头 于2005-07-12