Server"であったためです。この形式のサーバは,参照するプロセスのメモリ空間にロードされて稼動します。Becky!がPlugInとしてロードしてくれたコードと,VBアプリが使用したコードは,別のプロセスで動いていた,という訳です。理由が分かったところで,ちょっと考えてしまいました。Server"にしておく必要があります。この形式のサーバは,これは当然ともいえますが,独立したアプリ(exeファイル)になります。DLLにはできません。するか?いろいろ試行錯誤しましたが,最終的には解決策が見つかりました。それは“Becky!自体をActiveXサーバとして登録する”という,ごく当然の結論です。その方法を見つけるまでには,それなりに苦労したのですが。Wizardで生成したActiveXサーバは,自身をサーバとして登録するのに”レジストラ”という機構を使用します。このとき登録する内容は,実行ファイルやDLLのリソースとして登録されています。VC++のプロジェクト上は,***.rgsという名前のソースとして参照することができます。Wizardを使ってプロジェクトを生成して,OutProcess(exe)とInProcess(dll)の定義内容を比較してみると,それほど大きな違いがないことが分かりました。そこで前者を参考にして,DLL形式で生成したプロジェクトのrgs定義を書き換えてやることにしました。Server)としてやるその際の実行ファイルパスには,B2.EXE(Becky!)のパスを指定するの2点です。作成したrgsファイルは次の2つになりました。}}これをビルド,実行してみると...今度は期待通り,Becky!の情報を取得することができました。繋がってしまえば,他のAPIを実装するのは難しくありません。IDLにメソッドを定義し,実装するだけです。HANDLEなど)もあります。このあたりは結構アバウトに判断し,実装範囲を決めていきました。最終的に実装したのは,次のようなメソッドです。APIの中で,PlugInから呼び出しを行うものについてです。これ以外にAPIには,Becky!でのイベント発生を通知するコールバックも定義されています。これらのイベントを,ActiveXのイベントとして実装することにしました。この実装は,いわゆるdispinterfaceを使用して行います。インターフェースとして定義されているDLLコールを経由して行われます。ここで受けたパラメータをもとに,IDLをコンパイルしてできたスタブをコールしてやればいいのです。難しい部分はありません。IDLの定義は,次のような感じで記述しました。ここでも,いくつかのAPIは端折ってあります(悪しからず)。周期的なコールバックのような,ActiveX経由ではあまり意義のなさそうなものも実装していません。number);};Dispatchインターフェース経由でActiveXサーバから通知されるイベントは,クライアント側のイベント処理で受信します。VBを使う場合,インスタンス変数定義時にWithEventを指定してやります。BeckyAxSvr後はVBがタイプライブラリを参照して,適当なメソッドのスケルトンを与えてくれます。必要なのは,その中身を記述することだけです。Subスレッドが...これで一通り想定の機能がそろいました。ところが,いろいろテストプログラムで試していると,うまくいっていない部分があることが分かりました。メール受信時のコールバック"OnRetrieve"だけがコールされていないようなのです。)コールがエラーになっているようです。そこでエラーコードを確認したところ,“スタブが別スレッドからコールされている”ことが通知されていると分かりました。OnRetrieveだけは,他とは別スレッドでコールされているようです。これ自体,処理内容を想像すれば納得できるものではありますが。Model"という点にあるようです。この形式の場合,Marshallerは単一スレッドからの起動しか許されておらず(しっかりチェックされているようです),別スレッドであるコールバック内での起動はできません。Model"を使用する以外には見つかりません。このCOMモデルの指定には,WindowsAPIのCoInitializeExを使用します。value);最初のパラメータはReservedで,必ずNULLを指定します。2つ目がCOM初期化値を与える部分です。今回の条件であれば,ここでCOINIT_MULTITHREADEDを指定してやればよいようです。このAPIは,Windowsプログラム処理の最初に,1回だけコールします。)などのメイン関数で使用するのですが...。こちらの処理を変更するわけにはいきません。順調(でもないか)に開発を進めて来ましたが,ここで詰まってしまいました。OnRetrieveだけ諦める,という手も考えたのですが,ここまで理由を調べた以上,何とか対処したいのものです。それで,プログラム的に回避策を打つことにしました。理屈は単純で,「Dispatch処理を行うスレッドを作っておく」というものです。コールバックされたメソッドでは直接処理は行わず,このワーカスレッドにメッセージを投げます。このスレッドではWindows定石のメッセージディスパッチを行って,メッセージを順次処理する,という形で実装しました。DLL_PROCESS_ATTACHで起動,DLL_PROCESS_DETACHで停止,という具合です。この構造でテストしたところ,OnRetrieveを含めたコールバックを,すべてActiveXイベントとして通知することができるようになりました。Designplate。