Delphi:什么是 Application.Handle？

Question

什么是TApplication.Handle ?

它从何而来？

它为什么存在？

最重要的是:为什么所有表单都将其作为父窗口句柄？

德尔福帮助说:

TApplication.Handle

Provides access to the window handle of the main form (window) of the application.

property Handle: HWND;

Description

Use Handle when calling Windows API functions that require a parent window handle. For example, a DLL that displays its own top-level pop-up windows needs a parent window to display its windows in the application. Using the Handle property makes such windows part of the application, so that they are minimized, restored, enabled and disabled with the application.

如果我关注“应用程序主窗体的窗口句柄”这两个词，并且我将其理解为应用程序主窗体的窗口句柄，那么我可以比较:

“应用程序主窗体的窗口句柄”，与

MainForm的窗 Handlebars 的Application

但它们不一样:

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

那么什么是 Application.Handle ?

它从何而来？

它是什么 Windows® 窗口句柄？

如果是 是 Application 的 Windows® 窗口句柄的 MainForm ，那他们为什么不匹配呢？

如果是 不是 Application的窗 Handlebars 的 MainForm ， 那这是什么？

更重要的是:为什么它是每个表单的最终父所有者？

最重要的是:如果我尝试让一个表单成为无父无主的表单(这样它可以出现在任务栏上)，或者尝试使用诸如 之类的东西，为什么一切都会变得困惑？ IProgressDialog ?

我真正要问的是:制作 的设计原理是什么？应用程序句柄 存在？如果我能理解为什么，那么如何应该变得显而易见。

更新 通过二十个问题的游戏理解:

在讨论通过让其所有者使窗口出现在任务栏上的解决方案 null , Peter Below in 2000 said :

This can cause some problems with modal forms shown from secondary forms.

If the user switches away from the app while a modal form is up, and then back to the form that showed it, the modal form may hide beneath the form. It is possible to deal with this by making sure the modal form is parented [sic; he meant owned] to the form that showed it (using params.WndParent as above)

But this is not possible with the standard dialogs from the Dialogs unit and exceptions, which need more effort to get them to work right (basically handling Application.OnActivate, looking for modal forms parented to Application via GetLastActivePopup and bringing them to the top of the Z-order via 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; 

但随后他警告说:

If you click on a secondary forms taskbar button while another app is active this will still bring all the applications forms to front. If you do not want that there is option

当表单的所有者仍然是 Application.Handle 时，谁将所有表单带到前面.是 申请这样做？为什么要这样做？而不是这样做，不应该 不是 在做这个吗？ 的缺点是什么不是 这样做；我看到了 的缺点做 它(系统菜单无法正常工作，任务栏按钮缩略图不准确，Windows® shell 无法最小化窗口。

在另一篇处理 Application 的帖子中, Mike Edenfield says that the parent window sends other window's their minimize, maximize and restore messages :

This will add the taskbar button for your form, but there are a few other minor details to handle. Most obviously, your form still receives minimize/maximize that get sent to the parent form (the main form of the application). In order to avoid this, you can install a message handler for WM_SYSCOMMAND by adding a line such as:

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; 

Note that this handler goes in the PARENT form of the one you want to behave independantly of > the rest of the application, so as to avoid passing on the minimize message. You can add similar > code for SC_MAXIMIZE, SC_RESTORE, etc.

为什么我的 Windows® 窗口的最小化/最大化/恢复消息没有进入我的窗口？这是因为发送给窗口的消息是由 Windows® 发送给窗口所有者的吗？在这种情况下，Delphi 应用程序中的所有表单都归 Application“拥有”。 ?这是否意味着让所有者为空:

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

将删除 Application它的窗口句柄干扰了我的表单，Windows 应该再次向我发送我的最小化/最大化/恢复消息吗？

也许如果我们现在比较和对比一个“正常”的 Windows 应用程序做的事情，与 Borland 最初设计 Delphi 应用程序做事情的方式 - 关于这个 Application对象，它是主循环。

什么解决方案是Application对象解决？

Delphi 的更高版本做了哪些更改，以便不存在这些相同的问题？

Delphi 后续版本中的更改是否引入了初始应用程序设计如此努力解决的其他问题？

那些较新的应用程序如何在不受应用程序干扰的情况下仍能正常运行？

显然 Borland 意识到了他们最初设计中的缺陷。他们最初的设计是什么，它解决了什么问题，缺陷是什么，重新设计是什么，它是如何解决问题的？

Answer 1

应用程序窗口的原因有一点肮脏的历史。在开发 Delphi 1 时，我们知道我们想要为 IDE 使用“SDI”(分散在桌面各处的窗口)ui 模型。我们也知道 Windows 在那个模型上很糟糕(现在仍然如此)。但是我们也注意到，当时的 Visual Basic 使用了该模型，而且它似乎运行良好。经过进一步检查，我们发现 VB 使用了一个特殊的“隐藏” parking 窗作为“所有者”(Windows 有时会模糊父和所有者的概念，但区别类似于 VCL)用于所有其他可见窗口.

这就是我们解决包含主菜单的窗口很少聚焦的“问题”的方法，因此处理文件菜单的 Alt-F 根本不起作用。通过使用这个中央 parking 窗口作为中介，我们可以更轻松地跟踪消息并将其路由到适当的窗口。

这种安排还解决了另一个问题，即通常多个顶级窗口是完全独立的。通过让应用程序处理所有这些窗口的“所有者”，它们的行为都会一致。例如，您可能已经注意到，当您选择任何应用程序窗口时，所有应用程序窗口都会移到最前面，并保持彼此的 z 顺序。这也将使应用程序最小化并恢复为功能分组。

这是使用这个模型的结果。我们本可以手动完成所有这些工作以保持一切正常，但设计理念不是重新发明 Windows，而是尽可能地利用它。这也是为什么 TButton 或 TEdit 实际上分别是 Windows“用户”按钮和编辑窗口类和样式的原因。

随着 Windows 的发展，“SDI”模型开始失宠。事实上，Windows 本身开始变得“​​敌视”这种应用程序风格。从 Windows Vista 开始并继续到 7，用户 shell 似乎不适用于使用 parking 窗口的应用程序。因此，我们开始在 VCL 中进行调整，以消除 parking 窗口并将其功能移至主窗体中。这提出了几个“鸡与蛋”问题，即我们需要在应用程序初始化时足够早地让 parking 窗口可用，以便其他窗口可以“附加”到它，但主窗体本身可能不会很快构建。 TApplication 必须跳过几个环节才能使其正常工作，并且有一些微妙的边缘情况导致了问题，但大多数问题都已解决。但是，对于您前进的任何应用程序，它将继续使用旧的 parking 窗模型。