「情報がない！」

　本誌先月号の巻頭，高根氏と鵜沢氏のインタビュー記事に掲載されている円グラフはご覧になっただろうか（詳細は本号162ページ参照）．「市販のActiveXコントロールをお使いですか？」の問いに対して，Noと回答している解答者がかなりの割合いを占めている．興味深いのは，Noと答えた解答者のうち「情報がない」と答えた人が，半数以上いることだ．

市販コントロールを使うかどうかは，開発者のスタイルの問題
　市販のActiveXコントロールを使うか使わないかは，開発者のスタイルの問題である．何から何まで自分でプログラムを記述するのが好きな開発者は，市販のActiveXコントロールを使用する必要などはない．納期には大幅に遅れてしまうし，開発コストは膨大になるが，その代わり，すべてのソースコードと，深い充実感を得ることができる．反対に，楽をして納期に間に合わせることが好きな開発者ならば，迷わず市販コントロールを使うはずである．その代償として，コントロールのバグにあてるパッチに頭を悩ませたり，新しい開発ツールをサポートしないコントロールのために，いつまでも古い開発ツールを使うことになるかもしれない．

「情報がない」「サポートが不安」が使わない理由
　しかし「情報がない」から使わないのだとすると，それは情報を提供する側，すなわち私たち，コンピュータジャーナリズムの責任ということになる．2番目に多かった回答の「必要な機能を満たすものがない」と答えた人も，実は必要な機能を満たすものがあるのに，情報がないがために知らなかっただけかもしれない．
　「No」と答えた理由の他の要素をみると，「長期的なサポートに不安」という回答が3番目である．この回答に関連することを，偶然にも古橋氏が，同じく本誌先月号の連載「古橋本音堂」で次のように提言している．
　「注意として書いておくが，2番目の手法でいう［コントロール］は市販のコントロールを使うべきであって，VBに標準添付されているコントロールを使用するのはできる限りさけるべきだろう」
　Visual Basic添付のコントロールがバージョンアップと共になくなってしまたことから得た教訓だという．つまり，市販コントロール以上に， Visual Basic標準のコントロールのサポートは不安だということになる．だとすると「長期的なサポートに不安」と答えた解答者は，Visual Basic標準のコントロールも使わないのだろうか．コントロールを使わないVisual Basicプログラミング．不可能ではないが，考えただけで憂鬱な話である．

誰が責任をとるのか？
　ユーザーの意識における真の問題は，コントロールのサポートにあるのではなく，責任の転嫁の可不可にあるのではないだろうか．つまり，ユーザーからVisual Basicを使うように逆指名があったとする．Visual Basicだけを使って問題が発生した場合，Visual Basic，つまり，Microsoftのせいにできるが，市販コントロールを使うように提案した途端，責任はそのコントロールを選択した側にかかってくることになる．
　 しかし，大切なのは納期に合わせてプログラムが稼動することであって，責任を転嫁できるかどうかということではない．もし，それが，本題よりも大切ならば，できないことを明言しながら，裏でコントロールの調査を進めればいい．

市販コントロールの情報と読者
　コントロールに対する私の立場を明確にしておく必要があるだろう．私はソースコード公開製品を発売している関係上，できる限りサードパーティ製のコントロールは使わないようにしている．なぜなら，サードパーティ製のコントロールを使うと，ソースコードが公開されていたとしても，コンパイルするためにはそのコントロールを購入する必要があるからである．サードパーティが提供するロイヤリティフリーのライセンスは，あくまでも実行ライセンスのフリーであって，デザイン時のライセンスフリーではない．　また，テクニカルライターという私の立場も，サードパーティ製のコントロールを使いにくくしている理由である．サードパーティ製のコントロールを使用した記事を執筆したとして，そのコントロールを所有していない読者には無効な情報になってしまう．しかし，情報がないから購入しないというユーザーが多いならば，サードパーティ製のコントロールに依存した記事も，ある種のバイヤーズガイドとして役に立つだろう．そういう観点から，この原稿を書いているのである．

