Visual Basic 6.0のWebツール

  • [アーティクル]

Mike Pope
Microsoft Corporation

1999年7月

**概要：**Microsoft® Visual Basic® version 6.0のWebアプリケーション ツールについてと、それらをWebアプリケーション開発の際に利用する方法について説明します。

はじめに
Web向けアプリケーション：その背景
リーチ対リッチ、軽量対重量
クライアント処理対サーバー処理
処理の置き場所
MicrosoftのWeb技術
Visual BasicによるWebアプリケーションの作成
Visual Basicが提供するWeb技術のまとめ
Visual Basicによるサーバー アプリケーションの作成
Visual BasicフォームへのWeb機能の組み込み
ブラウザ内でのVisual Basicアプリケーションのホスティング
最後に

はじめに

Webベースのアプリケーションの作成にまだ取り組んでいなくても、すぐに取り組むことになるかもしれません。最近まで、フォーム、データ処理、そして場合によってはデータベースアクセスの機能を持つ標準Microsoft® Visual Basic®べースのアプリケーションとして作成されてきたようなアプリケーションが、企業のイントラネットやインターネットで使えるように開発されることが増えてきています。これには、より楽な配備と保守、スケーラビリティ、そして保有総コスト（TOC）削減など、さまざまな利点があります。

近い将来にWebアプリケーションにかかわるかどうかは予想できないとしても、上司や顧客が「このアプリケーションをWebに載せられないだろうか?」と言う日が来ることは間違いありません。そのときに備えてVisual Basicの開発システムで何ができるかを知っておきましょう。

幸運なことに、Visual Basicバージョン6.0には、ほかのクールな機能に加え、Webアプリケーションの開発を支援する多数のツールがあります。実際、ツールが多過ぎて迷ってしまいます。とくにVisual Basic 6.0やWeb開発が初めての人は、最初はツールが多すぎると感じるかもしれません。さて、何をどのようなときに使えばよいのでしょうか。

本稿では、Web対応のVisual Basicアプリケーションを開発するためのツールを紹介し、それらをどのようなときに使うべきかを解説します（同様に重要なこととして、使うべきでない場合についても説明します）。とはいえ、本稿ではツールの細部まで説明しません。それはVisual Basic 6.0の付属ドキュメントの役割です。本稿を読み終えれば、付属ドキュメントのどこを見ればよいかがはっきりわかるはずです。

Web向けアプリケーション：

その背景 Webアプリケーション用のVisual Basicツールの詳細について説明する前に、少しおさらいをしておきましょう。Microsoftプラットフォームを対象とするWeb開発のベテランには、このおさらいは必要ないでしょう。Web開発の経験がない方は、お読みください。

ご存知のように、Microsoftは「Microsoft Windows Distributed interNet Applications Architecture」（略してWindows DNA）という名前を冠した、WindowsベースのWebアプリケーションを開発するための完全な公式アーキテクチャの普及を推進しています。このアーキテクチャの詳細な説明が、弊社のWebサイト、https://www.microsoft.com/japan/developer/windowsdnaにあり、それに付随する素晴らしい3Dアニメーション モデルがhttps://www.microsoft.com/dna/images/dna.htmlにあります。

本稿では、Visual BasicとそのWebアプリケーション用ツールに焦点を合わせます。本稿を読み終えたとき、Visual Basicとあなたのプログラミング技術が、Windows DNAの全体像の中で、どのような位置付けになるのか明確に理解できるようになるでしょう。

まずはじめに、Webアプリケーションはそもそもの成り立ちから、ブラウザ（クライアント）とWebサーバーからなるクライアント/サーバー型のアプリケーションです。もっとも単純なWebアプリケーションは「静的」なものです。つまり、ブラウザがページをリクエストすると、それが表示されるというものです。Webサーバーによるページの提供とWebブラウザによるテキストの描画以外の処理はありません。

アプリケーションにほかの処理を追加すると、もう少し複雑なことができます。どのような処理ができるのでしょう。ユーザー入力の検証、ユーザー入力に応じたWebページの変更、ビジネス ロジックの実行、情報の検索やデータベースへの登録、ユーザーが見られるページの限定といったことができます。つまり、スタンドアロン型のアプリケーションで行うあらゆるタイプの処理ができます。

