关于.net:字体大小的独立用户界面:当我切换到120 DPI时,一切都崩溃了吗?

关于.net:字体大小的独立用户界面:当我切换到120 DPI时,一切都崩溃了吗?

Font-size independent UI: everything broke when I switched to 120 DPI?

因此,我正在阅读有人链接到另一个问题的Windows Vista UI指南,他们提到您应该能够在切换到120 DPI的情况下幸免。好吧,我在安装了我的应用程序后启动了我方便的虚拟机,我们将得到什么...啊! UI失败!

一切都混乱了:有些容器不够大,无法容纳其文字;现在,位于"彼此相邻"的一些控件全部被挤压在一起/分开了;有些按钮不够高;我的ListView列不够宽... eeek。

听起来好像是一种完全不同的方法。我的上一个基本上是使用VS2008 Windows Forms设计器来创建基于像素的布局。我可以看到,如果我坚持使用Windows窗体,FlowLayoutPanel会有所帮助,尽管我过去发现它们相当不灵活。他们也无法解决容器(例如表单本身)不够大的问题;大概有办法做到吗?也许AutoSize属性?

这也可能表明是该跳到WPF的时候了。我觉得它是专门为这种事情设计的。

基本问题似乎可以归结为:

  • 如果我要坚持使用Windows Forms,那么获得字体大小无关的布局(使用户将字体设置为大字体或将显示设置为120 DPI)可以幸免的所有技巧是什么?
  • WPF在这里是否具有显着的优势?如果是,您是否可以说服我,值得这样做?
  • 在.NET堆栈中或一般情况下,是否存在任何与字体大小无关的布局的常规"最佳实践"?

了解Anchor和Dock属性如何在您的控件上工作,如何单独保留可以自动调整大小的内容,并在可能的情况下使用TableLayoutPanel

如果做这三件事,您将在Windows Forms中获得很多WPF设计经验。设计良好的TableLayoutPanel将尽最大可能调整控件的大小,以使其适合表单。结合Soeren Kuklau提到的AutoSize控件,停靠和AutoScaleMode,您应该能够制作出可以很好缩放的东西。如果不是这样,您的表单可能只包含太多控件;考虑将其拆分为标签页,浮动工具箱或其他一些空间。

在WPF中,它容易得多,因为自动调整控件的概念是内置的。在大多数情况下,如果使用坐标对放置WPF元素,则说明这样做是错误的。不过,您无法更改以下事实:在较低的分辨率下,填满屏幕并不需要太多的120 dpi文本。有时问题不是您的布局,而是试图在一个很小的空间中放太多东西。


通常,问题是使用两个不同的"常量"进行表单布局,然后更改其中一个常量而不更改另一个常量之一。

您正在为表单实体使用像素,并使用点(基本上是英寸)来指定字体大小。像素和点由DPI关联,因此更改DPI时,像素固定值突然与点固定值不一致。

有一些软件包和类,但是到了最后,您必须选择一个或另一个单位,或者根据变化的常数来缩放一个单位。

就个人而言,我会将表单上的实体更改为英寸。我不是C#人员,所以我不知道此功能是否受本机支持,或者您是否必须在应用程序启动时执行一些动态的表单大小调整。

如果必须在软件中执行此操作,请继续按正常大小调整所有大小(例如,调整为通常的96 DPI)。

当您的应用程序启动时,在显示表单之前,请验证系统是否为96 DPI。如果是这样,那就太好了。如果不是,请在显示表单之前设置带有校正因子的变量,并缩放和平移(修改位置和大小)每个实体。

但是,最终的方法是以英寸或磅(点为1/72英寸)指定所有内容,然后由操作系统处理。您可能需要处理极端情况(具有正确设置DPI的户外屏幕将以几像素显示您的应用程序...)


If I were to stick with Windows Forms, what are all the tricks to achieving a font-size-independent layout that can survive the user setting his fonts large, or setting the display to 120 DPI?

例如,AutoScaleMode可能是您的朋友。


推荐阅读