Windows字体缩放比例大于100％时如何使GUI正常运行

Question

当在Windows控制面板中选择较大的字体大小（例如125％或150％）时，每次以像素为单位进行设置时，VCL应用程序都会出现问题。

拿走TStatusBar.Panel。我将其宽度设置为仅包含一个标签，现在使用大字体将标签“溢出”。其他组件也有同样的问题。

戴尔的某些新笔记本电脑已将默认设置设为125％，因此，在过去，此问题非常罕见，现在非常重要。

如何解决这个问题？

Answer 1

注意：请参阅其他答案，因为它们包含非常有价值的技术。我在这里的回答仅提供警告和警告，以防止容易理解DPI。我通常避免使用进行DPI感知缩放TForm.Scaled = True。仅当DPI意识对打电话给我并愿意为此付费的客户变得重要时，它才对我重要。这种观点背后的技术原因是，无论是否了解DPI，您都在打开一个通往受伤世界的窗口。许多标准和第三方VCL控件在High DPI中不能很好地工作。值得注意的例外是，包装Windows Common Controls的VCL部件在高DPI时表现出色。大量的第三方和内置的Delphi VCL自定义控件无法很好地发挥作用，或者根本无法达到很高的DPI。如果您打算打开TForm.Scaled，请确保针对项目中的每个表单，您使用的每个第三方和内置控件都以96、125和150 DPI进行测试。Delphi本身是用Delphi编写的。对于大多数形式，它都已打开“高DPI意识”标记，尽管就在大多数形式中，即使在Delphi XE2中，IDE作者自己也决定不打开“高DPI意识”清单标记。请注意，在Delphi XE4和更高版本中，HIGH DPI感知标记已打开，并且IDE看起来不错。我建议您不要使用具有高DPI Aware标志（如David的答案所示）的TForm.Scaled = true（这是Delphi中的默认设置，因此，除非您对其进行了修改，否则大多数表单都具有Scaled = true）。使用内置的delphi表单设计器构建的VCL应用程序。过去，我曾尝试对TForm.Scaled为true以及Delphi表单缩放出现毛刺时希望看到的那种破损进行最小化的采样。这些故障并非总是且仅由DPI值（而不是96）触发。我无法确定其他因素的完整列表，包括Windows XP字体大小的更改。但是，由于大多数故障仅出现在我自己的应用程序中，因此在相当复杂的情况下，我决定向您展示一些可以验证自己的证据。在Windows 7中将DPI Scaling设置为“ Fonts @ 200％”时，Delphi XE看起来像这样，并且在Windows 7和8中，Delphi XE2同样被破坏，但是这些问题在Delphi XE4上似乎已得到修复：这些大多数是标准的V控件，在高DPI时表现不佳。请注意，大多数事情根本没有扩展，因此Delphi IDE开发人员决定忽略DPI意识，并关闭DPI虚拟化。如此有趣的选择。仅在需要这种新的痛苦和困难选择的新来源时，才关闭DPI虚拟化。我建议你别管它。请注意，Windows通用控件似乎似乎可以正常工作。请注意，Delphi数据浏览器控件是一个围绕标准Windows Tree公共控件的C＃WinForms包装器。那纯粹是微软的小故障，要解决这个问题，要么需要Embarcadero为他们的数据浏览器重写一个纯净的本机.Net树控件，要么编写一些DPI-check-and-modify-properties代码来更改控件中的项目高度。甚至Microsoft WinForms都不能自动，自动地且无需自定义kludge代码来处理高DPI。更新：有趣的事实：尽管delphi IDE似乎没有被“虚拟化”，但它并未使用David所示的清单内容来实现“非DPI虚拟化”。也许它在运行时使用一些API函数。更新2：针对我将如何支持100％/ 125％DPI的要求，我提出了一个两阶段计划。第1阶段是清点我的代码，以获取需要针对高DPI进行修复的自定义控件，然后制定计划对其进行修复或逐步淘汰。第2阶段将采用代码的某些区域，这些区域被设计为没有布局管理的表单，然后将它们转换为使用某种布局管理的表单，以便DPI或字体高度更改可以在不进行裁剪的情况下起作用。我怀疑这种“内部控制”布局工作在大多数应用程序中会比“内部控制”工作复杂得多。