リーチ対リッチ、軽量対重量

従来のVisual Basicベースのアプリケーションとは異なり、Webアプリケーションのクライアント側は通常はブラウザで、その機能と能力がわからない場合があります。たとえば、一般に公開するWebサイトのアプリケーションを作成している場合、様々な種類のブラウザによってアクセスされることが考えられます。ブラウザによっては上記の処理を実行する能力に制限があるかもしれません。

それら以外のブラウザは、非常に高度な処理を実行できます。後者の好例はもちろん、Microsoft Internet Explorer（バージョン4.0以降）です。このブラウザはダイナミックHTML（DHTML）の機能を幅広くサポートしています。もちろん、最もリッチなクライアントは標準のVisual Basicフォームです。Visual Basicを使えば、ブラウザをまったく必要としないWebアプリケーションを作成できます。これらのアプリケーションは、ブラウザの代わりに、ブラウズ機能やほかのWeb技術を含んだVisual Basicフォームを使います。

クライアント機能の違いが、アプリケーションの設計を決めるときの重要な判断要素となります。アプリケーションに様々な種類のブラウザからアクセスできる必要があるのかどうか、対象ユーザーが全員Internet Explorer 4.0以降を使うことがあらかじめわかっているのかどうか、アプリケーションをVisual Basicフォームで作成してもよいのかどうかといったことを考えます。このようなクライアント機能の違いは、「リーチ（reach）」と「リッチ（rich）」という単語で簡単に言い表されることもあります。

「リーチ アプリケーション」とはできるだけ多くのユーザーに到達（を獲得）できるアプリケーションです。Webの世界の言葉で言えば、任意のブラウザでアクセスできるアプリケーションを意味します。たとえばHotmail™などのWebアプリケーションは、あらゆるコンピュータのかなり多くの種類のブラウザでアクセスできます。リーチ範囲が広いと言えます。対照的に、「リッチ アプリケーション」は、（当然）ユーザーによりリッチな体験を提供します。これは、多くの場合、より魅力的なインターフェイスの提供と、ユーザーの操作に対する一層速い応答を意味します。

リーチ対リッチは白か黒かという具合に分けられるものではありません。程度の問題です。次のグラフを見れば、それぞれがどのようなものを指すのか理解できるでしょう。

**図1：**リーチ アプリケーション対リッチ アプリケーション

同じように、「軽量（thin）」クライアント対「重量（thick）」クライアントという違いもあります。軽量クライアントは小さくて軽いのですが、定義からして十分にリッチではありません。ブラウザがこの部類に属します。重量クライアントは、クライアントに多数の機能を付加したもので、機能が非常に豊富である一方で、メモリ消費量なども大きくなります。フォーム、コード、そしてVisual Basicランタイムが必要なVisual Basicベースの標準的なアプリケーションは重量クライアントの条件を満たしています。

クライアント処理対サーバー処理

実は、リーチとリッチの差はすべて、「処理がどこで行われるのか」ということなのです。リーチ アプリケーションはサーバーに処理を任せることで、クライアントとして多様なブラウザをサポートします。リッチ クライアント ベースのアプリケーションはフロントエンドに多くの処理を任せることができます。

たとえば、従業員のリストを表示するアプリケーションがあると想定しましょう。1ページに5人を表示します。［次へ］ボタンをクリックすれば、次々と名前を見ることができます。リーチ アプリケーションでは、クライアントの能力があまり高くないと想定して、「次ページ」処理をサーバーにさせます。［次へ]ボタンは現在のページ番号などの情報を1つにまとめて、サーバーに送ります。サーバーは現在のページ番号に基づいて、クエリーを更新して、次の5人の名前を含んだ新しいページを作成します。そして、そのページをブラウザに戻します。つまり、次ページを取得するための処理に、サーバーとのやり取りが含まれているのです。このようなアプリケーションはあらゆるブラウザで実行できます。しかし、サーバーとのやり取りにより、応答時間が遅くなることもあります。

**図2：**リーチ アプリケーションにおけるサーバーの処理

