Windows 7では、タイトルに記載されているCOMponentsは、デフォルトでは "killbit"がCOMPAT_EVIL_DONT_LOAD(MSDN)に設定されているようです。 {>が< CLSID} \は、デフォルトでその値に設定されているように見えるHKLM \ SW \ IE \ ActiveXの互換性\その互換性フラグで、次のとおりです。components mscomctl.ocx、mscomct2.ocx、mswinsck.ocx:プログラムでキルビットを設定する
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{B09DE715-87C1-11D1-8BE3-0000F8754DA1}]
"Compatibility Flags"=dword:00000400
私は設定値を0に設定してください(つまり、Nirsoft's ActiveX Compatibility ManagerはCOMコンポーネントを「アクティブ化」するときに機能します)、すべて正常に動作します。
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\{B09DE715-87C1-11D1-8BE3-0000F8754DA1}]
"Compatibility Flags"=dword:00000000
しかし、これは1つのワークステーション用の単なるGUIソリューションです。私たちのソフトウェアをデプロイするには、私たちのソフトウェアに同梱の安全で安定した手順(スクリプトまたはツール)が必要です。キルビットを0に設定するか、レジストリエントリを削除するだけです。必要なことがなければ何もしません。好ましくは、解決策は、ファイル名またはファイルのリストの上を単に渡され、それ自体で必要なものはすべて実行される。
これは大きな疑問が始まるポイントである:COMオブジェクトについて
- を、レジストリがCLSIDによって、ないOCXファイル名によって照会される(つまり、WindowsレジストリでのInprocServer32エントリです)も(VersionIndependent)によって(HKLM \ \ソフトウェアクラス\ \ CLSID {<CLSID>} \)をPROGID。 ocxファイルまたは少なくともProgIDラディカルに関連するCLSIDを照会する方法、つまりバッチ/(PowerShell)スクリプト/ツール/何を知っていますか?
- 私はCLSIDがWindows 2000では最大7であることを理解していますか?
- SlayOCX.vbsは、SlayOCX.vbsとhereに記載されているようなグループポリシーと呼ばれる低レベルのアプローチのようですが、ネットワーク全体のソリューションとして機能する可能性があります。しかし、それはvbsで、一部の環境ではオフになっています。さらに、私はこのスクリプトでチェックするべきCLSIDのかなりのリストで終わるでしょう。例えばラップされる。バッチでは、記述された方法で顧客の管理者によって展開されるのではなく、レジストリなどのログオンスクリプトやrunonceキーによって展開される可能性があります。だから何を提案しますか?私は最初の情報的な質問を不必要にする解決策(ツール、新しいグループポリシー、私はまだわからない、より洗練されたスクリプト、システムとセキュリティ構成の問題に依存しない...)を好む。
サードパーティ製コンポーネントの依存関係を取り除く。信頼できる配布のためのベストプラクティスです。そして、はい、それはツリービューコントロールを意味しませんが、ツリービューの機能はネイティブAccessコントロールで複製できます。それはちょうど不気味ではありません。そして、はい、私は、Accessには、これらの年の後にネイティブツリービューがないというのはばかげていると思います。 –