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에 할당 할 DLL에 전달하여 문제를 해결할 수있었습니다.

안전한가요? 누구든지이 문제를 해결할 적절한 방법을 알고 있습니까?

Answer 1

귀하의 솔루션은 매우 합리적입니다. Excel COM 추가 기능에서 비슷한 기능을 수행합니다. 이 코드에서는 Excel의 주 윈도우의 윈도우 핸들이되도록 Application.Handle을 DLL에 설정했습니다. 그것은 당신이하는 일에 대해 유사합니다.

문제는 창 소유권을 올바르게 설정해야한다는 것입니다. 앱의 메인 폼으로 돌아 가려면 소유권 체인이 필요합니다. DLL의 양식에는 기본 양식이 무엇인지 알지 못하므로 해당 지식을 제공해야합니다.

윈도우 소유자가 완전히 다른 소유자의 VCL 개념이 아닌 윈도우 소유자의 개념에 대해 이야기하고 있습니다. VCL 용어에서는이를 popup parent라고하며 DLL 양식의 팝업 부모를 명시 적으로 주 양식으로 설정하여 문제를 해결할 수 있습니다. 관련 속성은 PopupMode 및 PopupParent입니다. 기본 앱에있는 양식의 경우 VCL은 자연스럽게 팝업 부모를 기본 양식으로 만듭니다.

그러나 팝업 부모를 명시 적으로 설정하는 것에 대해 이야기하면서 나는 현재 솔루션이 더 간단하고 편리하다고 강조했습니다.

두 가지 해결 방법은 모든 보조 양식이 기본 양식에 의해 소유되어 있는지 확인하는 것입니다. 즉,이 양식은 항상 기본 양식 위에 있습니다. 주 양식이 최소화 된 경우 보조 양식이 최소화됨을 의미합니다. 소유 윈도우 정보는 Window Features입니다.

덧붙여 말하자면 DLL이 아닌 런타임 패키지를 사용했다면 패키지의 코드는 기본 폼과 동일한 VCL에 연결됩니다. 따라서 패키지 된 코드는 기본 폼을보고 창 소유자를 적절하게 설정할 수 있습니다. 이는 패키지 사용의 확실한 장점입니다. 물론 패키지가 아닌 DLL을 사용해야하는 이유가있을 수 있습니다.