他方、リッチ アプリケーションでは、WebページはWebサーバーから送られますが、クライアントがデータそのものを処理します。クエリーが最初に実行された時点で、必要なデータがすべて（レコードセット全体）クライアントに送られます。以後、ユーザーが［次へ］をクリックすると、ページ処理のロジックがすべてクライアント側で処理されます。その結果として、応答時間が非常に短くなります。

**図3.0：**リッチ アプリケーションにおけるクライアントの処理

処理の置き場所

したがって、クライアント処理とサーバー処理のどちらを選択するかは、主にクライアントの処理能力に基づいて決めます。リーチ アプリケーションを作成するときには、サーバー ベースにします。だれでもアクセスできるインターネットの公開Webサイトは、できるだけ多くの人に（どのようなブラウザでも）使ってもらいたいアプリケーションなので、通常はリーチ アプリケーションにします。

逆に、Internet Explorerで統一された企業のイントラネット アプリケーションを作成する場合はどうでしょう。この場合、当然のようにリッチ クライアント アプリケーションを作るべきなのでしょうか。はじめは「その通り」だと思うかもしれませんが、実際の答は「状況次第」です。

この場合、クライアントが何であるかという単純な条件のほかに、以下の要素も考慮しなくてはなりません。

  • **セキュリティ：**サーバー ベースのアプリケーションでは、処理、コード、およびセキュリティのチェックにはユーザーからはアクセスできません。クライアント ベースのアプリケーションではコードの一部または全部がクライアントに置かれ、そこで実行されるため、ユーザーもそれを利用できます。
  • **処理の負荷：**サーバー ベースのアプリケーションは、あまりに多くのユーザーが一度にリクエストを出し、各リクエストに対するサーバーの処理が多くなると、性能が低下することがあります。当然のことながら、待ち時間が長くなれば、ユーザーは苛立ちを感じます（実際、サーバーの応答待ちがあまり長くなると、ブラウザはタイムアウトしてしまいます）。処理をクライアントに任せることで、このような作業の負荷をサーバーから取り除けます。
  • **オフラインでの使用：**クライアント ベースのアプリケーションはオフラインでの作業を想定して、設計できます。サーバー ベースのアプリケーションはユーザーが接続しているときしか使用できません。
  • **配備（デプロイメント）：**処理を更新する必要があるときには、中心のサーバーで一括で更新するほうが、個々のクライアントを更新するよりも簡単です。
  • **スケーラビリティ：**アプリケーションをより大きなプラットフォームに移行することになったときには、クライアントのインターフェイスを維持できるのであれば、サーバーの処理だけをより強力なプラットフォームに移すほうが簡単です。リッチ アプリケーションをより大きなプラットフォームに移行する作業は複雑な場合があります。

残された検討課題は、ネットワーク トポロジーに関するものです。イントラネット アプリケーションを作成する場合には、クライアント コンピュータとネットワークに接続されているほかのコンピュータとの間に直接的な接続があると想定できます。たとえば、クライアントからデータベースに直接接続できると想定できます。インターネット アプリケーションでは、通信プロトコルは通常はHTTPで、ネットワーク上に散らばっているデータベースにはアクセスできないのが普通です。リーチ アプリケーションの場合、データベースへのアクセスは通常はクライアントからではなく、サーバーから実行しなければなりません。

**注：**クライアントとサーバーが適切に構成されていれば、アプリケーションはMicrosoft Remote Data Service（RDS）を使ってクライアントからデータベースに直接通信できます。詳細については、https://www.microsoft.com/data/ado/rds/を参照してください。

MicrosoftのWeb技術

Microsoftはクライアント ベースおよびサーバー ベースのWebアプリケーションの双方について、いくつかの選択肢を提供します。クライアント ベースのリッチ アプリケーションでは、以下のものを利用できます。

  • インターネット向けのコントロールが付いたリッチなMicrosoft Win32®フォーム。本稿では、もちろんVisual Basicフォームです。
  • Internet Explorer 4.0以降のDHTMLページ。Dynamic HTML（DHTML）はブラウザ上で実行され、Visual Basicフォームと同じように、ページのすべての要素をプログラムから制御できます。また、クライアント側でのデータ バインドとリッチなUIなどの機能も備えています。現在は、DHTMLをサポートしているのはInternet Explorer 4.0以降だけです。

