(转)COM开发拾粹

将近一年的时间,我一直在用VC的ATL开发COM组件,其间遇到过不少的障碍,经过努力,大多数已经解决。在这这个过程中,积累下一了点经验,现在写下来,还是为了那两个目的:整理存档;和大家共享一些心得。

1. ProgID在哪里

这是我刚会用ATL向导时遇到的第一个问题。想修改ProgID却怎么也找不到。原来它躲在和组件同名的.rgs文件里,rgs是组件注册的脚本文件,当你用 Regsvr32.exe注册组件时,组件内部便是调用了这个文件。rgs文件是以资源的形式存于DLL内的。

2.手工添加一个方法,该修改哪些地方。

   假设组件类名叫CObj,接口叫IObj,要加入的方法是Open。首先在IDL文件中找到接口IObj的定义,在其中加入如下方法定义:

   [id(2), helpstring("method Open")] HRESULT Open([out,retval] VARIANT_BOOL *ret);

注意:id中的数字不要和已经存在的id重复

其次,在CObj的类定义头文件中加入如下成员函数声明:

public:

   STDMETHOD(Open)(VARIANT_BOOL *ret);

最后,在CObj类的实现Cpp文件中加入函数的实现:

STDMETHODIMP Open(VARIANT_BOOL *ret)

{

   *ret = VARAINT_TRUE;

   return S_OK;

}

3. 多用断言帮助调试

   COM组件是一个个独立的实体,它并不知道调用它的环境,也不知道调用者是否按开发者的约定来调用它。所以应该多用ATLASSERT来设置检查点,以便于调试。例如一个数据库连接组件,在Open方法里就首先要用断言检查ConnectionString属性是否被赋值:

   ATLASSERT(m_ConnStr != NULL);

断言后应该紧跟着写错误处理程序,因为在Release版中,断言全部无效了,你的错误处理代码就该发挥作用了。

if(m_ConnStr == NULL)

   return E_FAIL;

断言失败到底要不要处呢?这里提供一种判断原 则:你开发的COM是一个自己的软件内部使用的COM,也就是客户端和COM都是你一人或开发组内部开发时,可以不处理断言失败,而去检查使断言失败的客 户端的代码是否不完善;当你写的COM是要提交给”别人”使用时就要处理断言失败。

4. 写一些可以”偷懒”的宏。

如果一个组件有很多的属性,而对属性的处理不过是直接存取成员变量,写很多的get、put函数有点烦人。这些函数体看起来几乎一样,只是存取的数据类型不同:

get函数体: *pVal = m_SomeMemberVar;

put函数体: m_SomeMemberVar = newVal;

我们不妨写一组宏来处理这种无聊的工作。受ATL中Copy策略类的启发,我写了下的宏:

//实现属性写操作的通用宏