受託開発では…
　もっとも，受託開発の仕事の場合は，それこそ，使える部分のすべてに市販コントロールを使用する．これは主に開発コストを下げるためである．必要な機能が市販コントロールに搭載されているという理由で使用する場合もあるが，コントロールの機能に合わせて仕様を変更する場合も多い．そのため，新しいコントロールの情報には常に気を配っている．しかし，無条件で市販コントロールの使用を勧めているわけではない．Visual Basic標準のものよりはましかもしれないが，市販のコントロールにも，かなりのバグがあるし，プログラミングの時間と同じだけの時間をバグ回避のために費やすこともある．しかし，コントロールを使わなかった場合にかかったと思われるコストを考えれば，見合うだけの対価はある．

使用の決定は自分の調査に基づいて…
　また，私がいくつかのコントロールベンダーの方たちと，密接な関係をもっていることも告白しておかなければならない．いくつかのコントロールは無償で提供してもらっているし，ベンダーと短期的な契約を交わしたこともある．また，付き合いのないコントロールベンダーとのバランスからも，個々のコントロールを否定するようなことは書かない．もっとも，これは，決して私の立場を否定することにはならない．使える部分を採用し，使えない部分は使わないというのが私のプログラミングスタイルである．つまり，あるマテリアルがあったとして，それを採用するかしないかは，マテリアルの仕様書に基づいて決定するのではなく，自分の調査結果に基づいて決定するのである．

　最近の開発ツールのCD-ROMには「Unsupport」と呼ばれるフォルダが付属していることが多い．このフォルダには，メーカーは動作を保障しないが，便利なツールやサンプルプログラムが収められている．動作が保障できないからといって隠してしまうのではなく，情報を公開することで開発者の便宜を図るのである．開発者はプログラムの作成に関する情報をここで発見できるかもしれないし，あるいは，残念ながら正常に動作しないかもしれない．採用するかどうかは，自分で判断すればいい．
　複雑化したWindowsオペレーションシステムにおいては，システム全体がUnsuppotフォルダのようなものだということができる．特にバージョンアップによって追加された機能は，OS・開発ツール・アプリケーション区別なく，すべてUnsupportだと考えていい．メーカーが「Support」の判をおしても，何もしてくれないのだから同じである．

だから，パソコンは安い
　もちろん，こんな理屈は，通常の商道徳の観点からは通用しない．しかし，それが通用するのが，現在のコンピュータ業界である．しかし，これには正当といえるだけの理由がある．というのは，絶対に動作することを保障しようとした場合，製品全体にかかわるコストは桁違いに高くなってしまうからである．
　 現在のパーソナルコンピュータはソフトウェアを含めて，全体の7割動作するものを100分の1の値段で売っていると考えればいい．でなければ，洗練されたGUIを搭載したPentiumの300MHzのマシンが，30万円以下で買えるわけがない．ならば，残り3割の機能は最初からないものと考えてしまえばいい．7割の機能のコンピュータを1/100の値段で買えるのである．どうしてもすべてが動かなければ気がすまなければ，大手メーカ製のコンピュータを100倍の値段をだして買うことになる．
　 x86アーキテチャをもつパソコンは，所詮，パソコンなのである．また，Windowsは所詮Windowsでしかない．市販のコントロールを使うにしても，徹底した調査が必要である．それが，日立の製品だろうが，IBMの製品だろうが，Windows上で動くならば，Microsoftの製品と同列でしかない．ましてや，雑誌の新製品紹介や本稿などをあてにしてはいけない．Windowsプログラミングに関しては，金融ビックバンに先立って，自己責任の原則が適用されている．この原則を身につけた者だけが，パーソナルコンピュータ業界で生き残ることができる．誰も，ましてや，Microsoftはあなたを助けてはくれない．