逆に、リーチの広いサーバー ベース アプリケーションのために、MicrosoftはMicrosoft Internet Information Services（IIS）がサポートするActive Server Pages（ASP）技術を提供します。ASPはHTMLテキストをコード（通常はスクリプト）と組み合わせます。スクリプトはページがリクエストされるとサーバー上で実行されます。

次のグラフではこれらの技術の相関関係を分かりやすく示します。

**図4.0：**クライアント ベースおよびサーバー ベースのアプリケーションで利用できるWeb技術

それでは、Visual Basicで何ができるかを見てみましょう。

Visual BasicによるWebアプリケーションの作成

本稿の冒頭でも述べたように、Visual Basic 6.0にはWebアプリケーションを作成するための技術がいくつか用意されています。Webへのアクセス機能を追加することで、Visual Basicで作成した既存のアプリケーションの機能を拡張できます。あるいはWebのために新たにアプリケーションを作成することもできます。

いずれの場合でも、Webアプリケーションの開発ツールとしてVisual Basicを使うべき理由はいくつかあります。

  • 第１に、どのようにWebアプリケーションを作ろうが、Visual Basic言語を使ってコードを作成できます。したがって、スクリプト言語やほかのWebプログラミング技術に深入りせずに済みます。
  • 第2に、Webコンテンツの表示（HTMLページ）とアプリケーションの機能（作成したVisual Basicコード）を分離できます。以前にWebページでスクリプトを書いたことがあれば、コードとレイアウトを同じページ内で一緒にすることがかなり広く行われている（それどころか、多くの場合混乱を招いている）ことはよく知っているでしょう。
  • 最後に、デバッグ機能などのVisual Basicツールを活用して、一層堅牢なWebアプリケーションを開発できます。現段階でも、Visual Basicで使用できる開発ツールは、スクリプト ベースのアプリケーションを作成するのに使うツールよりもだいぶ優れています。

Visual Basicが提供するWeb技術のまとめ

ここで、Visual Basicによって作成と利用が可能なWeb技術をおさらいしましょう。

  • Visual Basicを使ってサーバー ベースのアプリケーションを作成できます。WebClassという名前のVisual Basic技術を使って、リーチ アプリケーション用のWebページとサーバー側の処理を作成できます。
  • フォーム ベースのVisual Basicアプリケーションにインターネット機能を付け加えることができます。Microsoft ActiveX®コントロールをフォームに追加することで、フォームをWebブラウザ、HTMLエディタ、あるいはWeb通信オブジェクトに作り変えることができます。
  • Internet ExplorerをVisual Basicフォーム（アクティブ ドキュメント、かつては「ActiveXドキュメント」として知られていました）のホストとして使用できます。また、フォームを使う代わりに、ブラウザの中でWebページをコンテナにして使うことができます（DHTMLアプリケーション）。

次の表では以上の選択肢を分類し、どの技術がリッチまたはリーチに適していて、どのような種類のクライアントが利用でき、本稿のどこにその詳細が書かれているかを示します。ただし、必ず各技術の詳細を読んでおきましょう。なぜなら、それぞれの技術には、アプリケーションを設計する時に考慮しなければならない固有の要素があるからです。

表1. Visual BasicのWeb技術

リッチかリーチか やりたいこと 使用するクライアント 使用すべきVB技術 詳細情報
リーチ サーバー アプリケーションを作成する 任意のブラウザ WebClass（IISアプリケーション） 「Visual Basicによるサーバー アプリケーションの作成」
リッチ 既存のアプリケーションにWebアクセス機能を追加して拡張する Visual Basicフォーム Visual Basicフォーム＋インターネット コントロール 「Visual BasicフォームへのWeb機能の組み込み」
リッチ フォームのコンテナとしてブラウザを使うVisual Basicアプリケーションを作成する Internet Explorer 3.0以上で実行するVisual Basicフォーム アクティブ ドキュメント 「ブラウザでのVisual Basicアプリケーションのホスティング」
リッチ Visual Basicを使ってDHTML Webページの作成と操作をする Internet Explorer 4.0以上 DHTMLアプリケーション 「ブラウザでのVisual Basicアプリケーションのホスティング」

