技術資料/COM

全般 †

なぜCOMが必要なのか †

COM通信は大きく分けて以下の3つが挙げられる。

1. 同一プロセス内でのCOM通信。DLL形式のCOMサーバを用いる。
2. 異なるプロセス間でのCOM通信。マーシャリングという仕組みによって実現される。EXE形式のCOMサーバを用いる。
3. 異なるマシン間でのCOM通信。ネットワークを介して通信される。DCOMと呼ばれる。

このうち、2番目と3番目の通信方法を実現するためにはCOMは有効である。しかし、1番目の同一プロセス内での通信は、COMではない通常のDLLでも実現可能である。
それでもCOM通信を用いる理由は、通常のDLLは使用する際に以下の制約があるからである。

• DLLを使用するアプリケーション側とDLL側で、関数の呼出規約を合わせる必要がある。
  しかし、言語によっては呼出規約を自由に決められない場合がある。
• DLLを使用するアプリケーション側と、DLL側で、関数のマネージド/アンマネージドを合わせる必要がある。
  しかし、言語によっては.NETフレームワークを使用できず、マネージドコードを作れない場合がある。

関連用語 †

参考リンク †

http://msdn.microsoft.com/ja-jp/vstudio/ffd7bcba-8a24-41c8-8f86-92c55c65fbde.aspx
http://program.station.ez-net.jp/special/vc/atl-com/variant.asp
http://www.tomosan.org/dev/vs/activex.html
http://www.ops.dti.ne.jp/~allergy/com/com.html
http://atata.sakura.ne.jp/

注意事項 †

• ATLによるCOMのレジストリ登録で、パスに2バイト文字が使われていると正常に登録できない。→リンク

データ型 †

Variant型 †

様々なデータ型を格納するために、保持するデータ型のIDと実際のデータを共用体で格納する。

関連する関数等。

(C++からVARIANT型の変数を渡す場合)

1. VARIANT型変数を、VariantInit()で初期化。
2. VARIANT::vt に VARENUM列挙体 からデータ型を代入。
3. データ型に合った共用体のメンバ変数に値を代入。
4. 値を渡す。
5. VARIANT型変数を、VariantClear()でクリア。

(C++でVARIANT型の変数を受け取る場合)

1. VARIANT型変数を、VariantInit()で初期化。
2. 値を受け取る。
3. データ型に合った共用体のメンバ変数から直接値をコピーしたり、VariantChangeType()でデータを変換することで操作可能。

BSTR型 †

実体は wchar_t*型のUnicode文字列。ただし、通常の文字列とは異なる仕様を持つ。

• 先頭から前4バイト分が文字数を表す。
• 文字列中にNULL文字を埋め込むことができる。逆にいえば、NULL文字が文字列の終端を表さない。

関連する関数等。

メモリの扱いについて。→参考

• 入力値(引数)にBSTR型を持つメソッド
  BSTRのメモリ確保、解放はクライアント(呼び出し)側が行う。
• 出力値(引数、戻り値)にBSTR型を持つメソッド
  BSTRのメモリ確保はサーバ(メソッド実装)側が、解放はクライアント(呼び出し)側が行う。（クライアントがVBであれば、string型を使うことでスコープを抜けるときに自動的に解放されるはず？）

BSTR型を扱うときは、メモリリークしないように注意する。
以下は、_bstr_tクラスの扱いによるメモリリークの有無の例。

• メモリリークしない例

  1 2 3 4 5 6 7 8 9

  BSTR bstr = NULL; // COMのメソッドを呼び出す m_pTestCom->GetString(&bstr); // コンストラクタを使用して格納(第2引数をfalseにすることで、bstr自身にアタッチする) _bstr_t bstrt(bstr, false); // _bstr_tクラスのデストラクタで、bstrが解放される

• メモリリークする例

  1 2 3 4 5 6 7 8 9 10 11

  BSTR bstr = NULL; _bstr_t bstrt; // COMのメソッドを呼び出す m_pTestCom->GetString(&bstr); // =演算子を使用する(bstrのコピーが格納される) bstrt = bstr; // _bstr_tクラスのデストラクタではコピーした文字列の解放を行うため、 // 元のbstrは解放されないまま残ってしまう

配列型 †

次元数や要素数と、データを指すポインタを持つ構造体。

関連する関数等。

HRESULT型 †

VARIANT_BOOL型 †

COMで使用する真理値型。C言語で使用するBOOL型やbool型とは値が異なり、VBの真理値型と同じ値となる。

• 真(VARIANT_TRUE) : -1
• 偽(VARIANT_FALSE) : 0

スマートポインタ †

