DLL内のApplication.HandleにApplication.MainForm.Handleを割り当てるDelphi XE2

Question

DLL内から作成されるフォームには小さな問題があります。

基本的には、dllのフォーム（Form1）が表示されている（私はそれが一番上になければならないと思います）、別のフォーム（Form2）を開くと、 DLLの中に）。ヒントが表示されるようにForm2のコントロールにカーソルを置くと、Form2はすぐForm1の後ろに移動します。

これは、MainFormOnTaskBarがtrueの場合にのみ発生します。現時点では、メインアプリケーションのApplication.HandleをDLLに渡して、それをDLLのApplication.Handleに割り当てます。

代わりに、Application.MainForm.HandleをDLLのApplication.Handleに割り当てるために渡して、問題を解決することができました。

これは安全ですか？誰もがこの問題を解決する適切な方法を知っていますか？

Answer 1

あなたのソリューションは完全に合理的です。私は非常に似通ったExcel COMアドインを持っています。そのコードでは、DLLのApplication.HandleをExcelのメインウィンドウのウィンドウハンドルに設定しました。それはあなたがしていることに類似しています。

問題は、ウィンドウの所有権を正しく設定する必要があることです。アプリのメインフォームに戻るには、オーナーシップが必要です。 DLLのフォームは、メインフォームが何であるかについての知識がないため、その知識を提供する必要があります。

私は、Windowsで使用されているウィンドウ所有者の概念について話していますが、所有者のVCL概念は全く異なります。 VCLの用語では、これはpopup parentと呼ばれ、DLLフォームのポップアップの親を明示的にメインフォームに設定することで問題を解決できます。関連するプロパティはPopupModeとPopupParentです。メインアプリケーションに存在するフォームの場合、VCLは自然にポップアップの親をメインフォームにします。

しかし、popup parentを明示的に設定することについて話したところ、あなたの現在のソリューションはより簡単で便利であると強調しました。

これらの解決策の両方が行うことは、すべての補助書式がメインフォームによって所有されていることを確認することです。これは、これらのフォームが常にメインフォームの上にあることを意味します。メインフォームが最小化されている場合、補助フォームが最小化されることを意味します。ここに所有されている窓について読む：Window Features。

ちなみにDLLではなくランタイムパッケージを使用していた場合、パッケージ内のコードはメインフォームと同じVCLに接続されます。したがって、パッケージ化されたコードはメインフォームを見て、ウィンドウの所有者を適切に設定することができます。これは確かにパッケージを使用する利点の1つです。もちろん、パッケージではなくDLLを使用する必要がある理由は非常に良いでしょう。