字体大小独立的 UI：当我切换到 120 DPI 时一切都崩溃了？
因此，我正在阅读有人在另一个问题中链接到的 Windows Vista UI 指南，他们提到您应该能够在切换到 120 DPI 后继续生存。 好吧，我启动了安装了应用程序的便捷虚拟机，然后我们得到了什么……啊啊啊！！！ 大规模用户界面失败！
一切都杂乱无章：有些容器不够大，无法容纳文本；有些容器不够大，无法容纳文本。 一些“彼此相邻”的控件现在全部压在一起/分散开； 有些按钮不够高； 我的 ListView 列不够宽...哎呀。
听起来似乎需要采取一种完全不同的方法。 我的上一个基本上是使用 VS2008 Windows 窗体设计器来创建（我猜）基于像素的布局。 我可以看到，如果我坚持使用 Windows 窗体，FlowLayoutPanel 将会有所帮助，尽管我过去发现它们相当不灵活。 它们也没有解决容器（例如表单本身）不够大的问题； 想必有办法做到这一点？ 也许是 AutoSize 属性？
这也可能表明是时候转向 WPF 了； 我的印象是它是专门为这种事情设计的。
基本问题似乎归结为这些：
- 如果我坚持使用 Windows 窗体，实现与字体大小无关的布局的所有技巧是什么，该布局可以在用户将字体设置为大或将显示设置为 120 DPI 时继续存在？
- WPF 在这方面是否具有显着优势？如果是，您能否尝试让我相信它值得进行切换？
- 无论是在 .NET 堆栈中还是一般情况下，与字体大小无关的布局是否有任何通用的“最佳实践”？
So I was reading those Windows Vista UI guidelines someone linked to in another question, and they mentioned that you should be able to survive a switch to 120 DPI. Well, I fire up my handy VM with my app installed, and what do we get... AAAAGH!!! MASSIVE UI FAIL!
Everything's all jumbled: some containers aren't big enough for their text; some controls that were positioned "next to each other" are now all squished together/spread apart; some buttons aren't tall enough; my ListView columns aren't wide enough... eeek.
It sounds like a completely different approach is in order. My previous one was basically using the VS2008 Windows Forms designer to create, I guess, a pixel-based layout. I can see that if I were to stick with Windows Forms, FlowLayoutPanels would be helpful, although I've found them rather inflexible in the past. They also don't solve the problem where the containers (e.g. the form itself) aren't big enough; presumably there's a way to do that? Maybe that AutoSize property?
This might also be a sign that it's time to jump ship to WPF; I'm under the impression that it's specifically designed for this kind of thing.
The basic issue seems to come down to these:
- 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?
- Does WPF have significant advantages here, and if so, can you try to convince me that it's worth the switch?
- Are there any general "best-practices" for font-size-independent layouts, either in the .NET stack or in general?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
其一，AutoScaleMode 可能是您的朋友。
For one, AutoScaleMode may be your friend.
一般来说，问题是使用两个不同的“常量”进行表单布局，然后更改其中一个常量而不更改另一个。
您使用像素作为表单实体，并使用点（基本上是英寸）来指定字体大小。 像素和点通过 DPI 相关，因此您更改 DPI 后，像素固定值突然与点固定值不一致。
有用于此目的的包和类，但最终您必须选择一个单位或另一个单位，或者根据不断变化的常数缩放其中一个单位。
就我个人而言，我会将表单上的实体更改为英寸。 我不是 C# 人员，所以我不知道这是否是本机支持的，或者您是否必须在应用程序启动时执行一些动态表单大小调整。
如果您必须在软件中执行此操作，请继续正常调整所有内容的大小（例如，通常的 96 DPI）。
当您的应用程序启动时，请在显示表单之前验证系统的 DPI 是否为 96。 如果是的话，那就太好了。 如果没有，则在显示表单之前设置一个具有校正因子的变量，并缩放和平移每个实体（修改位置和大小）。
不过，最终的结果是以英寸或点（点是 1/72 英寸）为单位指定所有内容，然后让操作系统处理它。 您可能必须处理极端情况（具有正确设置的 DPI 的户外屏幕将以几个像素显示您的应用程序......）
In general, the problem is one of using two different "constants" for form layout, and then changing one of those constants without changing the other.
You are using pixels for your form entities, and points (basically inches) to specify font size. Pixels and points are related by DPI, so you change the DPI and suddenly your pixel fixed values don't line up with your point fixed values.
There are packages and classes for this, but at the end of the day you must choose one unit or the other, or scale one of the units according to the changing constant.
Personally, I'd change the entities on the form into inches. I'm not a C# person, so I don't know if this is supported natively, or if you have to perform some dynamic form sizing on application startup.
If you have to do this in your software, then go ahead and size everything normally (say, to your usual 96 DPI).
When your application starts, verify the system is at 96 DPI before you show your forms. If it is, great. If not, then set a variable with the correction factor, and scale and translate (modify both the location and size) of each entity before you show the form.
The ultimate, though, would be to specify everything in inches or points (a point is 1/72 of an inch) and let the OS deal with it. You might have to deal with corner cases (an outdoor screen with a correctly set DPI would show your application in a few pixels...)
了解 Anchor 和 Dock 属性如何在控件上工作，保留任何可以 AutoSize 本身的内容，并使用
TableLayoutPanel代码> 当你可以的时候。如果您完成这三件事，您将获得大量 Windows 窗体中的 WPF 设计经验。 设计良好的
TableLayoutPanel将尽力调整控件的大小，以便它们正确适合表单。 与 Soeren Kuklau 提到的 AutoSize 控件、对接和 AutoScaleMode 相结合，您应该能够制作出可以很好缩放的东西。 如果没有，您的表单可能有太多控件； 考虑将其拆分为选项卡页、浮动工具箱或其他空间。在 WPF 中，这要容易得多，因为自动调整大小控件的概念是内置的； 在大多数情况下，如果您使用坐标对放置 WPF 元素，那么您的做法是错误的。 不过，您无法改变这样一个事实：在较低分辨率下，不需要太多 120 dpi 文本即可填满屏幕。 有时问题不在于您的布局，而在于试图在狭小的空间中放置过多的东西。
Learn how the Anchor and Dock properties work on your controls, leave anything that can AutoSize itself alone, and use a
TableLayoutPanelwhen you can.If you do these three things, you'll get a lot of the WPF design experience in Windows Forms. A well-designed
TableLayoutPanelwill do its best to size the controls so that they fit the form properly. Combined with AutoSize controls, docking, and the AutoScaleMode mentioned by Soeren Kuklau you should be able to make something that scales well. If not, your form might just have too many controls on it; consider splitting it into tab pages, floating toolboxes, or some other space.In WPF it's a lot easier because the concept of auto-sizing controls is built-in; in most cases if you are placing a WPF element by using a coordinate pair you are doing it wrong. Still, you can't change the fact that at lower resolutions it doesn't take much 120 dpi text to fill up the screen. Sometimes the problem is not your layout, but an attempt to put too much into a small space.