问在Windows Vista和Windows 7中排除DPI虚拟化和支持DPI的应用程序故障

EN

事实证明，当系统DPI从默认的96 dpi值更改时，我的应用程序中的怪癖有三个主要阵营：

1. 应用程序的一些控件使用GDI，一些控件使用GDI+。至少在我使用的控件中，GDI和GDI+字体在不同的DPI上有一些不同。
2. 我在delphi语言中使用了一个叫做VCL的框架。在这个Delphi VCL框架中，一些表单具有TForm.Scaled=true，而另一些表单具有TForm.Scaled=false。因为它要求您考虑缩放窗体中的每个控件，所以作为UI设计者，您会发现缩放窗体中的“丑陋”或不可接受的事情是很常见的。关闭缩放后，只剩下一些表单，这些表单要么被Windows 7本身在高DPI设置(DPI虚拟化模式)下拉大，要么看起来很小，因此，如果您愿意，可以忽略用户的“请求”，以获得您的96 dpi UI的144 dpi版本。其他人可能正在使用其他语言的其他框架，或者甚至可能使用非常老式的东西，比如Visual C++的对话框编辑器，在那里您可以使用“对话框单元”来设计对话框，这是另一种尝试将常规对话框布局从1:1对应到像素中分离出来的方法。缩放、拉伸和布局控件是UI设计的一个通用部分，必须以符合平台要求的方式来解决。在我的例子中，VCL做了很好的工作，让我设计了一个支持96dpi玻璃的航空应用程序，在其他DPI评级下也很好用，但我的大多数自定义控件都做不到。所以这是另一个坚持使用VCL自带的控件的原因:如果你关心高DPI支持，当你试图让高DPI支持工作时，你的工作就会变得更加困难。反过来，
3. DPI虚拟化是由一个清单设置控制的，你必须明确地将其包含在你的应用程序中。由于我的应用程序已经有了一个自定义清单(不是当你点击项目设置中的Enable-windows-themes复选框时包含在你的Delphi应用程序中的那个清单)，我能够一次又一次地打开和关闭这个DPI虚拟化，并在两种情况下测试我的应用程序。我发现我的应用程序在没有DPI虚拟化的情况下还不能运行，因此我让Windows保持其默认行为。如果其他人的应用程序使用100%的vcl控件，使用窗体缩放或一些其他技术来适当地调整自身的大小(例如来自DevExpress的VCL ExpressLayout控件)，以各种字体大小和DPI间距，则可以很容易地在禁用DPI虚拟化的情况下工作。在我看来，最终，VCL的功能已经足够了，但对于真正的工业级解决方案，需要一个比VCL更高级的框架，以便正确地综合处理“高DPI环境”等问题，并且在这些情况下，第三方控制通常不能像当前的VCL那样工作。这样的框架问题在WPF框架(微软)和Java (wing)中非常明显，但不是VCL的经典"Win16/Win32公共控制框架“的一部分。

总而言之，与过去相比，这些变化现在并没有太大的不同(复杂)，当时Windows XP和其他版本的Windows为您提供了“字体大小”的选择，而现在，Windows 7 UI体验试图相当深入地隐藏字体大小选项，并为您提供了一个“文本大小”更改用户界面，该界面修改了表面之下的系统DPI。这两种改变用户体验的方法都会导致几乎每个用户在至少一个主要的商业应用程序上出现问题，而这些应用程序看起来不是很好，或者不能正确处理由此产生的更改。随着超高点间距显示器在消费PC领域变得越来越普遍，这个问题可能会变得越来越严重，需要围绕更合适的框架进行UI设计。

你需要用下面这样的部分来表明你的应用程序是DPI感知的：

<asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
  <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
    <dpiAware>true</dpiAware>
  </asmv3:windowsSettings>
</asmv3:application>

如果你这样做，你将不会得到DPI虚拟化。

您并不打算使用DPI虚拟化，所以我认为尝试弄清楚它是如何工作的没有什么意义。它很容易依赖于显卡驱动程序。我们几乎不可能解释为什么虚拟化是这样的:你甚至没有给出任何屏幕截图，硬件细节等。然而，你根本不应该费心去诊断这个问题。显示为dpiaware，这不是问题。

作为参考，我提供给你：

• Writing High-DPI Win32 Applications
• http://www.rw-designer.com/DPI-aware

实际上，这是一个不同的问题。

您的表单不应该随着用户的字体大小而变大，它们应该随着字体大小的而变大。

Delphi's default form font是8pt Tahoma。

8pt Tahoma字符是：6.08px * 13px。

从Windows Vista开始，默认字体为9pt Segoe UI。

9pt Segoe UI字符为：6.81px * 15px。

​

​

你的Windows应用程序应该遵循用户的字体偏好(如IconTitleFont)。

我的Windows字体首选是12pt Segoe UI，它的平均字符大小为：8.98px * 21px

​

​

这意味着，如果您使用Tahoma 8pt (13px高)设计窗体，则需要将窗体和所有子控件缩放162%：

scaleFactor = (userFontSize / designedFontSize)
            = 21px / 13px
            = 1.615

如果你很小心，你会注意到改变DPI仅仅是改变字体大小的一种特殊情况。您的 8pt 字体仍为8pt，但8PT可转换为更多像素。如果您运行131dpi ( Windows 7中的136%缩放设置)，则：

9pt Segoe UI,  96dpi = 6.81px x 15px
9pt Segoe UI, 131dpi = 8.98px x 21px

​

​

注：我选择131dpi和12pt作为示例并不是巧合。在工作中，我运行96dpi，但12pt。在家里，我运行9pt但131dpi。两者都有相同的像素字体高度，21px。

最后，您需要根据大小差异调用ScaleControl：

procedure StandardizeFormFont(Form: TForm);    
var
   iconTitleFontName: string;
   iconTitleFontSizePixels: Integer;
   currentFontSizePixels: Integer;
begin
   GetIconTitleFont(iconTitleFontName, iconTitleFontSizePixels);

   //Change font face first
   //Some fonts are inheriently taller than others
   //(even at the same point size)
   Form.Font.Name := iconTitleFontName;     

   //Get the form's current font height (in pixels)
   currentFontSizePixels := Form.Font.Height; //negative number, but so is iconTitleFontSizePixels

   Form.ScaleBy(iconTitleFontSizePixels, currentFontSizePixels);
end;

实际上，这段代码非常简单。许多子控件需要手动更新：

• listview列需要使用size
• toolbar's获取wider
• controls需要拥有其字体的adjusted
• TImage控件需要将其图像拉伸到新的size
• toolbar‘s需要使用较大的图像

实际上，我们使用的是一个超级花哨的StandardizeFormFont版本，它递归地遍历窗体上的所有控件，并且最好根据控件的内容来调整每个控件。

Delphi的每个控件都应该覆盖它的ScaleControl方法，并做出它需要的调整：

protected
   procedure ChangeScale(M, D: Integer); override;