ActiveXコントロールを超えたWebブラウザ内アプリケーションの可能性 ActiveXというと、とかくActiveXコントロールの代名詞のように捉えられることが多いようだ。しかし、ActiveXはMicrosoftのインターネット技術の総称であり、ActiveXコントロールのことではない。むしろ、本当に次世代のイントラネット環境を担うのは、ActiveXコントロールではなく、ActiveX Documentsである。
ここでは、誤解が多いActiveX Documentsの実例をVisual Basic 5.0を使って解説する。
酒井 法雄
ActiveXという合い言葉で、Microsoftはインターネットに進出した。当初、ActiveXという言葉は、ActiveXコントロールの代名詞のように使われた時期があった。いや、そうマスコミが誤解しただけかもしれない。というのも、MicrosoftのターゲットはJavaであり、その対抗措置と見られたのがActiveXコントロールだったからである。
しかし、ActiveXとはMicrosoftのインターネット技術の総称である。似たようなものに、DirectXがある。そっち方面は詳しくないのだが、Directなんとかという名前のものがたくさんあり、それらを総称してDirectXと呼んでいる。ActiveXもまさにそういうものであり、インターネットに関わる技術はすべてActiveなんとかという名前になる。そう、XのつかないActiveなんとかである。しかし、どういうわけか、ActiveXコントロールだけはXのつくものである。この稿のテーマであるActiveX Documentsも、最近ではActive Documentsと呼ばれることが多くなっているようだ。まあ呼び名などどうでもいいことのようだが、従来OLEサーバーと呼んでいたものをActiveX EXEだのActiveX DLLだのヘンな名前にするのはやめてほしいものだ。
何がともあれ、ActiveXと言えば何といってもActiveXコントロールを思い浮かべるわけだが、そうではないのだということを言いたいのである。そして、むしろActiveXを持つ一連の技術のうち、Javaに対抗するような位置にあるもの、すなわちソリューションの方向としてイントラネットでHTTPあるいはHTMLの限界を超えるための技術は、ActiveXコントロールではなく、ここで紹介するActiveX Documentsなのである。
では、ActiveX Documentsとはいったいなんなのだろうか?
Microsoftは従来ActiveX Documentsのデモをするとき、拡張子が.XLSのファイルをURLに指定したとき、ExcelがIE(Internet Explorer)の内部で動作し、.XLSファイルをExcelのドキュメントとして扱うことができるものであるという見せ方をしてきた。
しかし、これは失敗である。ExcelのファイルがIEの中で見えることが重要なのではない。本当に重要なのは、IEの中でExcelのようなOLE Server、今どきの言葉で言うならばActiveX EXEやActiveX DLLが動くことである。
Excelのデモでは、たまたま拡張子がXLSのファイルに対応してExcelがインスタンシングされたわけだが、Visual Basicで作成するActiveX Documentsでは、拡張子が .VBDのファイルに対応して、Visual Basicで作成されたEXEファイルあるいはDLLが起動し、IEの内部で動作するようになる。もちろん、通常のEXEやDLLではなく、ActiveX Documentsに特化した仕組みを持つ物ではある。
このように、ActiveX Documentsは、むしろActiveXアプリケーションと呼んだ方が適切なものなのである。
では、ActiveX Documentsを使えば、ActiveXコントロールを使うのに比べて何がよいのだろうか?
まず、ActiveXコントロールを使ったときの開発スタイルを考えてみよう。これには、次の3つの技術を最低限知る必要がある。
さらに必要に応じて、CGIやSSIあるいはASPなども必要になるかもしれない。しかも、デバッグ環境なども整っているとは言い難い。
これを従来のC/Sに比較して考えてみれば一目瞭然、どっちがカンタンか分かるというものだ。では、なぜイントラネットを使おうという話になるのだろうか?
それは、イントラネットはカンタンで、サーバーですべてを管理することができるからだ。面倒なミドルウェアやインストールも必要ない。ところが、それは単純なHTMLとCGI, SSIの組み合わせのときの話である。そこでイントラネットが注目されることになったのである。この単純な組み合わせでは、表現力や機能的に不足が出てきた。そこでJavaなどで拡張することが試みられたわけだ。
しかし、JavaにしろActiveXコントロールにしろ、業務で使うようなシステムを構築するには、仕組みが複雑になりすぎてしまう。ここに大きな矛盾が出てきたのである。
一方、ActiveX Documentsはと言えば、これはブラウザの中で動作するアプリケーションであるから、従来のC/Sあるいはそれを拡張したn階層システムのフロントエンドと考えることができる。技術的にもVisual Basicだけ分かっていればよい。特にDCOMなどを使ってビジネスルール層を隠蔽したシステムとすれば、フロントエンドはインターフェイスだけに特化できるから、非常に簡便なシステムにすることができる。つまりは、あくまでもC/Sの延長でありながら、ブラウザ内で動作するために、インストールやメンテナンスを一極集中してラクに管理することができるというワケだ。
さらに言えば、ActiveXコントロールは、Javaなどに比べてセキュリティは無いに等しい。認証ダイアログはたしかにあるが、これはユーザーに責任を押しつけるもの以外の何物でもなく、心あるベンダーの作る仕組みではない。つまり、どこに悪意があるか分からないインターネットで使える技術ではないのである。現に、我々はInternet Mailの設定情報をレジストリから読み出し、WinSockを使ってPOPサーバーにコネクトして自分自身のパスワード情報を送るというActiveXコントロールを作ってデモしている(http://pcdn.int21.co.jp/pcdn/misc/)。このような危険窮まりないことができるものは、ある程度セキュリティや責任の所在が確保されているイントラネット向きの技術なのである。
ところが、イントラネットでは、よりきめ細かい動作が要求される。これをVBScriptやHTMLと組み合わせたActiveXコントロールなどでは到底作っていられない。ActiveXコントロールは、Visual Basicなどの開発ツール用の部品と考えるのが妥当であり、イントラネットに使えるものではないのである。
こう考えてくると、イントラネットでの次期主力技術は、ActiveX Documentsであることが容易に理解できるだろう。もちろん、ActiveX Documentsにもセキュリティの問題はある。だからイントラネット向きなのである。インターネットで使うということになると、ActiveXコントロール以上に危険なものとなることは間違いない。
Visual Basic 5.0でActiveX Documentsを作るには、新規プロジェクトダイアログで、「ActiveXドキュメントEXE」または「ActiveXドキュメントDLL」を選ぶ(図)。この違いは、インプロセスで実行されるかどうかの違いである。
図1:ActiveX Documentsの作成
ActiveX Documentsでは、フォームの代わりにUserDocumentモジュールが使われる。これは、ActiveXコントロールと似たようなもので、タイトルのないフォーム、すなわち埋め込みフォームのような見かけをしたものだ。
ActiveX Documentsでは、基本的には通常のアプリケーションと全く同じようにフォーム、もといUserDocumentモジュールに必要なコントロールをペタペタと貼っていき、同じようにコードをアタッチしていけばよい。そういう意味では、特にActiveX Documentsだからといって肩肘を張る必要はまったくない。それどころか、通常のフォームでデザインされ動作を確認したプロジェクトを、ActiveX Documentsに変換する「ActiveX Document Migration Wizard」というウィザードすらある。
しかし、もちろんActiveX Documents特有の拡張やクセ、あるいは注意点がないわけではない。UserDocumentオブジェクトのプロパティ、メソッド、イベントのうちで、拡張されているものを表に示す。
| ★プロパティ | |
| ContainedControls | 実行時にコントロールに追加されたコントロールのコレクションを返します．デザイン時には使用できず，実行時には値の取得のみ可能です |
| ContinuousScroll | スクロールバーのつまみが解放されたときにスクロールを継続するか，ユーザードキュメントの再描画だけを行なうかを指定します |
| HScrollSmallChange/ VScrollSmallChange | ユーザーがスクロールバーの矢印ボタン をクリックしたときにユーザードキュメントをスクロールさせる長さを指定します |
| Hyperlink | Hyperlinkオブジェクトへの参照を取得します |
| MinHeight/MinWidth | ビューポートの高さまたは幅の最小値を指定します．指定した高さまたは幅になるとコンテナにスクロールバーが表示されます |
| ScrollBars | オブジェクトの水平および垂直のスクロールバーを設定します |
| ViewportHeight/ViewportLeft/ ViewportTop/ ViewportWidth | ビューポート の現在のHeight，Left，Top，またはWidthの値を取得します |
| メソッド | |
| AsyncRead | コンテナによるファイルまたはURLからのデータの読み込みを，非同期に始めます |
| CancelAsyncRead | 非同期のデータ読み取り要求をキャンセルします |
| PropertyChanged | プロパティの値が変更されたことをコンテナに通知します |
| SetViewport | ビューポートに表示するUserDocumentの左上の座標を設定します |
| イベント | |
| AsyncReadComplete | コンテナが非同期読み出しの要求を完了すると呼び出されます |
| EnterFocus | オブジェクトがフォーカスを取得するとこのイベントが呼び出されます．オブジェクト自体または内在コントロールがフォーカスを受け取っています |
| ExitFocus | オブジェクトがフォーカスを失うとこのイベントが呼び出されます．オブジェクト自体がフォーカスを失った場合と，内在コントロールがフォーカスを失った場合が考えられます |
| GotFocus | オブジェクトまたは内在コントロールの中にフォーカスが移るとこのイベントが呼び出されます |
| Hide | オブジェクトのVisibleプロパティが偽（False）に変わるとこのイベントが呼び出されます |
| InitProperties | オブジェクトの新しいインスタンスが作成されるとこのイベントが呼び出されます |
| LostFocus | オブジェクトまたは内在コントロールがフォーカスを失うとこのイベントが呼び出されます |
| ReadProperties | 状態が保存されているオブジェクトの古いインスタンスをロードする際にこのイベントが発生します |
| ScrollBar | スクロールバー（ScrollBar）コントロールのスクロールボックスまたはスクロールバーを含むオブジェクトの表示内容が，水平または垂直方向にスクロールされた，あるいは移動したときに発生します |
| Show | オブジェクトのVisibleプロパティが真（True）に変わるとこのイベントが呼び出されますWriteProperties オブジェクトのインスタンスを保存すべき場合に呼び出されます．このイベントはオブジェクトの状態は保存が必要なことをオブジェクトに対して通知し，それによって後で状態を復元できるようにします．多くの場合オブジェクトの状態はプロパティの値だけで構成されています |
ActiveXコントロールについては別稿で詳細を書いたが、これと非常に良く似ている。特に、次のものについてはほぼ同様の機能を持っているので、ここでは詳細は述べない。
次にActiveX Documents固有の機能やクセなどについて述べていくことにしよう。これらは大きく分けて次のものがある。
詳細な話をする前に、ActiveX Documetsのデバッグ方法について述べておこう。というのも、これが少々特殊な方法だからだ。
ActiveX Documentsは、先に述べたように、OLE Serverの形態の一つである。Visual Basic 4.0では、OLE Serverのプロジェクトを実行するVisual Basicのインスタンスと、それを呼び出すコンテナのVisual Basicのインスタンスの二つのVisual Basicを起動してデバッグをした。
Visual Basic 5.0では、インプロセスOLE Serverのときには一つのVisual Basicインスタンスの中でデバッグができる。同様に、ActiveXコントロールのときにも、一つのインスタンスでデバッグができる。これは、複数のプロジェクトを一つのVisual Basicインスタンス内で実行できるようになったからである。ActiveX Documentsでも同様に一つのインスタンスでデバッグができそうなものだが、残念ながらそうはいかない。というのも、ActiveX DocumentsはIEの内部で動作することが前提の特殊な形式だからである。
ActiveX Documentsのデバッグは次の手順で行う。
これで、IE内部にActiveX Documentsがインスタンシングされる。エラー時の停止やブレークポイントなどは、Visual Basicでふつうに使うことができる。ただし、エラーで終了したときには、IEも一度終了する必要がある。
このように、ActiveX DocumentsのデバッグはIEを何度も起動しなおし、.VBDファイルを読み込み直さなくてはならない。「お気に入り」(なんという恥ずかしいメニュー名だ!!)に登録しておいたり、なるべく多くのメモリを積んでおくなどして、IEの起動を速くしてやった方がよいだろう。
次に、ActiveX Documentsでのイベントを見ていこう。基本的にはこれもActiveXコントロールと似たようなものである。次に、アクションを起こしたときのイベントの発生状況を示す。
Visual BasicからActiveX Documentsプロジェクトを動かしただけでは、何もイベントは発生しない。初めてイベントが発生するのは、IEに.VBDファイルが読み込まれてインスタンシングされたときである。このときには、次のような順番でイベントが発生する。
URLを移動したときには、Hideイベントだけが発生する。つまり、インスタンスは残ったままである。
戻るなどを使って再びActiveX Documentsのページに戻ると、Showイベントだけが発生する。
しかし、URLを何度か移動すると、Terminateイベントが発生して、インスタンスは終了する。これはブラウザの仕様によるが、IEでは4回URLが変更されるとTerminateイベントが発生する。
一度、Terminateイベントが発生した後で、再びActiveX Documentsのページに移動すると、最初に.VBDファイルを読み込んだときと同じように、3つのイベントが発生する。
ActiveX Documentsでも、ActiveXコントロールと同じようにプロパティを作ることができる。詳細は後述するが、プロパティを変更した後でURLを移動すると、WritePropertiesイベントの後、Hideイベントが発生する。
プロパティを保存したあとで、インスタンスがTerminateし、再びActiveX Documentsのページに戻ったときには、通常のときと違って、InitPropertiesの代わりにReadPropertiesが発生する。このように、ページごとにプロパティを保存することが可能である。
ActiveX Documentsにもプロパティがあると述べた。このときのプロパティは、Property Get/Letプロシージャを使う。ここで、ActiveXコントロールと同様に、プロパティに変化があったときには、PropertyChangedメソッドを実行する必要がある。プロパティの値をコンテナを通して保存したり読み込んだりするときには、UserDocumentオブジェクトのReadProperties/WritePropertiesイベントで、PropertyBagオブジェクトを使う。
ActiveX Documentsは、複数ページを使うことも可能である。図2は、二つのUserDocumentオブジェクトを使った例である。
このプロジェクトを実行して、.VBDファイルをIEに読み込むと、図3のような画面になる。
この例では、テキストボックスの値がそのままプロパティとして扱われている。したがって、テキストボックスの内容を書き換えてURLを移動しようとすると、そのタイミングでプロパティを保存しにいく。このとき、図4のようなダイアログが開く。
図4:プロパティ保存確認 この指示に基づいて処理は継続されることになる。 このサンプルでは、複数のUserDocumentオブジェクトを使っている。これは通常の標準EXEプロジェクトで複数フォームを使うのに似ている。なお、UserDocumentオブジェクトからFormをダイアログのように使うことも可能である。 リスト２の例では、UDFirstで変更されたStartURLプロパティを、UDSecondでも表示している。（図５） ちょっとオマケでHyperlinkオブジェクトの使用例を示す。このオブジェクトには、GoBack, GoForwardメソッドというヒストリー内での移動の他、NavigateToメソッドでの指定されたURLへの移動が可能である。 ただし、どうしたわけか原稿締め切り間際(いや完全に過ぎていた)に手に入った製品版同等品(?)では、GoBack, GoForwardが機能しなくなっていた。本当の製品版ではきちんと動くことを祈りたい。 ActiveX Documentsの機能のうちでもユニークなのは、スクロールとビュウポートに関するものだ。Visual BasicでのActiveX Documents開発画面から分かるように、ActiveX Documents自体は小さなサブフォームみたいなものである。もちろん大きなものにデザインすることも可能だ。いずれにしても、サイズは固定として作ることになるだろう。 次に、スクロールに関連するUserDocumentオブジェクトのメンバーを示す。 図6の例では、スクロールバーが出る最小サイズをInitialize時のサイズにしている。 図6:サンプルのデザイン画面 図7：サンプルの動作画面 IEがリサイズされたらスクロールだけで対応できるのだろうか? いや、コトによってはそれだけでは使いにくくなる可能性がある。たとえば、複数のテキストボックスがあったとき、{Tab}キーで移動していったら、見えないところに行ってしまった...などという間抜けなことになってしまう。 次のコードは、コントロール配列化されたテキストボックスで、フォーカスがきたらSetViewportメソッドを使って、フォーカスがきたテキストボックスが必ず左上に表示されるようにするものだ。 2番目のテキストボックスコントロールにフォーカスが移動すると、スクロールしてこのコントロールが一番上に表示されるようになる。(図8） 図8：コントロール移動のサンプル画面 次のコードは、IE内部の大きさに合わせてコントロールのサイズを変更するものである。UserDocumentのResizeイベントで、DBGridの幅と高さを、LeftとTopの位置はそのままにして、表示しうる最大の大きさにしている。 DBGridはできるだけ大きなサイズで表示される。(図9) 図9：コントロール画面変更のサンプル画面 ActiveX Documentsの作成やデバッグの概要はご理解いただけただろう。このように基本的にはフォームでのプログラミングに準ずるものであり、特に難しいことはないだろう。 ActiveX Documentsのプロジェクトを指定して、オプションから「インターネットダウンロードセットアップを作成」を選ぶと、 安全性についてのチェックが出てくる。（図10,11)これは詭弁にすぎない仕組みなのでどうでもよいだろうが、安全性保持をチェックしておいた方が、実行時に面倒が少なくなる。 図10:インターネットダウンロードセットアップを作成 図11:安全性についてのチェックを確認… ちなみに、初期化の安全性とは勝手にファイルにアクセスしないなどを保証することなのだが、そんなことをまったくしないActiveX Documentsでは仕事に役立つプログラムなど作れない。ましてやスクリプトで制御できないのがActiveX Documentsだから、スクリプト化の安全性保持って何? というようなものだ。 図12:ランタイムライブラリの置き場所を指定 後述するようにDCOMやRemote Automationを使ったn階層システムなどのフロントエンドとして使うときには、「リモートコンポーネントの追加」を選び、サーバーの.VBRファイルを指定する必要がある。(図13)もっとも、β版ではこの設定をしても、ActiveXコントロールおよびActiveX Documentsでは動かなかった。 図13:リモートコンポーネントの追加 こうしてできたファイルは、CAB(一つにまとめられる)やVBD(UserDocumentオブジェクトに対応した数だけある)の他に、最初の.VBDを読み込むためのHTMLファイルも作成される。 このHTMLファイルを読み込むと、例によって図14のような「安全性の侵害の可能性」ダイアログが開く。これはIEのセキュリティを中にしていたときの話である。これを低にしておくといちいちダイアログが出ないのでうっとうしくないが、知らないうちにヘンな物が動く可能性があって大変に危険だ。だからといって高にしておくと、まったく動かなくなってしまう。やはり開発者は中にしておくのがよいだろう。 図14:「安全性の侵害の可能性」ダイアログボックス このダイアログで<実行する>を選ぶと、図15のようにActiveX Documentsが実行される。 図15:ActiveX Documentsの実行 さて、これで万々歳のような気がするが、一つ気になるコトがある。というのは、プロパティである。デバッグ時にはローカルディスクにプロパティが書き込まれたが、WWW経由のときにサーバーに書き込みに行くわけにもいかない。さて、どうなるのだろうか? 例によって、変更を保存するかを聞いてくるダイアログが出るのは同じである。(図16) 図16:変更の保存ダイアログ しかし、ここで<はい>を選ぶと、何とファイル保存ダイアログが開いて、保存先を聞いてくる。ここからが調査不足もあって謎なところだが、こうして保存した.VBDファイルは、あくまでもローカルなものであり、（図17）そのURLがヒストリーに保存されるわけではない。いったいこの後どうしたら効率よくプロパティを再現できるかは、現状では謎である。 図17:VBDファイルはローカルに保存されるが、、 ActiveX Documentsについて一通り説明してきたが、WWWブラウザ内アプリケーションだと言っても、なんだかピンとこない方が多いかもしれない。いったいどのように使うことを想定したものなのだろうか。 図18:WWW+ActiveXControl+DCOM そこで、ActiveX Documentsを使ってブラウザ内アプリケーションを作ってしまおうというのである。これならば、ブラウザ内で実行されない通常のDCOM対応の3階層システムを作ってから、ウィザードを使ってActiveX Documentsに移行することも可能である。開発に必要な言語もVisual Basicだけで済むから効率的な開発が可能だし、配布をWWWサーバーから行う簡便さも活かすことができると言うわけだ。 図19:WWW+ActiveXDocumentsl+DCOM しかし、こういったシステムが実用化されるまでには、Transaction Serverがさらに高機能化する必要があるし、レジストリベースでのdcomcnfg.exeを使ってのリモートサーバー接続方法にも問題がある。もっとスマートにリモートサーバーとやりとりできるようにならなくてはならない。 ※NT 4.0附属のDCOMCNFG.EXEやVB5のリモート接続マネージャでは、レジストリの書き換えでローカル実行とリモート実行を切り替える。インストールや設定がスマートにできない問題がある。
このような複数オブジェクト間で変数を共有するには、標準モジュールを追加して、グローバル変数を使うことが可能だ。もし、前に使ったオブジェクトのプロパティなどを使おうというのであれば、Object型のグローバル変数を用意し、そのオブジェクト変数に共有したいオブジェクトをSetしてやればよい。なお、NewをともなわないオブジェクトのSetは、別のオブジェクトができるわけではなく、別名の指定ということになるので気をつけていただきたい。
ところが、IEはサイズを変更できる。当然ながら、内部に表示されるActiveX Documentsもサイズが変わってしまう。となると、IEが小さいときにはスクロールバーを出してスクロールができるようにしなくてはならない。こういったスクロールに関するプロパティやイベントが追加されているのである。・スクロールに関するもの
MinWidth, MinHeightよりサイズが小さくなると、スクロールバーが出る。(図7）Private Sub UserDocument_Initialize() MinHeight = Height MinWidth = WidthEnd Sub
そこで、今見える範囲を指定するため、次のようなプロパティやメソッドが用意されている。・ビュウポートに関するもの
Private Sub Text1_GotFocus(Index As Integer) UserDocument.SetViewport Text1(Index).Left, Text1(Index).TopEnd Sub
Private Sub UserDocument_Resize() On Error Resume Next DBGrid1.Width = UserDocument.ViewportWidth - DBGrid1.Left DBGrid1.Height = UserDocument.ViewportHeight - DBGrid1.TopEnd Sub
しかし、ActiveX Documentsをどう使っていくかということになると、これはもうイントラネットで使うためのものと言えるだろう。つまり、WWWブラウザ内アプリケーションである。
このときには、当然WWW Serverにファイルを配置しておくことになる。ただし、単純にEXEやDLLとVBDファイルを置いておけばよいというものではない。例によってCABファイルを作って置く必要があるのだ。
これは、Visual Basic附属のセットアップウィザードで作成することができる。次に概要を示す。
Visual Basicで作成されたActiveX Documentsは、ランタイムライブラリが必要になる。イントラネットであれば、社内にあるスループットのよいマシンに置いておけばよい。
最初に述べたように、イントラネットはWWWを中心としたインターネット技術を使って、社内の業務をブラウザでやってしまうおうというものだ。この方式は、すべてはサーバーから送られるために、インストールやメンテナンスの手間を大幅に軽減できるというメリットがある。
しかし、ステートレスなHTTPではトランザクションができない、何をするにもページが切り替わるといった問題がある。また動きのないページになりがちである。そこで、JavaやActiveXコントロールを使ったページという話になってきたわけだ。しかし、トランザクションの問題や、ページ切り替えをなるべくしないといった方向性を目指すためには、別の技術が必要である。その代表例がDCOMなどの分散オブジェクト技術である。
これは、Visual Basic 4.0のときに話題になったRemote Automationを発展させてNT 4.0からはOSレベルでサポートされたものであり、n階層システムを実現するためものである。一般には3階層システムなどと呼ばれ、インターフェイス層、OLE Serverで作られたビジネスルールをカプセル化したビジネスルール層、そしてデータアクセス層といったコンポーネント化で、スケーラビリティやメンテナンス性の向上を目指したものだ。
しかし、今までは、メンテナンス性はあまり期待できない、パフォーマンスがよくないなど、さまざまな要因があって話ばかり先行した割りには実がなかったが、DCOMの登場と、ビジネスルール層をうまく管理してくれるTransaction Serverの登場で、いよいよ現実性のあるものとなりつつある。
この3階層システムをブラウザ内部からWWWサーバーとは別ルートで行い、トランザクションも管理してしまおうというのが、図の発想である。しかし、すでに述べたように、HTML + VBScript + ActiveXコントロールでは、開発に必要な知識がいたずらに増えるばかりで効率がよくない。
実は、Windows NT 4.0からはCoCreateInstanceExというWindows APIが追加されており、リモートマシンを指定してのOLE Serverのインスタンシングが可能になった。残念ながらVisual Basic 5.0のCreateObjectではこれをサポートしていないが、Windows APIコールでCoCreateInstanceEx関数を使うことが可能だ。これはすでに私も実験済みである。いよいよ、DCOMを使った本格的な分散環境を構築できる可能性が高まってきたのである。そして、そのときに使われるユーザーインターフェイス層に最適なものこそ、ActiveX Documentsなのである。
int21 ホームページ |PCDN ホームページ
Copyright (c) 1996 int21 Corporation All Rights Reserved.
For questions or comments, please send mail to: pcdn@int21.co.jp