先ほど示した各技術の相関関係を示すグラフを更新する時が来ました。便利なことに、リーチ対リッチのグラフ曲線上に記した各点には、対応するVisual BasicのWeb技術があります。

**図5：**Visual BasicのWeb技術の相関関係

Visual Basicによるサーバー アプリケーションの作成

リーチ アプリケーションを作成する場合、処理はサーバー側で行わなければなりません。Visual Basicでは、WebClassを使って、この問題を解決します。

IISにおけるサーバー処理

まず、IISがサーバー側の処理をどのように扱うかを簡単に説明します。IISはActive Server Page（ASP）という特殊なタイプのWebページをサポートします。ASPページは、サーバー側処理のためのフックが組み込まれたHTMLページです。

IISは、ファイルの拡張子が.aspであることを検出すると、まずページの中で指定されているサーバー側の処理をすべて実行します（ASPページのサーバー側処理は多くの場合、スクリプト言語で書かれています）。このサーバー側の処理には、リーチ アプリケーションで必要なあらゆるビジネス ロジックを組み込めます。サーバー側の処理からユーザーに対して出力を送信する必要があるときには、サーバー側でページ内のHTMLテキストを変更します。サーバー側の処理が完了すると、ASP処理機能によるHTMLの変更がすべて終わった完成されたページがブラウザに送られます。

**図6：**IISのサーバー側処理

サーバーがすべての処理を行うことに注意してください。作成したページがユーザーのブラウザに到達するまでに、すべての処理が完了しています。そしてページのコンテンツの一部がサーバーによって動的に作成されていたとしても、ユーザーがそれを知ることはできません。加えて、当然ですが、ユーザーのブラウザは、ページにHTMLを表示する以外には何もする必要がありません。

WebClass

Visual Basicでは、上に述べたようなサーバー側の処理を「IISアプリケーション」、略して「WebClass」と呼ばれる技術を使って構築できます。WebClassを使えば、Visual Basicでサーバー側のロジックを構築して、それをASPページにリンクできます。ブラウザがASPページをリクエストすると、そのASPページはWebClassを呼び出して、サーバー側の処理を実行します。図7にWebClassの簡単な仕組みを示します。

**図7：**WebClassを使ったサーバー側の処理

WebClassは出力を生成するのみでなく、入力も受け取れます。たとえば、データ入力フォームのあるWebページを作ることもできます。ユーザーはデータを入力し、［送信］ボタン（Webの世界での呼び方）をクリックすると、データで埋められたフォームがサーバー上の特定のASPページに送られます。ASPページはWebClassを呼び出します。呼び出されたWebClassは、フォーム内の個々のコントロールの値を拾い出して処理を続けます。また、入力された情報を受信したことをユーザーに知らせるために別のページを送り、必要に応じてエラー メッセージなどの情報を表示することもできます。

忘れてはならないのは、この単純なデータ入力フォームではサーバーとの間でデータが往復することです。実際、完全にサーバー ベースのアプリケーションでは、コードを実行するときはいつでも、フォームをサーバーに送られなければなりません。ユーザーが数字を正しく入力したかどうかを調べるといった単純なことでも、フォーム（ページ）をサーバーに送信し、サーバー上のWebClassを呼び出して、フォームを検証し、そのフォームをユーザーに返さなければなりません。残念ですが、真のリーチ アプリケーションはこれだけのコストがかかるのです。

利点

ほとんどのVisual BasicベースのWebアプリケーションでは、WebClassを使うのが最良の方法です。以下に、その理由のいくつかを挙げます。

  • 最も重要なのは、Visual Basicでリーチ アプリケーションを作成するための技術がWebClassだという点です。WebClassを使えば、クライアントはInternet Explorerに限定されず、Visual Basicのランタイムも必要もありません。

  • ●WebClassを使えば、Visual Basicでリーチ アプリケーションが作れます。ASPページを作るために、スクリプトやその他のプログラミング環境を使う必要がありません。

  • アプリケーションのコードがサーバー上にあるので、個々のクライアントにコードを配備する必要がありません。これにより、アプリケーションのインストールと保守にかかる手間とコストを大幅に削減できます。

  • WebClassはサーバー側の処理をページのレイアウトから切り離します。ページには、HTMLのほかに、WebClassのインスタンスを作成して、必要な情報をそのインスタンスに渡すための最小限のコードだけが含まれています。

  • WebClassはコンパイルされます。したがってWebClassはスクリプトより優れたセキュリティと速度を提供します。

  • そして、もちろん、慣れ親しんだVisual Basic環境とツールを使って、WebClassを作成できます。

