• ベストアンサー

ActiveX DLL と ActiveXコントロールの違い

VB6で開発をしています。 複数のEXEファイルを使用するシステムです。 各EXEファイルの共通のモジュールをライブラリ化しようと思っています。 これは [ActiveX DLL] 又は、[ActiveXコントロール] のどちらでも実現できると思うんですが、どちらで作成した方が良いのでしょうか? それぞれのメリット、デミリットを教えて下さい。

質問者が選んだベストアンサー

  • ベストアンサー
  • TAGOSAKU7
  • ベストアンサー率65% (276/422)
回答No.5

混乱させますw 私も最近まで知らなかったのですが、任意のタイミングでOCXもインスタンスの生成が可能みたいです。 WinSockを張らずにPGを書き上げ、WinSockコントロールを使用する方法がわたしの利用しているメーリングリストに出ておりました。 その結末は、「あまり公開はされてはいないけど、ほとんどのコントロールはEXEにしてからOCXとして取り込むことができる」ということです。 ActiveXDLLも参照設定をしなければ、DLLバージョンが違っても大丈夫です。 ただし宣言が As HogeHoge←(DLLの定義)を As Object として、CreateObject("DLL定義")のように行うと、引数が一緒ならEXEはリコンパイルしないでもいいです。実例として、エクセルを参照設定して[as Excel]と宣言していたら、その参照設定に対応したExcelしか操作できませんが、[As Object]と[CreateObject("Excel.Application")]とすると、EXCEL95~XPまで扱えます。 不便なのは、タイプライブラリが未設定になるので、Excelの各プロパティ/メソッドを知らないといけないし、Excel固有の定数が宣言もされてないので、自分で定数値を調べなければいけません。でもバージョンの違いを気にしないでいけるのは、非常に便利です。 速さのことを言ったら、当然DLLが早いです。 OCXはプロパティにRight/Leftなどを持っています。変えて言うと実体を持っていると言うことです。非表示にしていても実体をもっています。DLLはインスタンスは生成されますが、OCXだって生成されるので、表示しないで使用するなら、OCXの意味があまりありません。 んで、私(個人)の考えとしては、、、 ※オリジナルボタンなどの、画面上必要ならOCX   理由:画面に必要だから ※画面に表示を行う必要がなくても、配布する気ならOCX   理由:配布先のユーザが扱いやすい ※そうじゃなければDLL   理由:OCXにする理由が見つからないから 余談です。 私はいつもCommonコントロールは使用しません。   理由:簡単なAPIでも実現できるのに、機能が少ないCommonコントロールを追加して、EXEの容量を大きくしたくないから

reshop
質問者

お礼

ありがとうございました。 DLLにしようと思います。 あと、 >※画面に表示を行う必要がなくても、配布する気ならOCX > 理由:配布先のユーザが扱いやすい 配布先ユーザというのは、開発者のことですか?また、開発したシステム(ソフト)を使用するエンドユーザのことです?

その他の回答 (6)

  • TAGOSAKU7
  • ベストアンサー率65% (276/422)
回答No.7

なんか文章を書いた後勘違いされそうな文章に思えたので、補足です。 参考URLのOCXの場合を例に挙げたのは、電源のON/OFFだけならDLLで十分だということです。ただこのOCXは他の機能により画面も要します。それらの機能のために画面が必要なので、必然的にOCXということになりますが、、、 しかし、画面がなくても配布という意味で、先ほど言った理由でOCXが望ましいということになります。

  • TAGOSAKU7
  • ベストアンサー率65% (276/422)
回答No.6

このようなOCX http://www.vector.co.jp/soft/win95/prog/se185666.html このような機能は、本来はOCXでなくDLLで済むものです。 電源を管理する関数群の設定を、パラメータでなく、プロパティとして設定させることで、開発者だけでなく、そのOCXを使用する人が設定しやすくなります。 よほど汎用性が高い関数なら、OCX化して小銭稼ぎができます。

参考URL:
http://www.vector.co.jp/soft/win95/prog/se185666.html
  • Hk2001
  • ベストアンサー率48% (24/49)
回答No.4

ActiveXコントロールってOCX作るやつですよね? これは、画面に貼り付けないと使えません。 ActiveXDLLの方は、参照設定などを使用して宣言します。 基本的にActiveXコントロールはインターフェースがあるもの向け、 ActiveXDLLの方は通常のクラスの使い方向けです。 ActiveXDLLでもフォームなどの画面は組み込めます。 両者とも外部ファイルになるので 使用するとEXEが小さくなります。 両者ともデメリットは、世代管理(継承)管理が必要になります。 失敗すると全EXEの再コンパイルが必要です。 また インターフェース部分(パブリックの引数、関数名)など変更すると 再コンパイルが必要です。関数の追加はOKです。 作ってしまうと内部的に見えないので、 しっかり作らないとエラーを追えません。 また、セットアップを作成する場合も、両者とも内部で使ってある コントロールやオブジェクトを組み込まないと、EXEは動きません。 両者のメリットは、作成後の開発効率や、ソースの隠蔽性などですかね。 両者とも結構デメリットありますので覚悟して開発してください。

