酒井 法雄のVBコンプリート
Visual Basic 4.0
OLE カスタムコントロールで進むコンポーネント指向
OLE 2.0でサポートされたOLEオートメーションは、アプリケーションをコンポーネント化、カプセル化して再利用することが可能なメカニズムである。OLEの標準的なインターフェイスで使用できるカスタムコントロール(OCX)は、Windows 95やWindows NTでの開発環境やスタイルを、コンポーネント指向に大きく変えようとしている。
Visual Basic 4.0は、OCXをサポートする標準的な開発環境であり、この製品の登場でOCX市場は本格的に動き出している。今回は、OCXとは何か、
そしてVisual Basic 4.0でバンドルされているOCXについて概要を述べる。
酒井 法雄
●Windowsにおけるプロセス間通信の歴史
OLE(Object Linking and Embedding)と言えば、とかくWordの文書にExcelのシートやチャートを貼り付けるといったことを連想しがちである。そこからくるOLEのイメージは、複数のアプリケーションでのデータ共有というものでしかない。本来OLEは、Microsoft Power Pointで文字や図形を自由に貼り付けてデザインできるようにするために開発されたものであるから、この連想はあながち外れてはいない。しかし、OLE 2.0の仕様が発表になった数年前から、すでにOLEはそれだけの存在ではなくなっているのだ。
OLEはプロセス間通信の一つの形式である。こう捉えると、その存在価値もかなり違って見えるはずだ。Windowsでのプロセス間通信(厳密には、Windows
3.1まではプロセスとは言わなかったが)の歴史を振り返ると、その後のプロセス間通信のベースとなるクリップボードからスタートし、メッセージベースDDE(Dynamic Data Exchange)、APIベースのDDE、そしてOLEという流れがある。一方、ファイルマネージャからプログラムマネージャに選択したファイル情報を送るドラッグ&ドロップという便利なインターフェイスがある。このインターフェイス自体はプロセス間通信とは言うには語弊があるものの、結果的に似たようなものになっている。これらを統合した形で出てきたのが、OLE 2.0(図)である。もっとも、今となってはすでにOLEといえば2.0のことを指すのが当然になっている。
この短い歴史の中で注目したいのがDDEである。DDEは手動、自動、通知という3つのリンク形態を持ち、ソース(サーバー)側のデータをディスティネーション(クライアント)側にコピーして共有しようというものである。また、一時的にディスティネーション側データをソース側に転送することも可能である。さらに、ディスティネーション側からソース側にコマンド文字列を送信することもできた。これをうまく使えば、二つのアプリケーション間でデータのやり取りを比較的自由にプログラミングすることができたのである。
しかし、当初のDDEはメッセージベースだったため、プロトコルに合わせて矛盾なくコーディングするのが難しかった。その後DDEML.DLLが提供されてAPIベースとなったものの、Windows 3.1自体がノンプリエンプティブなマルチタスクだったため、非同期で動作するDDEは、ドラッグやディスクアクセス、重い処理などが間に入ったときにリンクを保持し続けることができずに、うまく動作しないといった問題点が指摘された。
OLEは、DDEの手続きを簡略化し、もっと手軽にアプリケーションから使えるようにすることを目標とした。このため、あくまでも複合ドキュメントを主眼とし、データのファイルをサーバー側が管理するリンクと、クライアント側が管理するエンベッドの二つの方法が提供された。しかし、扱えるデータ型は相変わらずクリップボード形式のものであり、グローバルメモリのアドレスを使ってデータのやり取りをしており、64Kbytesの壁を越えられないというDDEそのままの制限があった。それもそのはず、実はOLEのデータのやり取りをする中心となるOLECLI.DLLとOLESVR.DLLの間はあくまでも非同期のDDEが使われていたのである。また、DDEのメリットだったコマンド文字列の送信などはほとんど使われない仕様となった。
●OLE 2.0の特徴と構造
OLE 2.0では、このような中途半端なOLE 1.0の仕様を抜本的に解決すべく、大幅な見直しが行われた。その主眼となる目標も複合ドキュメントの強化だけにとどまらず、ユーザーインターフェイスと操作性の改良、さらにはWindowsアプリケーション間での共通マクロとも言えるOLEオートメーションが掲げられた。結果的には、次のような改良が行われた。
Visual Editing (In-Place Activation)
オブジェクトのネスト
ドラッグ & ドロップ
ファイルシステムから独立したファイル
リンクの整合性
OLE オートメーション
バージョン管理
オブジェクトタイプのコンバージョン
ここでは、残念ながらこれらの一つ一つについて詳しく述べるページはないが、OLE 2.0はこれらの機能を実現するために、従来とはまったく違う構造を取っていることに着目してほしい。
図 OLE 2.0のアーキテクチャー(Inside OLE 2)
OLE 2.0の中心となるのが、コンポーネントオブジェクトモデル(COM)である。ここでは、オブジェクトのインスタンスを作成し、オブジェクトのメンバー関数APIのアドレスを供給する。また、プロセス境界での文字コード(UniCode, ANSI)や16bit, 32bitの整合性を取るマーシャリングと呼ばれる処理も行っている。この処理のベースとなるのが、LRPC(Lightweight Remote Procedure Calls)と呼ばれるプロセス間通信である。従来の非同期なDDE方式に比較すると、同期して実行されるのでインプリメントがしやすいというメリットがある。また、いわゆるRPCと同様にプロシージャを呼び出すという考え方であるから、二つのパラメータしか持てないSendMessage関数を使うのと比較して、引数に自由度がある。
実際には、LRPCはインターフェイスと呼ばれる関数群をコールして実行される。サーバーオブジェクトには、あらかじめ自オブジェクト内のデータを操作するためのメソッド(メンバー関数)を用意しておく。COMではこれらのメソッドの一覧をvtableと呼ばれるテーブルに作成して、そのアドレスを管理する。クライアント側ではCOMを通してアクセス可能なメソッド一覧およびそのアドレスを知ることができる。そして、必要に応じてそのメソッドをプロシージャコールするわけだ。
●OLE オートメーションとOCX
このようなOLEのメカニズムのメリットを最大に活かしたのが、OLEオートメーションである。OLEオートメーションは、インターフェイス関数群をそのままサーバー側オブジェクトから公開された関数(いわゆるDLLでのエクスポートされた関数とは違う)と見なして呼び出すことができるようにしたものである。したがって、サーバーオブジェクトのプロパティやメソッドという形式を実現することができる。こうして、コンテナ(クライアント)アプリケーションからサーバーアプリケーションを操作することができるわけである。
さらに、インプレイスアクティべーションでサーバーでの編集画面をコンテナ内部に表示し、サーバー側で発生したイベントをコンテナ側に通知するイベントのメカニズムを装備したのがOLEベースのカスタムコントロール、いわゆるOCXである。このイベント通知のメカニズムは、実はOLEのコンテナとサーバーが逆転したような形で実現される。つまり、通常ならばサーバーが公開しているメソッドをコンテナが呼び出すのだが、イベントではコンテナが公開しているメソッドをサーバーが呼び出し、これがイベントとしてコンテナ側に認識される。
従来カスタムコントロールと言えば16bitのVBXを指すことが多かったが、この仕様は86系CPUの16bitでの使い方であるセグメントとオフセットという考え方に依存しており、32bitに対応することができないため、事実上なくなる運命にある。今後はカスタムコントロールと言えば、このOCXを指すことになるはずだ。
従来のVBXの動作とOCXの動作を比べてみよう。VBXでは、図のようにWindowsシステムからVisual Basicに送られてきたWM_XXXメッセージをそのまま、あるいはVB内部形式のVBM_XXXメッセージをVBXに送る。VBXでは必要な処理をしてVisual Basicのデフォルトコントロールプロシージャを経由してWindowsのデフォルトプロシージャに戻るという流れを取る。このように、VBXはあくまでもメッセージを使って処理が行われるオーソドックスなものだ。しかし、前述したようにSendMessageで送られるデータだけでは処理できるものに限界があるし、グローバルアドレスを参照して使うといった形になってしまう。
一方、OCXは構造的にもOLE 2.0のインターフェイスを使うものであり、LRPCを使ったプロシージャコールでアクセスするものだ。したがって、ここでも従来のメッセージベースでの制限を克服できるようになっている。また、プロシージャをコールするという形式が標準であることから、メソッドをカスタマイズすることができる。これも、従来のVBXではできなかったことだ。
OCXでもう一つ注意しておきたいのは、通常のOLEサーバーより高速に動作するという点だ。OLEサーバーには二つの種類がある。一つはアウトプロセスOLEサーバーであり、もう一つはインオブプロセスOLEサーバーである。
アウトオブプロセスOLEサーバーは通常EXE形式の実行ファイルであり、動作は通常のOLE 2.0のインターフェイスである。つまり、コンテナ側から見たら外にある別プロセスで動作しているサーバーである。
一方、インプロセスOLEサーバーは、コンテナが動作してるプロセスの内部にロードされて実行されるもので、通常はDLL形式のものである。インプロセスOLEサーバーのときにも、もちろんOLEのインターフェイスが使われるが、内部的に見るとスタック呼び出しの形でプロシージャをコールしている。したがって、実際にはプロセス間通信はしていないから、マーシャリングによるオーバーヘッドは軽減される。このため、アウトオブプロセスOLEサーバーに比較して、数百倍は高速に呼び出すことが可能である。OLEベースのミドルウェアとして注目されているOracle Objects OLEでも、このインプロセスOLEサーバーが採用されている。
OCXは、独立したアプリケーションではないから、実際にはDLL形式のOLEサーバー、すなわちインプロセスOLEサーバーになる。このため、高速にプロシージャコールをすることが可能なのである。
●OCXのためのツール
このように、OCXにはVBXにはない優れた点があることは確かだ。しかし、すでに数年前からOCXについては仕様が決定されていたにもかかわらず、なかなかOCXに対応したツールがなかったのも事実である。OLEの企画元であるMicrosoft純正ツールとしては、Access 2.0でOCXが使えるようになっていた。また、Oracle Power ObjectsでもOCXが使えるようになっている。しかし、いずれも動作が微妙に異なる、動作が遅いなど問題点が指摘されていた。
そもそもOLEはプロセス間通信をするものであるから、従来のWindows 3.1のようなノンプリエンプティブな16bit OSではパフォーマンスの点でも期待できない。そこで、MicrosoftとしてもOCXを本格的に世の中に出すのは32bit版のVisual Basicの発売時と考えていた。なぜVisual Basicかと言えば、MicrosoftはOLEオートメーションを使うためのWindowsマクロとも言える言語エンジンVBA(Visual Basic for Applications)を提唱しているからである。VBA自体はExcel 5.0にも搭載されているが、16bit版である。そのVBAのもっとも汎用なものがVisual Basicそのものであることは言うまでもない。したがって、OCXの本格登場、そして標準的なOCXのためのコンテナはVisual Basicにする必要があったのだ。ところが、32bit版Visual Basicは、Windows 95のディレイのあおりをまともに受けてしまい、リリース時期は1995年第4四半期までずれこんでしまった。そのため、OCX自体も世に出るのがずいぶんと遅くなったというわけだ。
しかし、OCXを開発するためのツール自体はOLE 開発キットとして提供されており、ずいぶん以前からOCXを開発することは可能だった。1995年初頭に日本語版がリリースされたVisualC++ 2.0でも、OCXの開発キット一式が含まれており、16bitならびに32bit版のOCXを作成することができた。しかし、それを使うための標準的なコンテナがないというのが現状だったのである。実際に確実に動作するのはこの開発キットに付属しているテストコンテナのみであり、きちんと動作する開発ツールはなかったのである。このため、OCXの細かい仕様も微妙に変化してきたのである。
●Visual Basic 4.0とOCX
こうした流れを止めることになったのは、言うまでもなくVisual Basic 4.0である。Visual Basic 4.0は16bit版とともに、Windows 95とWindows NT 3.51上で動作する32bit版の開発環境を持っている。このため、OCXも16bit用と32bit用が用意されている。
誤解のないようにしてほしいのは、本来はOLEのインターフェイスさえあれば、16bitだろうが32bitだろうが動作するハズである。しかし、インプロセスOLEサーバーでは16bit版コンテナから32bit版のOLEオブジェクトを実行することはできない。逆に32bitコンテナから16ビットオブジェクトを実行することもできない。したがって、16bit用と32bit用のOCXが必要なのである。
Visual Basic 4.0の登場によって、いよいよOCXを使うためのリファレンスコンテナができたわけで、従来は細々とやっていた16bit OCXベンダーも、今後は安心して32bit OCXを作っていくことができるようになったわけだ。
Visual Basic 4.0のProfessional Editon, Enterprise Editonには、標準的に数多くのOCXがバンドルされている。これらの中には従来からあるVBXに互換を持った標準と3D系のOCXがあるほか、Windows 95で増えたコントロールを使うためのものや、データアクセスに特化したものなどが増えている。
OCXはOLEベースのものであるから、単純にファイルをプロジェクトに加えて実行できるものではない。実際にはシステムのレジストリデータベースに入っている情報を元にして実行される。Visual Basicでも、カスタムコントロールをレジストリデータベースから参照してプロジェクトに加えるようになっている。なお、ここでは通常のOLEサーバーもカスタムコントロールと同様に扱うことができる。
実際にバンドルされているOCXのうちでもよく使われるであろうものを一通りプロジェクトに加えると、ツールバーは図のようになる。ここでは、Powe Point, Excel, WordなどもOCXと同様にアイコンになっていることが分かる。
OCXはカスタムコントロールとしての使い勝手も向上している。従来のVBXには高機能なものになると膨大なプロパティがあるものも少なくなかった。このようなカスタムコントロールでは、プロパティにどのようなものがあるかを把握するのも容易ではなかったが、さらにそれらを設定するのも大変だった。ものによっては、構造上プロパティウィンドウですべての情報を指定できないため、どうしてもコーティング部分が多くなる嫌いがあった。しかし、たいていのOCXではプロパティページが用意されており、デザイン時に多くの設定をすることが可能になった。このため、コーディング量も減り、以前よりはたやすく理解できるようになっている。
コモンダイアログでは、ダイアログの種類によってタブを切り替えて細かいプロパティやデザインを指定することができる。
イメージリストは複数のピクチャーをコレクション的に扱うものだが、ここでもプロパティページが活躍する。
Windows 95で追加されたコントロールの数々。いずれもOCXで使うことができるようになっている。
●OCXはWindows NTの未来を担う
このように、OCXはVisual Basicの、そしてOLEの標準的なインターフェイスを使うカスタムコントロールである。したがって、Visual Basicコンパチの言語仕様を持つようなコンテナ、あるいはBasicでなくともOLEオートメーションインターフェイスを持つコンテナであれば、使うことができる。もはや、OLEインターフェイスはDLLコールインターフェイスを越えた新しい標準インターフェイスなのである。
Microsoftでは、このOLEのアーキテクチャーをCairo(次期Windows NT)で大幅にOSに取り入れるという。そうなれば、いわゆるカスタムコントロール的な使い方だけでなく、システムのオブジェクトを扱うためのコンポーネントとしてOCXが活躍することになるだろう。たとえば、Oracle Objects for OLEやVisual Basic 4.0 Enterprise Editonに含まれているRemote Data Object(RDO)といったOLEサーバー、そしてそのOCX版であるRemote Data Control(RDC)は、C/S型データアクセスをするためのものであり、OSの機能の拡張として捉えることができる。このようなシステムに近いオブジェクトをOCX化していけば、目的に応じたOCXを使ってすばやくアプリケーションを開発することができるようになるだろう。
OCXはWindowsの将来に大きな役割を果たすに違いないのである。
●OCX市場動向
Visual Basic 4.0の発売にともない、すでに米国では32bit OCXが多数発表されており、発売されているものも少なくない。OCXやVisual Basic関係のツールをまとめて扱っているVBxtras社では、インターネットのWEBサーバーでOCXを発売している。表にそのリストを紹介する。
1-800-788-4794 1-770-952-6356 Fax:1-770-952-6388
http://www.vbxtras.com/
Currently Available
PC-Install
Visual/db
VBA Companion
PinPoint
VB/Rig Professional
RoboHELP 95
Choreo for Visual Basic
Crusher!
Crystal Reports Pro (Upgrade)
PowerTCP VBXs
ImageMan VBX/OCX Suite
Early Morning Editor
Distinct TCP/IP SDK- Visual Edition
DynaZIP
Drag-it/OCX
LEADTOOLS VBX/OCX
WinWidgets XTable and XGrid
Attila
Info Sleuth
Graphics Server SDK
Sax Basic Engine
Sax Comm Objects
Sax Setup Wizard
VB AppFramework
Calendar Widgets
ClassAssist
Designer Widgets
sp_Assist
Visual Voice
VB HelpWriter
VideoSoft VSFlex/OCX
VideoSoft VSVBX/VS-OCX
SourceWorks/VB
First Impression
VisualSpeller
Formula One
Either Currently Available or Available
Soon
QuickPak Professional
PDQComm
NetPak Professional
SpyWorks
StorageWorks
VersionStamper
MicroHelp Compression Plus
OLETools
VBTools 5
Communications Library
VBAssist
また、国内の企業もOCX開発にいち速くとりかかったところも少なくない。VBXのときから米国で定評のあるカスタムコントロールを日本語化してきた文化オリエントだけでなく、日立製作所やエーエスピー、コムラッド、システムラボといったベンダーは日本での使用を前提とした仕様のOCXを素早く発表、発売している。1996年の前半には、かなりの数のOCXが発売されることになるだろう。
この背景には、OCXの作成はVBXほど難しくないという要因がある。従来のVBXではWindowsの構造やAPI、メッセージだけでなく、Visual Basic自体のプログラミングや構造、VB独自のAPIやメッセージなどを熟知する必要があった上、開発にはC言語が必須であった。MFCなどのクラスライブラリを使ったC++での開発は標準ではサポートされていなかったのである。また。開発キットもSDKの他にVisual Basic Professional Edition付属のCDKが必要だった。
しかし、OCXはWindowsの新しい標準的なインターフェイスであるため、標準的なVisualC++にすべてのツールキットが含まれており、MFCクラスライブラリがサポートされている。C++で開発ができるOCXは、開発自体も以前に比較すると楽になってきているのだ。
このように考えてくると、今後のWindowsでのアプリケーション開発には、明らかに複数の階層ができてくることになる。すなわち、OCXやOLEサーバーを作成する層と、それを使ってアプリケーション開発する層である。こうなってくると、どのようなOCXが市場にあり、今後どのようなものが望まれているかといったことが、開発開始時の重要なトピックとなることは間違いないだろう。