WebClassについては、Visual Basic 6.0のドキュメントに詳しく書かれています（WebClassについてさらに確証を得たければ、ドキュメントの中の「IIS アプリケーションの利点（Advantages of IIS Applications）」というトピックを参照してください）。WebClassについては、そのほかにもいくつかの記事があります。MSDN® のVisual Studio® 版とMSDN Onlineのどちらにも記事が載っています。MSDNライブラリのTechnical Articles\Visual Tools\にある「The WebClass Developer's Primer」という記事を参照してください。

Visual BasicフォームへのWeb機能の組み込み

上記の場合とはまったく逆の状況の場合を考えてみましょう。つまり、標準的なフォーム ベースのVisual Basicアプリケーション（従来型のリッチ アプリケーション）を持っていて、それにちょっとしたWeb機能を付け加えたい場合です。Web対応のコントロールを組み込むことで、Web機能を追加し、アプリケーションの機能を拡張できます。たとえば、フォームにコントロールを追加して、Internet Explorerと同じように動作させることができます。ただしこの場合、Internet Explorerと違って、あなたが表示とナビゲーションを完全に制御できるのです。

以下を含む様々なWeb対応コントロールが提供されています。

  • WebBrowserコントロール。ブラウザ機能を提供します。
  • DHTML Editingコントロール。WYSIWYG型のHTML編集ができます。
  • Internet Transferコントロール。HTTPとFTPプロトコルを簡単に利用できる機能を提供します。

通常はこれらのコントロールを使ってフル機能のWebアプリケーションを作成することはしません（そうするくらいであれば、実際のブラウザをクライアントとして使う方がよいでしょう）。その代わり、これらのコントロールは、基本的にクライアント ベースであるアプリケーションにいくつかのWeb機能を追加するのに便利です。

フォームからブラウザを作る

WebBrowserコントロールはブラウザ ウィンドウとして機能し、Internet Explorerと同じようにHTML（そしてDHTML）をレンダリングします。ボタン、テキスト ボックス、その他の標準的なVisual Basicコントロールを追加して、ナビゲーションを始めとするブラウザ機能を提供できます。

フォームからHTMLエディタを作る

DHTML Editingコントロールはもう1段階上の機能を提供します。ドキュメントをレンダリングするのみならず、WYSIWYG編集機能も提供します。このコントロールを使って、ユーザーに完全なHTML編集環境を提供できます。実際、DHTML Editingコンポーネントとともに提供されるサンプルのアプリケーションの中にはVisual Basicアプリケーションで書かれたHTMLエディタがあります。

Webの未加工データの送受信

もう1つの便利なコントロールであるInternet TransferコントロールはHTTPプロトコル（ダウンロード用）、またはFTPプロトコル（アップロード用またはダウンロード用）を使って、テキスト、画像、およびバイナリ情報の下位レベル伝送を実施します。このコントロールはウィンドウ上には情報をまったく表示せず、単にWeb上のある点と別の点との間の通信を実現するだけです。Internet Transferコントロールを使ったアプリケーションのよい例にWeb発行ウィザードがあります。このコントロールはVisual Basicの一部として提供されており、詳細はVisual Basicのドキュメントに書かれています。

ブラウザ内でのVisual Basicアプリケーションのホスティング

Visual BasicでWebアプリケーションを作成する第3の方法は、Visual BasicとInternet Explorerを混合したものを作ることです。それには2つの方法があります。

  • アクティブ ドキュメント。Internet ExplorerのようにVisual Basicフォームをホストできます。
  • DHTMLアプリケーション。Visual Basicフォームの代りに、DHMTLのWebページを使って、アプリケーションのユーザー インターフェイスを作成します。

アクティブ ドキュメント

