1

COMインターフェイスを既存のアプリケーションに追加するつもりです(ちなみに、これはWin32を使用してC ++で記述されています)。COMオブジェクトの使用経験があるので、インターフェイスなどの基本的なCOMの概念は知っていますが、実際にコンポーネントを実装するのはこれが初めてです。

最終的には、COMインターフェイスを使用して、VBなどのスクリプトからアプリケーションを自動化できるようにしたいと考えています。私は2つのステップがあることを理解しています:

  1. アプリケーションはアウトプロセスサーバーとして機能する必要があります(つまり、MIDLを使用して、プロキシDLLとスタブDLLのコードを生成する必要があります)。
  2. サーバーを入手したら、IDispatchインターフェイスを実装することで自動化機能を追加できます。

MIDLを使用するServer-in-an-EXEの機能とそうでないものはすでに少し急勾配であるため、IDispatchに進む前に、まずそれらすべてを把握したいと思いました。

DaleRogersonの「InsideCOM」という本を読んでいて、EXEのサーバーに関する章を完了しました(次の章では自動化について説明します)。

「EXE内のサーバー」の章では、サーバーとクライアントを実装するサンプルコードを提供します。ただし、サーバーを手動で起動する必要があります。これは私を混乱させます。明らかに、私のアプリケーション(=サーバー)がクライアントプロセスによって使用されている場合、この追加の手動手順は必要ありません。サーバーを自動的に起動するメカニズムはありませんか?それとも、それを達成するために自動化が必要ですか?現時点では、サーバーを手動で起動しなければならない可能性があるため(サーバーが1つでもある場合)、正しい方向に進んでいるのではないかと疑っています。

うまくいけば、これについてもっと知識のある人が、私が見逃している情報を見て、正しい方向に私を向けることができます。

4

2 に答える 2

1

いいえ、COMサーバーは通常手動で起動されません。なぜ本がそれを提案したのかわからない。おそらく、COMがEXEを自動的に開始できるようにするために必要なレジストリキーについて話すのを避けたかったからだろう。それ以外はそれほど複雑ではありません。アプリのアプリケーションコクラスを、EXEへのパスを指定するLocalServer32キー値に登録します。

ただし、特に既存のプログラムでは、これは完全に珍しいことではありません。設計上の決定の1つは、クライアントコードにプログラムを完全に制御させるかどうかです。または、プログラムに既存のユーザーインターフェイスが既にあるが、サービスを他のコードに公開したい場合。後者の場合、通常どおりにユーザーがアプリを手動で起動できるようにするのが理にかなっています。

于 2012-10-18T17:38:08.187 に答える
1

アプリケーションがとして登録されてLocalServer32いる場合、実行中のプロセスがCLSIDのファクトリオブジェクトをまだ登録していない場合は、そこで指定されたコマンドラインで呼び出されます。

このようにして、両方の長所を活かすことができます。アプリケーションがすでに実行されている場合、このインスタンスはサーバー側を提供でき、実行されていない場合は起動されます。

自動化はそれと完全に直交しています。を実装することで、コンポーネントは自動化と互換性がありますIDispatch

于 2012-10-18T17:39:12.913 に答える