もう一歩先に進むための
Visual Basic再入門
もう一歩先に進むための
Visual Basic再入門
Visual Basicは、エントリーしやすいWindowsアプリケーション開発ツールとして人気を集めてきた。一昨年発売になったバージョン4.0からは、本格的なC/S用クライアント開発ツールとして、あるいはOLE対応アプリケーションツールとしての側面が増えたほか、OCXコンポーネントが使えるリファレンスツールとして、Windowsでもっとも標準的なツールとなってきた。
どんどんと機能が増えていくVisual Basicだが、そのカバーする範囲の広さゆえ、すべてを把握することは次第に困難になってきている。Visual Basicを実際に使っていても、なんだかはっきりしない疑問を感じながら使っている方も多いのではないだろうか。
さらにインターネット/イントラネット用アプリケーション開発ツールとしての側面を持つVisual Basic 5.0が発表になった。また新しいコトが増えてしまう。
しかし、Visual Basic 5.0に触れるにはまだ少々の時間がある。この間に、今一度Visual Basicとは何であるかを、あらためて知ろうではないか。そして、もう一歩先に進んでVisual Basicをもっと使いこなせるようになろう。
今回の特集では、Visual Basicの歴史から将来を展望しつつ、我々がVisual Basicを活用するために本当に知っておくべきことを復習してみたい。
酒井 法雄
Visual Basicを知る上で重要なことは、MicrosoftにおけるVisual Basicの位置づけである。
Visual BasicはBasicという名前からか、ついビギナー向けのオモチャだと受け取られがちである。ある意味では、Visual Basicはたしかにオモチャと言えなくもない。しかし、今やC/S用ツール、イントラネット用ツールとしての側面が出てきたこともあり、Visual Basicをよく知る人ほどオモチャだとは思わないだろう。そして、Microsoftが今までやってきたことを考察してみれば、Visual Basicはオモチャどころか逆に一番重要な製品であることが分かるハズだ。
そもそも、MicrosoftはBasicでスタートした会社である。今のCEO、アメリカ一のお金持ちになったBill GatesとPaul Allenは、メインメモリが256bytesしかなかったAltairというマシンにBasicを載せたところから、Microsoftの歴史は始まっている。その後、Basicはパソコンの標準的な言語として次々といろいろなマシンに搭載されることとなった。IBM PCの登場とともに、Microsoftの名声はBasicよりもMS-DOSで大きくなっていった。
しかし、MicrosoftはBasicを辞めたわけではなかった。MS-DOSには、GW-BASICそして、QBASICが標準でバンドルされており、コンパイラが欲しいユーザーはQuickBASIC、さらにプロが使うためにISAMなどを装備したMicrosoft BASICが用意されていたのである。我が国では、NECのPC-9801シリーズがメジャーだったため、Basicはバンドルされていなかったのだが、MS-DOS 6.2Vなどには、しっかりとQBASICがバンドルされていた。
その後、OSはWindows、Windows NTとなっていくわけだが、そこにもVisual BasicがGUI向きの開発ツールとして、存在し続けているわけだ。
では、なぜMicrosoftはここまでBasicにこだわるのだろうか。端的に言うならば、Bill GatesがBasicを大好きだということだろう。Microsoft社内では、開発に行き詰まったとき、こんなジョークが囁かれるそうだ。「大丈夫、こんなときにはBillに頼めばいいさ。彼なら一晩で作ってしまうよ。Basicで。」それほど、Bill GatesはBASICが大好きなのである。
MicrosoftはBill Gatesがいなくては成り立たない会社だ。そして、Bill GatesはBasicに非常に思い入れがある。ということは、Microsoftがある限り、Basicは主流なのである。
もちろん、それだけではない。Microsoftの目標は、一家に一台パソコンがあり、そこではMicrosoftのOSやアプリケーションが動いていることだという。そのためには、こ難しい言語ではいけないのである。そして、Basicは単なる開発言語から、Windows共通のマクロ的な言語なってきている。これがまさしくVisual Basic for Applications Edition(VBA)である。インターネットのブラウザ上で走る言語としても、Visual Basic for Scrioting Edition(VBScript)が登場しているし、Active Server PagesでもVBSベースの言語が使われている。こうなってくると、MicrosoftはWindowsを作っているベンダーというよりは、Basicを作っているベンダーと言った方がいいのかもしれない。
このように、Microsoftを語る上で、Basicは切り放せない存在だ。現在のパソコン市場がMicrosoft主導である限り、Basicは主流なのである。そして、そのリファレンス的な存在こそVisual Basicである。Visual Basicは、単なる一開発言語ではないのだ。
Windows用ソフトウェア開発ツール、RAD(Rapid Application Development)ツール、C/S用クライアントツール、OLE Server開発用ツール、ActiveXコントロール開発ツールと、Visual Basicはいろいろな言い方がされる。
たしかに、Visual Basicはこれらの用途に使われるツールであり、しかもVisualな開発環境ゆえ、比較的カンタンにエントリーできる。しかし、それは複雑なWindowsの仕組みをカプセル化してあるからである。Visual Basicを本当に使いこなすためには、このカンタンさにだけ甘えていてはいけない。もう一歩先をいかなければならないのである。
今回の特集は、この「もう一歩先に進む」ための、Visual Basic再入門である。ここで、再入門と言っても、あらためて分かりきったことを書くつもりはない。すでにVisual Basicをかなり使ってきた方にこそ知っていただきたい次の3つのポイントを述べたい。
詳細は、後の記事を読んでいただくとして、ここでは概要を述べておこう。
いま、Visual Basic、いやWindowsを語る上でもっとも重要なことは、COM(Component Object Model)である。COMという言葉は、耳慣れない方も多いかもしれないが、OLE 2.0(Object Linking and Embedding)の中核となるアーキテクチャーのことである。一般には、COM = OLEと考えても差し支えないだろう。
OLE 2.0は、そもそもアプリケーション間での通信を目的としたものである。同様なものには、クリップボード、DDE(Dynamic Data Exchange)、そしてOLE 1.0があった。通信の目的には大きく分けると二つの方向性がある。ひとつは、ドキュメント指向であり、もう一つはコンポーネント指向である。
ドキュメント指向は、WordにExcelの表やグラフを貼り付けるといった、よく言われるOLEの例にあるようなものだ。複数の別々のデータを扱うアプリケーションで適材適所なデータを作り、それらを有機的に結合してひとつのドキュメントを作ろうというものだ。これは、以前からのMicrosoft Officeなどで体感することができる。
コンポーネント指向は、ドキュメント指向に似ている。部品を作っていき、それらを組み合わせてひとつのアプリケーションを構築しようというものだ。ドキュメント指向がエンドユーザー寄りであるのに比較し、こちらは開発者寄りの技術である。最終的な目標は、開発者にとってはアプリケーションであり、ユーザーにとってはそれで得られるドキュメントと言うこともできる。そして、ここで作った部品を再利用して生産性を上げていこうというのが、コンポーネント指向の重要なテーマだ。
Visual Basicでは、その環境自体がOLEをベースにしている。DAOやRDOなどは、Visual Basic内部の言語仕様のようにも思えるが、実際にはOLEサーバーとして実現されている。Add-Inもそうだ。そして、OCXもOLEサーバーの特殊な形なのである。
Visual Basic 4.0では、OLEサーバーを作れる機能があり、さらにEnterprise Editionには、サーバーを他のマシンに配置してネットワークで通信するリモートオートメーションという機能もあった。
Visual Basic 5.0ではOCX、すなわちActiveXコントロールを作れる他、イントラネットに最適と言われるActiveX Documentsも作れるようになっている。
Windows NT 4.0では、Visual Basic 4.0のリモートオートメーションと同様な機能を、COMを拡張し、OSレベルで提供するDCOM(Distributed COM)が装備されている。DCOMは、インターネットやイントラネットでのRDBMSとのトランザクション処理や、分散コンピューティング環境への拡張がOSレベルでサポートされた点で、非常に注目度の高いアーキテクチャーである。Visual Basic 5.0やWWW Serverと組み合わせた3階層システムなどのベースとなるものだ。
このように、COMは何気なく使っているVisual Basicにも使われており、さらに目まぐるしく登場するMicrosoftの新しい技術群の中心的な役割を果たすものである。COMの概要を知り、Visual Basicからの活用法を知ることは、非常に重要なことなのである。
Visual Basicでは、ご存じのようにカスタムコントロールを使って機能を拡張することができる。これは、上記のCOMベースのOCXと呼ばれるものであるが、最近ではインターネット対応がなされたActiveXコントロールと呼ばれるようになっている。
インターネットでのActiveXコントロールも重要であるが、従来のような使い方も、当然そのまま残るわけである。用途に応じてコントロールを組み合わせ、目的のアプリケーションを作ることができる柔軟性は、Visual Basicの大きな美点である。
しかし、実際にはこの活用がまだまだなされていないのが現状である。というのも、カスタムコントロールを使うということは、それだけプロパティやメソッド、イベントを使いこなさなくてはならないわけで、言語仕様が巨大になっていくように感じてしまうからだ。Professional EditonやEnterprise Editionに付属している数多くのOCXを使ってみるだけでも、かなりの時間と労力を必要とするだろう。
ところが、実際に使ってみるとこれらのカスタムコントロールは必ずしも「使えるモノ」ではない。実は、これらの大半はオマケなのである。ためしにプロパティウィンドウからAboutを選んでみてほしい。かなりのものは、Microsoft以外の著作権表示がされているのが分かるだろう。これらは、いずれも製品として発売されているカスタムコントロールのサブセットであり、肝心のオイシイ機能は外されているのである。「だいたいこんなものだから、もっとちゃんと使いたい人は買ってね」といったようなものなのだ。
しかし、別途お金を出さないと買えないとなると、なかなか買ってくれないのが会社という組織だ。だが、考えてみて欲しい。ひとつの複雑な処理をプログラマーがインプリメントする時間とコストと、デバッグされている(バグはあるだろうが)市販のコントロールを数万円で買ってくるのと、トータルでどちらが安く済むのかを。
カスタムコントロールは、よいものを探して買ってくるものなのである。
とはいえ、Visual Basic 5.0からはカスタムコントロールを作ることができるようになった。パフォーマンスや機能によっては、これを活用した方がよいケースもある。たとえば、市販のカスタムコントロールのようにある程度汎用に作られているものでなく、比較的カンタンな処理ながらよく使う特殊な部品ならば、カスタムコントロールにして再利用しない手はないだろう。
カスタムコントロールの有効利用こそ、Visual Basicでの開発を効率化する大きなポイントなのである。
Visual Basicは、Windows内部の複雑な処理をカプセル化して、カンタンにプログラミングできるようにしたものである。しかし、Windowsの内部は、メッセージとWindows API(Application Programming Interface)で動いている。ここを理解してこそ、Visual Basicをフル活用できるのだ。
メッセージとは、システムからウィンドウに送られてくる命令や報告である。一方、Windows APIは比較的低レベルの関数である。従来のDOSレベルで言えば、BIOSやDOSのファンクションリクエストに相当する。Windowsはハードウェアとのやりとりはドライバを介することになっており、特定のハードウェアに依存しないように設計されている。したがって、すべての処理はWindows APIをベースにしている。
Visual Basicでもたいていの処理はその言語仕様内でできるようになっている。しかし、ちょっと気の利いたことをしようと思ったら、Visual Basicだけでは対処できなくなってしまう。これは、以前のBasicと同様に、面倒な処理はよく使われるであろうやり方がカンタンにできるようにしてあり、危ない処理はできないようにしてあるからだ。よく使われないものだったり、ちょっと危ない処理はできないようになっているのである。
このような問題を解決するには、カスタムコントロールを使うという手もあるが、コンポーネントが増えすぎるのもよくない。
こんなときに役立つのがDLLコールの機能だ。Visual Basicでは、外部にあるDLL内に含まれている関数を、一定の手続きを書けば、呼び出すことができるようになっている。Windows APIもDLL内の関数のひとつであるから、呼び出すことができる。
したがって、Windows APIやメッセージについての知識があれば、従来Visual Basicだけではできなかったことが、いともカンタンにできるようになるのである。Windows APIはWindowsでの最低レベルのものであるから、基本的には何でもできるようになるワケだ。
また、VisualC++などを使ってよく使うようなルーチンをDLLとして作り、Visual Basicから呼び出すという手もある。これもライブラリ化になるから、有効な拡張手段だ。
しかし、ここにもいくつかワナがある。
ひとつは、APIは単体でちょっと使えばいいというものではなく、Windows自体のシステムやメモリ管理など、さらにはC言語について、十分な知識や資料が必要である。すなわち、VisualC++くらいは持っていないといけないということだ。
二つ目は、慣れてくると何でもAPIで解決してしまおうとすることだ。気づいたら、Visual Basicにある機能すらAPIに頼るようになっていたり、果てはAPIだけのコーディングになってしまい、VisualC++だけで作った方が速かったということにもなりかねない。
三つ目は、必ずしもすべてがWindows APIで解決するわけではないということだ。APIの中には、関数のアドレスを指定しなくてはならないタイプのものがある。関数のアドレスという概念のないVisual Basicではまったくのお手上げである。しかし、Visual Basic 5.0からは限定こそあるが関数のアドレスを知ることができるようになっているから、Windows APIはすべて使えるようになった。しかし、パフォーマンスを考えれば、市販のカスタムコントロールなどを使った方がよいケースもある。
このようなワナこそあるが、Windows APIを使えばVisual Basicだけでは解決できなかったことや、パフォーマンスを上げることもできる。そして、何よりもWindowsの内部動作を知ることこそ、プログラミングの醍醐味に通じるハズだ。
このように考えてくると、Visual Basicをもう一歩先まで知るために重要なのは、Visual Basic自体の関数を知ることやデータアクセスなどの機能ではないことが分かるだろう。
Windowsの基本動作を理解してAPIを操り、COMの仕組みを知ってコンポーネント化したプログラミングをし、市販のコントロールを活用したり場合によっては作っていく。
これがVisual Basicハイパープログラマーである。テーマはたった3つであるが、その内容は広い。すべてを一気に制覇することは難しいが、この特集をきっかけにして、少しずつでも、もう一歩先に進んでほしい。その先にあるものは、Windowsプログラマーとしての醍醐味のハズである。