アクティブ ドキュメントは別のコンテナの中でホストできるフォームです。この場合のコンテナはInternet Explorerです。この技術には見覚えがあるかもしれません。というのも、エクスプローラ、Microsoft Word、その他Internet Explorerの中で実行されるアプリケーションでも使われることがあるからです。アクティブなドキュメントはVisual Basicの以前のバージョンで登場し、Internet Explorer 3.0との互換性があります。

アクティブ ドキュメントのアプリケーションは他のVisual Basicアプリケーションと同じ方法で作成できます。Visual BasicまたはActiveXコントロールをフォーム（この文脈では、UserDocumentデザイナと呼びれます）上に配置し、コントロールの振る舞いを定義するコードを書き、プロジェクトをコンパイルします。アクティブ ドキュメントと標準のVisual Basicフォームとの違いは、アクティブ ドキュメントが以降はWebブラウザの中で動作するという点だけです。

アクティブ ドキュメントはスタンドアロンのVisual Basicアプリケーションと純粋にブラウザ ベースのアプリケーションとを混合したものです。したがって、アクティブ ドキュメントはおそらくニッチな技術として短期的にはメリットはあるかもしれませんが（次に説明します）、多用したり長期的に使ったりするものではありません。

アクティブ ドキュメントはスタンドアロン アプリケーションではありません。アクティブ ドキュメントを含むアプリケーションを配備するときには、Visual Basicのランタイム ダイナミック リンク ライブラリ（DLL）のほか、.vbdファイルやプログラムに関連するその他のファイルも含める必要があります。そして、当然ながら、ユーザーはアクティブ ドキュメントをホストできるブラウザを持っていなくてはなりません。実用的には、ブラウザはInternet Explorer 3.0、あるいはさらに機能の高いInternet Explorer 4.0以降でなければなりません。

DHTMLアプリケーション

ブラウザ内のVisual Basicベースのアプリケーションをホストする2番目の方法は、DHTMLアプリケーションを使う方法です。Visual Basic 6.0で初めて登場したこの技術は、WebブラウザでホストされるVisual Basicアプリケーションを作成するために使うという点では、アクティブ ドキュメントに似ています。しかし、DHTMLアプリケーションは、単にフォームがブラウザでホストされているというものではなく、純粋なDHTML Webページなのです。

DHTMLアプリケーションはDHTML Page Designerという名前のツールを使って作成します。単純にVisual Basicだけでなく、DHTMLのオブジェクト モデルとHTMLを組み合わて使うことができます。DHTMLアプリケーションにはActiveXコントロール、またはDHTMLページで動作するように作られた特殊なバージョンのVisual Basicコントロールを組み込むことができます。

**注：**DHTML Page Designerで使用できるActiveXコントロールは限られています。詳細についてはVisual BasicのReadmeファイルを参照してください。

アクティブ ドキュメントの場合と同じく、DHTMLアプリケーションもスタンドアロン アプリケーションではありません。つまり、これらも重量クライアントなのです。DHTMLアプリケーションを配備するときには、Visual BasicのランタイムDLLのほかに、.dsrファイル、.dsxファイル、およびプログラムに関連するHTMLページやその他のファイルを含める必要があります。また、アプリケーションをWebブラウザ（あるいはWebBrowserコントロール）など、DHTMLをサポートするコンテナの中で使わなければなりません。繰り返しになりますが、これもおそらくInternet Explorer 4.0以降を使うということを意味します。

アクティブ ドキュメントとDHTMLアプリケーションの利点

アクティブ ドキュメントとDHTMLアプリケーションはいくつかの共通する利点を提供します。

  • どちらも、開発環境としてHTMLオーサリング ツールではなく、Visual Basicが使えます。
  • どちらもコンパイル済みのVisual Basicコードを使います。そのため、ユーザーにコードを見られたり、操作されたりすることを防げます。

アクティブ ドキュメントは上記のほかに、固有の利点があります。以下の場合に使用するのに適しています。

  • 既存のVisual Basicフォームを短期間でブラウザ ベースのアプリケーションに移行したい場合。
  • ページ フレームだけでなく、ブラウザ ウィンドウ全体を制御したい場合。HTMLとDHTMLは、メニュー項目、スクロールバー、ツールバーなど、Webページの外部にある要素は制御できません。これに対して、アクティブ ドキュメントはブラウザ ウィンドウ全体を制御できるので、カスタムのメニュー項目を作成したり、ツールバーを操作したりできます。