　ここで紹介するのは，DesaWare社が開発したSpyWorksである（日本語版の発売は文化オリエント）．なぜ，SpyWorksかといえば，本号がダニエル・アップルマン氏来日記念号だからなのだが，それは別にしても，この製品はVisual Basicの限界を超える方法を提示するという意味で興味深い．
　実はこの製品はアップルマン氏の近著である『詳解，ActiveXプログラミング』（ソフトバンク刊）と密接な関係がある．この本は，最新のテクノロジーを利用するVisual Basicプログラマにとって必読の本だといってもいい．特にCOMコンポーネントのメカニズムについて説明してある上巻は，COMのメカニズムを理解した上でVisual Basicでプログラムをしたい開発者に有益である．

Visual Basicとオートメーション
　Visual Basicのもっとも優れた部分は，多くのことを割り切ったことにあるといえる．Visual Basicは何もできない開発言語だが，随一優れた点として，COMコンポーネントを扱うことができる．この一点によって，何もできない開発言語が，何でもできる開発ツールに転じるのである．もっとも，APIがコールできるということも拡張性のひとつにあげるべきだろう．しかし，APIの機能を提供するCOMコンポーネントがあれば，APIを呼び出す必要もない．というより，Visual BasicでCOMコンポーネントの作成が可能になった今日においては，APIを呼び出す場合は，その部分をCOMコンポーネントによってカプセル化すべきである．もちろん，それはActiveXコントロールでもいい．
　 Visual Basic 3.0までは，Visual BasicからのAPIコールは，サポートされてはいるがある種の裏技だったといえる．APIビューアが添付されている現在のバージョンでは，API呼び出しはVisual Basic標準のプログラミング技法として認められたともいえる．しかし，Visual BasicがCOMコンポーネント操作言語であるという本質は変わらない．ActiveXコントロールのようなCOMコンポーネントでカプセル化することで，APIを使用する場合の問題点である移植性の問題を特定の個所に集めることができる．

COM ＆ ActiveXコントロール
　ActiveXコントロールはCOMコンポーネントの変種といえるのだが，ユーザーから見た場合，クラスを使って作成する通常のCOMコンポーネントとの違いについて簡単に説明する．ActiveXコントロールを利用する際に，ツールボックスで選択してフォーム上でドラッグすることはVisual Basicプログラミングの基本だが，この操作はCOMコンポーネントを使う際のObject変数の宣言とインスタンスの作成に相当する．フォームにコントロールを配置すれば，フォームのLoadイベントで，そのコントロール（COMコンポーネント）のインスタンスを自動的に作成してくれるというわけである．
　このようなプログラミングの記述方法の違いの他に，ActiveXコントロールはVisual Basicのフォーム内にビジュアルな要素を表示できるという利点がある．しかし，これはActiveXコントロールの必要条件ではない．Timerコントロールのように，実行時には表示されないコントロールも多いからである．非ビジュアル系のコントロールは，ユーザーインターフェイスとしては機能しないが，メソッド，プロパティ，イペントといったプログラミングインターフェイスにより，プログラムコードとコミニュケーションをはかることができる．このような，非ビジュアル系のコントロールはActiveXコントロールではなく，一般のCOMコンポーネントとしても実装が可能である．しかし，私は非ビジュアル系のコントロールも，クラスを使ったコンポーネントよりもActiveXコントロールとして実装することを薦める．何ぜなら，ActiveXコントロールはプロパティシートが使えるからである．プロパティシートの使用は，コンポーネント指向プログラミングにおけるドキュメンテーションの問題を軽減してくれる．Visual Basicはソースコード中にオブジェクト名を入力してピリオドを入力した瞬間に，メソッド，プロパティ，イベントを列挙してくれるすばらしい機能があるが，それでもプロパティシートの一覧性にはかなわない．
　バインディングのタイミングが指定できない等の問題があるし，また，プログラミングアーキテクチャの美観を損なうにしても，使用しているコンポーネントの把握のしやすさといった利点も含めて，ActiveXコントロールは魅力のあるアーキテクチャである．