#define PROP_PUT_IMPL(Name,Type)         /

   STDMETHOD(put_##Name)(Type newVal)        /

   {                             /

      m_##Name = newVal;               /

      return S_OK;                            /

   }

//实现属性读操作的通用宏

#define PROP_GET_IMPL(Name,Type,CopyAdapter)    /

   STDMETHOD(get_##Name)(Type* pVal)           /

   {                                            /

      CopyAdapter::destroy(pVal);             /

      Type src = m_##Name;                    /

      return CopyAdapter::copy(pVal, &src);   /

   }

//实现读写属性的通用宏

#define PROP_IMPL(Name,Type,CopyAdapter)        /

   PROP_PUT_IMPL(Name,Type)                    /

   PROP_GET_IMPL(Name,Type,CopyAdapter)

使用这个宏的前提是保存属性的成员函数的命名必须是:”m_属性名”这样的形式,如有一个读写属性 Name,类型为BSTR,我可以在对像类中这样实现它

class   ATL_NO_VTABLE CObj

{

… …

public:

PROP_IMPL(Name,BSTR,CopyBSTR)

private:

CComBSTR m_Name;
}

CopyBSTR是我写的一个Copy策略类,如下:

class CopyBSTR

{

public:

   static HRESULT copy(BSTR* p1, BSTR* p2)

   {

      ATLASSERT(p2 != NULL);

      if(p2 == NULL)

         return E_POINTER;

      CComBSTR bstrTemp = *p2;

      return bstrTemp.CopyTo(p1);

   }

   static void init(BSTR* str) {}

   static void destroy(BSTR* str) {SysFreeString(*str);}

};

实现只读属性也很简单:

……

public:

      PROP_GET_IMPL(Name,BSTR,CopyBSTR)

private:

      m_Name;

实现一些常用类型的写法如下:

PROP_IMPL(PropName,long,_Copy<long>)

PROP_IMPL(PropName,short,_Copy<short>)

PROP_IMPL(PropName,VARAINT_BOOL,_Copy<VARAINT_BOOL>)

PROP_IMPL(PropName,IDispatch*,_CopyInterface<IDispatch*>)

PROP_IMPL(PropName,BSTR,CopyBSTR)

使用这个宏还有个附加的好处:定义的都是inline函数,效率会比向导生成的函数体好。

还有一种代码段是很常用的,形如:

   HRESULT hr = Obj->MethodCall();

if(FAILED(hr))

   return hr;

我们可以定义这样的宏来代替它:

#define RET_ERR_IF_FAIL(exp)        /

   do {                           /

      HRESULT __hr = (exp);         /

      if(FAILED(hr) return hr;           /

   } while(false)

然后这样使用:

   RET_ERR_IF_FAIL(Obj->MethodCall());

   RET_ERR_IF_FAIL(Obj->MethodCall2());

怎么样,代码整洁多了吧。

5.BSTR的使用

初学COM肯定要在BSTR上栽跟头,分配、释 放弄得一头雾水,内存泄露在所难免。劝大家尽量不要直接使用BSTR,用封装类_bstr_t和CComBSTR取而代之。_bstr_t是一个类,它是 MS对ANSI C++的扩展,有了它,你可以在SDK方式中(非MFC、ATL)方便的使用BSTR类型。CComBSTR是ATL中对BSTR的封装。用ATL开发 时,一般情况下可以用CComBSTR类。在属性的读取函数中,可以用CComBSTR的CopyTo方法返回一个BSTR。CComBSTR重载了取地 址运算符&,对CComBSTR取地址等于对它内部的BSTR取地址,这样,CComBSTR也可以用在方法的out,retval类型参数上, 例如:

有某COM类的某方法定义如下:

   HRESULT GetUserName([in]BSTR UserID,[out,retval]BSTR *UserName);

此方法内部可如下实现返回UserName的代码:

……

m_UserName.CopyTo(UserName);//m_UserName为成员变量,类型为CComBSTR

而此COM的客户端调用GetUserName时,也可以用CComBSTR类型变量来得到UserName.

……

CComBSTR bstrUserID(L”001”),bstrUserName;

Obj->GetUserName(bstrUserID,&bstrUserName);

不管是方法GetUserName内部还是客户端,都能够正确的自动的分配、释放内存。只有一种情况例外,那就是连续使用一个CComBSTR变量作为输出参数的实参时,如果处理不当会产生内存泄露。如:

   CComBSTR bstrFieldName,bstrFieldValue;

   bstrFieldName = L”usr_id”;

   RecordsetObj->GetFieldValueAsString(bstrFieldName,&bstrFieldValue);

   m_UserID = bstrFieldValue;

   bstrFieldName = L”usr_name”;

   RecordsetObj->GetFieldValueAsString(bstrFieldName,&bstrFieldValue); //如果方法内部实现直接覆盖&bstrFieldValue指针,则bstr上次的值会丢失。如果内部是用的CComBSTR.CopyTo则 不会。

   _bstr_t类型不是不好,但我们总是在迫不得以时才会用它,也就是用#import预编译指令导入一个COM的封装类时。用import导入的封装类 只用_bstr_t类型作为BSTR参数类型,而在CComBSTR、_bstr_t、BSTR之间来回转换也是顶麻烦的事。于是我仿照CAdapt类写 了一个CBSTRAdapt来自动完成转换的工作。

   class CBSTRAdapt

{

    _bstr_t m_str;

public:

    CBSTRAdapt(const _bstr_t& str)

    {

       m_str = str;

    }

    CBSTRAdapt(const BSTR str)

    {

       m_str = str;

    }

    CBSTRAdapt(const CComBSTR& str)

    {

       m_str = str.m_str;

    }

    operator BSTR()

    {

        return m_str.GetBSTR();

    }

    operator _bstr_t()

    {

        return m_str;

    }

    operator CComBSTR()

    {

        return CComBSTR(m_str.GetBSTR());

    }

};

它的主要用途是完成从CComBSTR到_bstr_t的转换。

例如有要调用如下方法:

bool   IsLogin(_bstr_t UserID);

调用代码如下:

CComBSTR bstrUserID(L”007”);

if(Obj->IsLogin(CBSTRAdapt(bstrUserID))

{

……

}

5.自定义错误代码?HRESULT?异常?

COM中的出错处理可以有多种选择,比如用方法的[out,retval]参数返回自定义的错误代码;或返回标准的以及自定义的HRESULT值;抛出异常也是一种选择。采用哪种方法要根据实际情况而定。

返回自 定义错误代码是一种源自C语言结构化设计的传统方法,它放弃了C++以及COM的出错处理机制,采用自建的处理方法。代码上少不了要写很多的switch -case语句以捕捉错误代码进行处理。它的缺点是最外层代码要想得到最内层的错误的话,则中间层就必须如实的返回内层的出错代码,这样一层层的”抄送” 给最外层。带来的负作用就是灵活性非常差。

异常(exception)可以解决这个问题。但在COM规范里规定,一个COM组件不 能让任何异常逃脱到这个COM之外,原因是你不知道调用这个COM的客户端语言是否支持异常机制,它能不能捕获(catch)到这个异常。规定是死的,人 的活的。如果客户端缺定也是C++编写的,并且你也不需要编写那么”规范”的COM,而只要实用就行,那么从COM里抛出异常,客户端来捕获又何妨?不 过,这种”玩法”最好仅在进程内DLL中使用,跨进程、跨机器的异常能不能被正常捕获,COM规范里可没承诺什么,本来你就没用COM的推荐方法嘛。

那什么 是COM的推荐方法,答案是HRESULT。我们可以返回一个HRESULT值表示某种错误。很多情况下,我们都懒得去查预定义的HRESULT值,更不 愿意自已定义HRESULT了,于是几乎所有的方法都是返回S_OK或E_FAIL。其实32位长的HRESULT给我们留出了充足的空间来定义自已的错 误码。你可以把HRESULT值定义在IDL文件中,这样当客户端#import这个COM时,也会把定义自动加到*.tlh文件中,无需附加的.h文件 声明:

cpp_quote("//自定义错误码")

cpp_quote("#define E_IDNOTFOUND 0x8000F001")

cpp_quote("#define E_IDEXIST 0x8000F002")

cpp_quote("#define E_IDREQUIRED 0x8000F003")

客户端处理HRESULT值分为两种情况。如果你用VC写客户端,用#import预编译指令生成了COM的智能封装,那么这个封装会自动把错误的返回码转成一个异常抛出。如下面是#import生成的封装代码:

inline _variant_t IContext::GetContextValue ( _bstr_t PropName ) {

    VARIANT _result;

    VariantInit(&_result);

    HRESULT _hr = get_ContextValue(PropName, &_result); //调用真正的方法

    if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this)); //如果返回一个ERROR值,_com_issue_errorex就抛出异常

    return _variant_t(_result, false);

}

这样的封装代码让我们即可以享受到特定语言(C++)提供的便利,又可以在开发COM时遵守统一的规范而不需根据客户端作特殊的处理。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值