经常很奇怪, 一些本应是每个开发人员一开始就应该碰到应该把它挖出来的东西, 实际上很晚才发现, 自己也是如此, 一直以来没有考虑大字体下WinForm 的外观, 总觉得那是小众的选择, 可以不必管它. 直到我老板喜欢上了大字体, 每次看我们的程序, 总是指着被折到下一行显示不完全的label对我说: 这个要改改, 某某软件在大字体下就是好的.
的确, 至少应该考虑96和120 两种分辨率.
找到
<>, 第4章, 布局. page 144, 作者给出了应用了自动缩放窗体大小的几个窗口, 以证明默认情况下WinForms已经做的有多完美, 事实是: AutoScaleMode 设置为Font时, 有bug, 有时可以有时不行, 最糟糕的是, 我找了一大圈, 没有发现确定的word around的办法. 最让人感觉痛快的是在微软自己网站上有人报的一个bug.
我觉得微软的态度有点不好意思认帐, 总说自己没复现自己这个bug. 事实上作者给出的复现步骤很清晰简单, 我一次性就能复现出来.
最后有人总结说步骤是:
Create a new Windows Forms Application on one computer, and run the application on another computer with a different DPI setting.
1. Create a new Windows Forms Application and check that the AutoScaleMode property is set to Font. --> form will NOT scale on other computer.
2. Place a button on the form --> form will scale
3. Change the font of the form to "Tahoma" --> form will not scale
4. Set Localizable property of the form to true --> form will scale
5. Set Localizable property of the form to false --> form will not scale
可惜, 并不是 把 Localizable 设置为true就一定能保证成功, 我在自定义控件(与上面直接针对Form有所不同)中明确设置了Localizable为true, 照样失败.
最后, 只好放弃Font缩放, 改用基于DPI的. 放大的结果比基于Font的略大.
小结一下:
做UI时, 至少要有个常备的VMWare 虚拟机, 设置成大字体, 跑一遍看看UI有没有被搞乱.
还有其它一些奇奇怪怪的事情: 在我自定义的控件中, 改变了 AutoSize, 子控件的 DockStyle为Fill几个Property后, 行为变得很奇怪. 在PropertyGrid中设置成什么大小, 它偏就不是那个尺寸. 真正等程序跑起来的结果更离谱.
WinForms layout的内部机制一直没找到足够详细的资料, 又一次验证了Joe说过的"抽象漏洞法则", 任何抽象都有漏洞, 总有一天, 那些被抽象掉的东西会跳出来狠咬你一口, 让你把之前从中得到的大多数好处一次吐出来.
找了一天这方面的问题, 对一些技术作者包括这本书的第一作者 Chris sells, 也有点不满了. 相比很多其它的作者, Chris sells算是务实派的了. 比如曾经因为 Programming Windows 出名的 peztold, 写了一本WinForms方面的又厚又烂的书, 照本宣科, 把FCL中的类库中挑出一些东西来讲, 看不出来他实践过什么WinForms, 很多人都认为, Peztold 用这本书自己砸了招牌. Chris sells的书中还是处处能显示出挽起袖子干过的痕迹, 可惜WinForms涉及的细节太多, 这样的实验还是浅尝辄止的为多. 深度不够, 也没有来自一线实用经验才碰得到的tricks.
阅读(1983) | 评论(0) | 转发(0) |