　ActiveXコントロールにビジュアルなコントロールと，非ビジュアルなコントロールがあることは説明した．それとは違った意味で，コントロールを使う理由にも，大きくわけて2つのパターンが考えられる．ひとつはコントロールを使うことで技術的な制限を乗り越えられることであり，もうひとつは開発労力を低減化できることである．最初の例としては，TCP/IPの通信機能をカプセル化したようなコントロールがあげられる．このようなコントロールを使用することで，Visual Basicプログラマは，TCP/IPの知識が乏しくてもアプリケーションを開発することが可能になる．後者の例としてはグリッドコントロールがあげられるだろう．グリッドコントロールの代用をテキストボックスとラベルコントロールで行なうことは，技術的には難しいことではない．簡単な配列操作といくつかのプロパティを覚えればいいだけである．しかし，キストボックスとラベルでグリッドを作成したいと思う人は少ないはずである．それらの便宜を図るのがグリッド系のコントロールだといっていい．

Visual Basicの限界を超えるためのツール
　SpyWorksは前者のコントロール，つまり，Visual Basicの機能や開発者のスキル不足を補うツールである．今まではAPIを使用したり，C++言語等を使用しなければ実現できなかったプログラム開発を，可能にするための機能を提供する．つまり，このツールを使用することで開発者の能力を向上させ，Visual Basicがもつ制限の壁の一部を超えることができる．Visual Basicが標準でこのようなツールをバンドルしていれば，Visual Basicのイメージそのものが変わっていっただろう．APIビューアの添付やAddressOf演算子のサポートよりも，コントロールやCOMコンポーネントによる拡張の方が，よほどVisual Basicのアーキテクチャに準拠しているのだから．

Visual Basicエンタープライズエディションの価格
　Visual Basicエンタープライズエディションを購入するよりも，Visual Basicラーニングエディションと，このSpyWorks，Progress SoftWare社のClassAction，同社のQuickPak，それとVisual Component（Sybase）のdbComplate（ついに日本語版が発売された）を購入する方が，よほど，汎用的で標準的なVisual Basicプログラミングが可能である．もっとも，全部買うとVisual Basicエンタープライズエディションよりも高くなってしまうので，必要なものだけを選べばいいだろう．

Windowsメッセージを扱う
　SpyWorksは，最新のバージョンになって，WindowsNTのシステムサービスや，ISPAPIアプリケーションの作成，それにMDIアプリケーションにタスクバーを付加するといった具体的な機能が追加されたが，サプクラス化やメッセージフックなどのWindowメッセージを操作するための機能を，Visual Basicに提供するのが主な目的である．このあたりの技術的な詳細は，本誌2月号で酒井法雄氏が詳しく説明しているので参考にしていただきたい．
　基本的には，サブクラス化することで，Visual Basicでは本来扱えないようなWindowsメッセージを扱うことが可能になる．コントロールとして提供されているので，APIを用いるよりも洗練された方法で扱うことができるが，Windowsメッセージの知識が必要だという点は，APIを用いる場合と変わらない（図1）．

図1：プロパティページでメッセージを選択（SpyWorks ver5英語版）


アイデア次第でサブクラス化のメリットは無限にある
　サブクラス化を行なうことで何ができるのかということになると，これはかなり抽象的な話になる．日頃，使用しているVisual Basicのイディオムからは，サブクラス化を有効に使うためのアイデアは生まれにくい．ただ，このようなツールを使い始めることから，Windowsのメカニズムについて理解を深めていくのもひとつの方法である．使い慣れたVisual Basicの文法を使ってWindowsメッセージを扱うことができるのだから，Visual Basicプログラマにとっては朗報である．

Copyright (c) 1998 int21 Corporation All Rights Reserved.
For questions or comments, please send mail to: pcdn@int21.co.jp