一方、DHTMLアプリケーションは利点は、DHTMLのすべての機能を自由に使えるという点です。これによって、ブラウザに表示されるUIを制御できます。

不利な点

どちらの技術も、上で述べた理由により便利に使えますが、念頭においておかなければならない相殺要因もいくつかあります。まず、どちらの場合も、Visual Basicのランタイムと、ブラウザ（ホスト）としてInternet Explorerをユーザーが持っていなければなりません。

それ以外にアクティブ ドキュメントについて考慮しなければならない点は次のとおりです。

  • ブラウザがホストするVisual Basicフォームには、通常のWebページの外観と操作性が伴いません。たとえば、フォームにメニューがある場合、ユーザーは2つのメニューを目にします。つまりあなたのメニューとブラウザのメニューです。
  • アクティブ ドキュメントは必ずしもほかのWebページとうまく連携するわけではありません。たとえば、テキスト ベースのハイパーリンクなど、Webの一般的な機能がアクティブ ドキュメントでは実装することが難しい場合があります。これは、Visual Basicフォームにハイパーテキスト コントロールというものが実際にはないからです。ボタンやその他のプログラム可能なコントロールを使ってジャンプ機能を実装する必要があります。
  • アクティブ ドキュメントの配備は複雑なことがあります。
  • ブラウザ内でVisual Basicフォームをホストする技術は、Microsoftが今後も戦略的に取り組む可能性は低いでしょう。

アクティブ ドキュメントの一般的な規則は次のとおりです。つまり、アクティブ ドキュメントは、アプリケーションの特定の要素をWebに移行するために使うと便利な場合があります。作成するWebアプリケーション全体をアクティブ ドキュメントで作ってはいけません。そして、アプリケーションの将来のリリースでは、アクティブ ドキュメントを純粋なブラウザ ベースのアプリケーションに変えていくことを考えてください。

DHTMLアプリケーションにもまたいくつかの不利な点があります。

  • Visual Basicのほとんどのオブジェクト モデルとは異なる新しいオブジェクト モデル（DHTML）を学習しなければなりません。
  • 動作に必要なコンポーネント（Visual Basicランタイムなど）のダウンロードが大きく、ユーザーにとってはインストールと設定が複雑かもしれません。
  • アクティブ ドキュメントと同様に、DHTMLアプリケーションも、Microsoftが将来のVisual Basicのリリースでサポートするとは限りません。

アクティブ ドキュメントの詳細については、MSDNライブラリに収録されているVisual Basicの『コンポーネント ツール ガイド』の「ActiveXドキュメントの利点」、「ActiveXドキュメント作成の基本」、および「ActiveXドキュメントの作成手順」を参照してください。DHTMLアプリケーションの詳細については、Visual Basicの『コンポーネント ツール ガイド』の「DHTMLの開発」を参照してください。

最後に

ここまで読めば、Webアプリケーションを作るためにVisual Basicをどのように、どのような理由で、そして、どこで使えばよいか理解できているはずです。ほかのあらゆるアプリケーションと同様に、最初にすべきことは、開発目的と対象ユーザーを検討することです。今回のケースでは、「リーチ」（サーバー）と「リッチ」（クライアント）のタイプの中から、単にユーザーが保有するフロントエンドだけでなく、セキュリティや処理の負荷などの要素も考慮して、アプリケーションを選択します。

次に、アプリケーションの作成に使用するVisual Basic技術（1つまたは複数）を選択するという面白い仕事が控えています。一般的に最善の選択はWebClassです。この技術を使えば、最小の開発労力で最大の効果が得られます。それ以外のVisual BasicのWeb技術は、アプリケーション、カスタマ、開発の個別のニーズに特化しています。

もちろん、ここでは表面をなぞったに過ぎません。これらの個々の技術については、Visual Basicのドキュメントにはるかに詳しい情報が載っています。それ以外のすばらしい情報源としては、MSDN Onlineがあります。MSDN OnlineにはWebの設計に関するドキュメント、記事、ヒントなどがたくさん詰まっています。