CSDN博客

img justleon

COM开发拾粹<一>

发表于2003/4/21 9:00:00  2882人阅读

分类: visual C++

COM开发拾粹<>

   将近一年的时间,我一直在用VCATL开发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. 写一些可以偷懒的宏。

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

get函数体:  *pVal = m_SomeMemberVar;

put函数体:  m_SomeMemberVar = newVal;

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

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

#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_tCComBSTR取而代之。_bstr_t是一个类,它是MSANSI C++的扩展,有了它,你可以在SDK方式中(非MFCATL)方便的使用BSTR类型。CComBSTRATL中对BSTR的封装。用ATL开发时,一般情况下可以用CComBSTR类。在属性的读取函数中,可以用CComBSTRCopyTo方法返回一个BSTRCComBSTR重载了取地址运算符&,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_tBSTR之间来回转换也是顶麻烦的事。于是我仿照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))

{

……

}

 

0 0

相关博文

我的热门文章

img
取 消
img