COMオブジェクトは使い終わったら必ず解放しなければならないが、スマートポインタを使用するとスコープを抜けるときに自動的にCOMオブジェクトの解放を行ってくれる。

関連する関数等。

オブジェクトの生成 †

CComPtr<T> はテンプレートクラスとして定義されているため、生成したいオブジェクトでポインタを定義する。

  1

    CComPtr<ISampleObject> pSampleObj;

実際の生成には、CComPtr<T>::CoCreateInstance() を用いる。

オブジェクトの代入 †

CComPtr<T>型の変数を定義し、既に生成済みのCOMオブジェクトを代入するときには、「=」演算子を使用してはいけない。「=」演算子はオーバロードされており、COMオブジェクトの参照カウントがインクリメントされてしまう。
代入には、基底クラスのCComPtrBase<T>::Attach() を用いる

  1
  2
  3

    // pIFooObj はスマートポインタではなく、ISampleObject型のポインタ
    pISampleObj = pIFooObj;         // ×
    pISampleObj.Attach(pIFooObj);   // ○

また、CComPtr<T>オブジェクトとして生成済みのCOMオブジェクトのアドレスを別の変数や関数に渡すときは、メンバ変数 CComPtr<T>::p を用いる。

オブジェクトの関数の呼び出し †

オーバロードされた演算子「->」を用いる。つまり、スマートポインタであることを意識せずに関数呼び出しを行うことができる。

  1
  2

    // 通常のCOMオブジェクトのように使用できる
    pISampleObj->Func();

オブジェクトの解放 †

何もする必要はない。デストラクタで解放を行ってくれるため、スコープを抜けるときに自動的にCOMオブジェクトが解放される。
もし明示的にCOMオブジェクトの解放を行う場合は、内部のオブジェクトを直接解放するのではなく、CComPtr<T>::Release() を用いる。「->」演算子を使用してはいけないことに注意。

  1
  2

    pISampleObj->Release();     // ×
    pISampleObj.Release();      // ○

また、スコープを抜けるときに自動的に解放されたくない場合は、基底クラスのCComPtrBase<T>::Detach() を用いてCOMオブジェクトをスマートポインタから切り離す。

COM識別子(GUID) †

COMサーバを識別するために、GUIDという128ビットの値を用いる。
GUIDは5グループの16進文字列で表わされる。それぞれ、8, 4, 4, 4, 12文字。

  1
  2
  3
  4
  5
  6
  7
  8

    // GUIDの例
    AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE
 
    // GUID構造体
    GUID::Data1    (DWORD) // AAAAAAAA
    GUID::Data2    (WORD)  // BBBB
    GUID::Data3    (WORD)  // CCCC
    GUID::Data4[8] (BYTE)  // DDDD-EEEEEEEEEEEE

ProgID †

COMサーバを識別するための文字列。VB系言語で CreateObject() に引数として渡す文字列。内部的には対応するCLSIDに変換される。

CLSID †

COMクラスの識別子で、GUIDで表わされる。
GUID型にtypedefされている。また、「REFCLSID」という識別子が、CLSID型の参照型として定義されている。（C言語ではポインタ型）

IID †

COMクラス内のインタフェースの識別子で、GUIDで表わされる。
GUID型にtypedefされている。また、「REFIID」という識別子が、CLSID型の参照型として定義されている。（C言語ではポインタ型）

その他 †

• FMTID

  プロパティセットフォーマットの識別子で、GUIDで表わされる。(typedefされている。)

• CATID

  コンポーネントカテゴリの識別子で、GUIDで表わされる。(typedefされている。)

インタフェース定義ファイルの生成の流れ †

サーバもクライアントも、使用するインタフェースの定義はIDLファイルやタイプライブラリを用いる。通常、インタフェースの作成者が用意して、サーバもクライアントも同じ定義を使用する。
C++で実装を行う場合、インタフェースの定義をヘッダファイルやソースファイルに置き換える必要がある。

以下にファイルの生成の流れを示す。
File not found: "ref001.PNG" at page "技術資料/COM"[添付]

デバッグのヒント †

• atlbase.hをインクルードする前に_ATL_DEBUG_INTERFACESマクロを定義しておくことで、COMの参照カウントの増減をトレースできる。（デバッグウィンドウに表示される。）

  1 2 3

  // ATLの使用開始をウィザードで行った場合、stdafx.hでatlbase.hがインクルードされているはず #define _ATL_DEBUG_INTERFACES #include <atlbase.h>

#importディレクティブのオプション †

COMクライアント †

COMコンポーネントをバインドする2種類の方法 †

アーリーバインディングとレイトバインディングの2種類の方法が存在する。

実装手順 †

1. COMの使用開始

   スレッド内でCOMを使う前に、::CoInitialize() をコールする。