reshop
質問者

お礼

ありがとうございました。

  • k_kazari
  • ベストアンサー率68% (15/22)
回答No.3

どうもです。 戻ってみてみたら続きがありました(汗) えーーーっと DLLの処理速度が速いというのは あくまで、ActiveX.exeとの比較で言っていたので ActiveXコントロールと比較しての答えではありませんのでしたのでした。 すんません。 書籍などを見ている限り ActiveX.dllとActiveX.exeを比較して メリット・デメリットなどを述べているもので おまけで書いてみました。 でも、GUIもってるのと持ってないのと、DLLって考えたら 感覚的にで、なんも根拠ないんだけど DLLの方がなんか早そう(おいおいっ) COM化(ActiveX.dll)というのは 今制作しているプログラム(仕事上のプロジェクト)があるとして また、まったく別のプログラム(プロジェクト)でも再利用したいというときに 共通ライブラリとして 使うのだと思います。 ということで、今の仕事のプロジェクト終了後、 またいずれ先に、違うプロジェクトなどで 同じ処理を利用したりするなど そんなときにCOM化しておけばよいと思います。 とか、Webで処理速度・レスポンスを速くしたいとか。。。 が、時事的にも、 後々、開発ツールのバージョンアップやシステム環境の変化など 考慮すると、COM化しておいた方がよいような気がします。 あまり汎化されていないモジュールだったり その仕事でしか使わないような共通の処理だったら クラスモジュールの方が、よい気もしますが。 あんまし参考になってない気がしますが ・・・そんな感じです。 でわであ

reshop
質問者

お礼

ありがとうございました。

  • k_kazari
  • ベストアンサー率68% (15/22)
回答No.2

一意見ですが、上記の目的から行くと >各EXEファイルの共通のモジュールをライブラリ化しようと思っています。 ActiveX.dll もしくは ActiveX.exe が 向いているように思えます。 ActiveXコントロールは インターフェース(GUI)をもったコンポーネントです。 たとえば、ボタンや画像など、フォームごと、一緒にCOM化しちゃうものです。 ActiveX.dllは コードコンポーネントとして利用しています。 処理を分割して、ライブラリのようにして利用するのに 向いていると思います。 これはインターフェースをもちません。 たとえば、外部のEXEから 独立したActiveX.dllの関数をコールして、処理をさせたり 戻り値を受け取ったりすることができます。 メリットは、DLLなので処理速度が速い。 デメリットは、インプロセスなので、 DLLでこけると、かなりのこけかたをする (超アバウト・・・) ちなみに、 ActiveX.exe も コードコンポーネントとして利用できるのですが これは、アウトプロセスで、 DLLに比べると処理は若干遅いけど 安全性が高いとのことです。 ・・・でした なんか、参考になれば幸いです

reshop
質問者

お礼

お返事ありがとうございます。 <No.1>nanashinogonbeiさんへのお礼文を入力している間にお返事をいただいたみたいで、同じ質問をさせていただきます。 例えば、ActiveX コントロール作成時に、プロジェクト内に簡単な計算をするクラスモジュールを追加します。(UIは用意しません。タイマーコントロールみたいな感じで実行時には非表示になります。) アプリケーション側では、このクラスを使用するだけ。 この様な場合ですと、ActiveX DLLで作成したクラスを使用するのとどう違うのでしょうか? また、 >メリットは、DLLなので処理速度が速い。 というのは、上記例の場合、ActiveXコントロールよりも処理が早いという事なのでしょうか?

noname#4564
noname#4564
回答No.1

[共通点] ・どちらも単独のプロセスとして起動することはできない。 ・どちらもCOMクライアントと同一のアドレス空間?(= インプロセス)で動作するので、ActiveX EXEより高速に動作する。 (DCOMを使えばアウトプロセスで動作させることも可能??) [相違点] ・ActiveX DLLは任意のタイミングでインスタンスの生成/破棄が可能。 ・ActiveX コントロールを使用するにはコンテナが必要。 コンテナがロードされている間は破棄出来ない。 (コンテナと寿命をともにするので、任意のタイミングで生成、破棄できない) ロジックのみでUIを必要としないプログラムはActiveX DLLで、UIを必要とするプログラムはActiveX コントロール(OCX)として実装するのが一般的だと思います。 ちょっとあやふやですが、大体こんな感じでしょうか?(^^;

reshop
質問者

お礼

お返事ありがとうございます。 まだちょっと、わからないのですが。 例えば、ActiveX コントロール作成時に、プロジェクト内に簡単な計算をするクラスモジュールを追加します。(UIは用意しません。タイマーコントロールみたいな感じで実行時には非表示になります。) アプリケーション側では、このクラスを使用するだけ。 この様な場合ですと、ActiveX DLLで作成したクラスを使用するのとどう違うのでしょうか?

関連するQ&A