ユーザーのPCにActiveXをインストールすることなく、サーバー側で全て行う事も可能で、今回私が関係しているものもそうなっています。
ただ、問題のアプリケーションを私の開発環境に入れるわけには行かないため、テスト用に、私の方で必要とされるインターフェースだけを実装したActiveXコントロールを作成して使用する事を考えたわけなのですが。
これが思った以上に煩わしい。IEはかなりの頑固者ですねw
とにかく、コントロールに署名がないとどうにもならない。これは最低限の要求事項というわけです。
テスト用のオブジェクトにそんなもの用意できませんよね。
検索した結果、この問題に関しては、インターネットオプションのセキュリティタブにある各ゾーンのセキュリティ設定を操作する、というのがお約束のようです。
ところで、インターネットオプションの詳細設定タブにも…
「署名が無効な場合でもソフトウェアの実行またはインストールを許可する」とかあるし…
同じページの「マイコンピュータのファイルでのアクティブ コンテンツの実行を許可する*」も関係ありそう。
などと色々調整した結果情報バーはクリアでき、とりあえず実行できるようにはなったものの、ダイアログ「このページのActiveXコントロールは安全でない可能性があり…」だけが消えてくれません。
これを調べて彷徨っていたところ…
発見しました。
署名などが存在しない場合でもブロックされないようにするには下記のキーを追加する。
Implemented Categories\{7DD95801-9882-11CF-9FA9-00AA006C42C4}
Implemented Categories\{7DD95802-9882-11CF-9FA9-00AA006C42C4}
なお、ディストリビューションウィザードを使用した場合は、「スクリプトと初期化の安全性」という設定項目があるので、そこを「はい」に変更すれば、自動的にこれらのキーを追加するようなインストール用キャビネットが生成される。
私の場合は「テスト用」に「自分で開発した」わけなので、「コントロール及び設定」はローカルPC内に存在(コンパイル時に自動的に行われるため)しています。
きちんと配布手続きが取られていなかったこと、そのために設定の一部が書けていたこととファイルの位置がセキュリティで管理されていないエリアであること、それと、同じローカル上に存在するページといえども、ファイルを直接開いた場合とWEBサーバー経由とではまた違うらしいということ、このあたりをきちんと把握していないことが、解決を難しくした原因なのかもしれません。
あ~、今調べてみたところ、どうやらイントラネットと認識されていないようですw
なるほどねぇ…
http://マシン名をイントラネットとして登録したら、ダイアログ一切表示されずにインストールされちゃいましたw
追記:
スクリプトで関数を定義して、そのページをIFRAMEなどで公開すれば、[IFRAME要素].[関数名]としてアクセスできることがわかりました。
今回は、ActiveXなんて作らなくてもこれで十分だったのですね^^;
---この下に広告が入るかもしれませんが、私とは一切関係ありません。---