2. COMオブジェクトの定義、生成
3. COMオブジェクトの使用
4. COMオブジェクトの解放
5. COMの使用終了

   スレッド内でCOMを使い終えたら、::CoUninitialize() をコールする。
   使用したインタフェースの解放時には参照カウントがデクリメントされるだけで、実際にプロセスが削除されるのはこのタイミング？

COMサーバ(COMコンポーネント) †

レジストリ登録 †

COMコンポーネントは、レジストリに自分のパスとGUIDを登録しておく必要がある。

DLL形式のCOMサーバ †

• 登録

  regsvr32 xxx.dll

• 解除

  regsvr32 /u xxx.dll

EXE形式のCOMサーバ †

• 登録

  xxx.exe /RegServer

• 解除

  xxx.exe /UnregServer

タイプライブラリのバイナリへの埋め込み †

VisualStudioでCOMサーバを作成すると、リソースにCLSIDをレジストリ登録するためのレジストリスクリプトが埋め込まれるが、それだけではIIDの登録は行われない。IIDの登録には、COMサーバのビルド時に作られるtlbファイルが必要になる。

tlbファイルは、レジストリ登録時にCOMサーバと同じ場所に置いておくと認識される。また、リソースにtlbファイルを指定することでexeやdllにtlb情報を埋め込むこともできる。その場合はtlbファイルは必要ない。（DLL形式のCOMサーバの場合は、自動的にtlbを埋め込むようにリソースが作られているはず）

リソースへtlbファイルを埋め込むには、rcファイルの「3 TEXTINCLUDE DISCARDABLE」ブロックの末尾に相対パスでtibファイルを指定するコードを追加する。

3 TEXTINCLUDE DISCARDABLE 
BEGIN
    ：
    "#ifdef _DEBUG\r\n"
    "1 TYPELIB ""Debug\\xxx.tlb""\r\n"
    "#else\r\n"
    "1 TYPELIB ""Release\\xxx.tlb""\r\n"
    "#endif    // _DEBUG\r\n"
    "\0"
END

※tlbファイルは相対パスを指定する必要があるが、EXE形式のCOMサーバの場合はDebug/Releaseそれぞれのフォルダでtlbファイルが作成されるため、条件分岐させた。

参考リンク1 参考リンク2

VBアプリケーションによる自動登録 †

VBで作成されたアプリケーションは、自身が参照するOCXがレジストリに見つからない場合、起動時にエラーとなる場合がある。しかし、このときDLL/OCXの検索順序?に従ってCOMコンポーネントを検索して見つかると、自動的にレジストリ登録(regsvr32)するようである。そのため、次回からは起動時にエラーとならずアプリケーションを使用することができる。

実装すべきインタフェース †

• IUnknownインタフェース

  全てのCOMコンポーネントは、IUnknownインタフェースを実装する必要がある。

• IDispatchインタフェース

  デュアルインタフェースに対応する場合は、IDispatchインタフェースを実装する必要がある。
  ※IDispatchインタフェースは、IUnknownインタフェースを含む。

実装すべき機能 †

レジストリへの自己登録機能など、必要な機能を実装する。

DLL形式のCOMサーバ †

以下の4つの関数をエクスポートする必要がある。

• xxx
• xxx
• xxx
• xxx

EXE形式のCOMサーバ †

以下のコマンドラインオプションに対応する必要がある。

• /RegServer
• /UnRegServer
• /Embedding
• /Automation

不具合／注意点 †

COMサーバ(EXE形式)にウィザードによって追加されるコード †

VC++6.0でウィザードによって追加されるコードが誤っている箇所があるので注意。
COMサーバ(EXE形式)にウィザードによって追加されるコード

STAでの再入 †

COMサーバーをSTAにしておくことで、マルチスレッドで動作することはなくなる。しかし、別のCOM呼び出しをしている最中に処理が再入されることがあるので注意が必要。
（STAではシングルスレッドで動作させるために、COM呼び出しされたことをウィンドウメッセージとしてキューに溜めている。自身が別のCOM呼び出しを行っている間はメッセージループが回るため、処理が再入される。もちろん、通常のウィンドウメッセージの動作も再入されるということになる。）
参考：http://blogs.wankuma.com/melt/archive/2007/12/13/112869.aspx

SendMessage中のCOM呼び出し †

SendMessageによって別スレッドから送信されたメッセージを処理している間は、EXE(アウトプロセス)のCOMサーバーに対してのCOM呼び出しは失敗して例外が発生する。（デッドロックを防ぐため？）COM呼び出しを行う前に、::InSendMessage() でチェックをすることで防げる。
参考：http://support.microsoft.com/kb/131056/en-us