シェルの名前空間拡張は非常に複雑です。過去 10 年間、シェルの名前空間拡張機能を構築してきました。その最新版が MagicRAR (www.magicrar.com) のアーカイブ フォルダ機能です。
残念ながら、非常に慎重にコーディングし、スレッドが共有メモリに適切にアクセスできるようにしているにもかかわらず、シェルの名前空間拡張機能を使用すると、クラッシュが発生することがあります。Explorer ホスト プロセスは、シェル名前空間拡張の使用中または使用外でクラッシュします。
AQTime Pro などのさまざまなツールを使用して、シェル名前空間拡張コードのトラブルシューティングを行いました。メモリの上書きやその他の同様のアクセスの問題は報告されていません。これにより、問題が 1 つだけ残ります。VCL はスレッド セーフではありません!
実際、VCL をシェル名前空間拡張の一部として使用しています。Explorer のファイル リストは、実際にはホストされたコントロールであり、独自のシェル名前空間拡張の場合は、実際には VCL ウィンドウです。そもそもこれが許可されたシナリオであるかどうかは、（複数世代の開発の後）疑問に思っています...
メイン アプリケーション オブジェクトは、シェル名前空間拡張 DLL にも存在しません。メイン VCL スレッドがどこにも作成されていないため、TThread.Synchronize を使用すると Explorer がデッドロックします。メインの VCL スレッドを手動で作成する必要がありますか (どのように?) - おそらく別の DLL 内で - その DLL を介してすべての UI の作成/更新/破棄を再ルーティングしますか?
Explorer には、VCL ウィンドウを含む任意の数のウィンドウが表示される場合があることに注意してください。Explorer は、ターゲット システムの構成に基づいて、複数の独立したプロセスとして、または単一のプロセスとして実行されている場合もあります。
私たちのシェル名前空間拡張は、John Lam の出発点に基づいています (ほとんどの Delphi シェル名前空間開発者は知っているでしょう)。もちろん、最終製品でわかるように、この出発点には大幅な変更が加えられています。John Lam は、VCL がスレッドセーフではないという問題について、スライドやサンプル プロジェクトで一度も議論していません。
また、過去 10 年間にわたり、ShellPlus コンポーネントの複数のバージョンを使用しようと試みてきました。彼らはいくつかの優れた仕事をしましたが、残念ながら、私たちの経験では、彼らのコードに基づく非常に初歩的な取り組みでさえ、私たち自身のコードよりもはるかに悪い結果をもたらしました.
ShellPlus は実際には、カスタム VCL ウィンドウを作成する代わりに、Explorer 独自の定義済みホスト ウィンドウを使用する機能も提供します。これにより、VCL のスレッド化の問題を回避できる可能性がありますが、私たちの経験では、これでさえ実行可能な解決策ではありませんでした。これは、VCL がウィンドウ化されているかどうかにかかわらず、ShellPlus シェル名前空間の拡張は常に自作のコードよりも安定性が低いためです。
何よりもまず; この質問は理論的なものです。エクスプローラー内の VCL ウィンドウをプロセス ホストとして使用するシェル名前空間拡張で VCL を使用できますか?
もしそうなら、このシナリオで VCL スレッドセーフレスの問題はどのように処理されますか?