Delphi: Что такое Приложение. Дескриптор?

Что TApplication.Handle?

• Куда это прибывает из?
• Почему это существует?
• И самое главное: почему все формы имеют его как свой родительский дескриптор окна?

Справка Delphi говорит:

TApplication. Дескриптор

Обеспечивает доступ к дескриптору окна основной формы (окно) приложения.

property Handle: HWND;

Описание

Используйте Дескриптор при вызове Windows API functions, которые требуют родительского дескриптора окна. Например, DLL, который отображает его собственные всплывающие окна верхнего уровня, нужно родительское окно для отображения его окон в приложении. Используя Handle свойство делает такую часть окон приложения, так, чтобы они были минимизированы, восстановлены, включены и отключены с приложением.

Если я фокусирую на словах "дескриптор окна основного бланка заявки на участие", и я беру это для значения дескриптора окна основного бланка заявки на участие, то я могу выдержать сравнение:

• "дескриптор окна основного бланка заявки на участие", с
• дескриптор окна MainForm из Application

но они не то же:

Application.MainForm.Handle: 11473728
Application.Handle: 11079574

Таким образом, что Application.Handle?

• Куда это прибывает из?
• Какой дескриптор окна Windows® - это?
• Если это - дескриптор окна Windows® Application MainForm, затем, почему они не соответствуют?
• Если это не дескриптор окна Application MainForm, затем, что это?
• Что еще более важно: Почему это - окончательный родительский владелец каждой формы?
• И самый важный: Почему все выходит из строя, если я пытаюсь иметь форму быть непорожденным не находящийся в собственности (так я, это может появиться на TaskBar), или попытайтесь использовать что-то как IProgressDialog?

Действительно то, что я спрашиваю: Что является объяснением дизайна, которое подает Заявку. Дескриптор существует? Если я могу понять, почему, как должен стать очевидным.

Обновление, Понимающее через игру двадцати вопросов:

В разговоре о решении того, чтобы заставлять окно появиться на панели задач путем создания ее владельца null, Peter Ниже в 2000 сказанного:

Это может вызвать некоторые проблемы с модальными формами, показанными от вторичных форм.

Если пользователь переключается далеко от приложения, в то время как модальная форма произошла, и затем обратно к форме, которая показала его, модальная форма может скрыться под формой. Возможно иметь дело с этим путем проверки, что модальная форма порождается [так; он значил принадлежавший] для формы, которая показала его (использование params.WndParent как выше)

Но это не возможно со стандартными диалоговыми окнами от Dialogs единица и исключения, для которых нужно больше усилия заставить их работать правильно (в основном обработка Application.OnActivate, поиск модальных форм, порожденных к Приложению через GetLastActivePopup и обеспечение их к вершине Z-порядка через SetWindowPos).

• Почему модальная форма заканчивается застрявшая позади других форм?
• Какой механизм обычно выявляет модальную форму, и почему это не функционально здесь?
• Windows® ответственен за показ сложенных окон. Что пошло не так, как надо, что Windows® не показывает правильные окна?

Он также говорил об использовании нового расширенного стиля Windows, который вынуждает окно появиться на панели задач (когда нормальные правила создания его не находящийся в собственности недостаточны, непрактичны, или нежелательны), путем добавления WS_EX_APPWINDOW расширенный стиль:

procedure TForm2.CreateParams(var Params: TCreateParams); 
begin 
   inherited CreateParams( params ); 

   Params.ExStyle := Params.ExStyle or WS_EX_APPWINDOW; 
end; 

Но затем он предостерегает:

При нажатии на вторичную кнопку панели задач форм, в то время как другое приложение активно, это все еще перенесет все формы приложений на передний план. Если Вы не хотите это существует опция

Кто выявляет все формы, когда владелец формы неподвижен Application.Handle. Приложение делает это? Почему это делает это? Вместо того, чтобы делать это, разве это не должно не делать этого? Что является оборотной стороной не выполнения этого; я вижу оборотную сторону выполнения его (системное меню не работают продерзко, миниатюры кнопки панели задач неточны, оболочка Windows® не может минимизировать окна.

В другом сообщении, имеющем дело с Application, Mike Edenfield говорит, что родительское окно отправляет другое окно их минимизировать, максимизировать и восстановить сообщения:

Это добавит кнопку панели задач для Вашей формы, но существует несколько других незначительных деталей для обработки. Наиболее очевидно, Ваша форма все еще получает, минимизируют/максимизируют, который отправляется в родительскую форму (основной бланк заявки на участие). Для предотвращения этого можно установить обработчика сообщений для WM_SYSCOMMAND путем добавления строки, такой как:

procedure WMSysCommand(var Msg: TMessage); WM_SYSCOMMAND; 

procedure TParentForm.WMSysCommand(var Msg: TMessage); 
begin 
   if Msg.wParam = SC_MINIMIZE then 
   begin 
      // Send child windows message, don't 
      // send to windows with a taskbar button. 
   end; 
end; 

Обратите внимание, что этот обработчик входит в РОДИТЕЛЬСКУЮ форму той, которая Вы хотите вести себя независимо> остальная часть приложения, чтобы не передавать минимизировать сообщение. Можно добавить подобный> код для SC_MAXIMIZE, SC_RESTORE, и т.д.

Как получается, что минимизируют/максимизируют/восстанавливают сообщения для моих окон Windows®, не идут в мое окно? Это вызвано тем, что сообщения, предназначенные для окна, отправляются Windows® владельцу окна? И в этом случае все формы в приложении Delphi "принадлежат" Application? Делает это не означает что создание пустого указателя владельца:

procedure TForm2.CreateParams(var Params: TCreateParams);
begin
   inherited;
   Params.WndParent := 0; //NULL
end;

удалит Application и это - окно Handle от вмешательства с моей формой, и Windows должен еще раз отправить мне мои сообщения mimimize/maximize/restore?

Возможно, если мы выдержали сравнение и контрастировали теперь, "нормальное" Приложение Windows делает вещи, с тем, как Borland первоначально разработала приложения Delphi, чтобы сделать вещи - относительно этого Application возразите и это - основной цикл.

• чем решение было Application объектное решение?
• Какое изменение было внесено с более поздними версиями Delphi так, чтобы эти те же проблемы не существовали?
• Изменение в более поздних версиях Delphi не представляют другие проблемы, что inital Проектирование приложений так старалось решать?
• Как те более новые приложения могут все еще функционировать без Приложения, вмешивающегося в них?

Очевидно, Borland осознала дефект в их начальном дизайне. Каков был их начальный дизайн, какую проблему он решал, каков дефект, какова была модернизация, и как он решает проблему?