Remember to set AutoMessWithYourHead to false

There's nothing quite like the frustration of trying to keep an application from helping you. I spent a good chunk of the past weekend trying to figure out why a UI package was displaying controls at random sizes.

I'm working a Windows client application that's built on the .NET platform, with the UI built in Windows Forms. We recently moved from .NET 1.1 to .NET 2.0, and I've generally been impressed by the wealth of new UI facilities. In particular, most controls can now auto-size to a reasonable size (finally!), and the new TableLayoutPanel and FlowLayoutPanel go a long way towards building scalable UI in a structured way through the visual designer without having to hand-code a bunch of layout logic.

The new platform is not without its faults, however, as I discovered when some custom controls mysteriously changed sizes. I'd create a control with a bunch of auto-sized elements and nested layout panels, and in the designer everything would look perfect. I'd build the project, drop the control on to a form, and the control would look almost right—but the size would be off by some small, random amount. No amount of inspection could determine why this was happening, nor could any amount of groveling through the docs.

It turns out that Microsoft Visual Studio 2005 offers yet another attempt to help ISVs build UIs that scale with respect to the user's preferred system font. Scaling UI to assist users who, for example, prefer large fonts is in principle a great thing. Changing the development paradigm for coping with this problem in a new product release is not so great.

VS 2005 does so through a new form property called AutoScaleMode, although perhaps a more appropriate name for this property might be AutoMessWithYourHead. Its default value is true. The true value means that Windows Forms will try to scale your UI with regard to the system font—although it won't tell you it's doing this.

Now that I know what the $#*@% is going on, I can understand why Microsoft changed this behavior, and it's at least nice to see them trying to fix this. The underlying problem is that a modern, complex UI layout package is essentially a pretty face on top of a recalc engine. As the Microsoft Excel team learned years ago, in a complex spreadsheet it can be near impossible to track down why a particular cell value is ending up with the value it does. To address this very problem, Excel offers a tool that let you visually trace the origins of any calc.

In the same light, it would be enormously valuable for WYSIWYG HTML editors or a client UI designers to offer some way to point to a visible element and ask, "Why is this thing ending up with the position and size that it has?"

Comments

[Robert W. Anderson]

Is this behavior new?

AutoScaleMode (plus some other features) replace the old AutoScale which defaulted to true. AutoScale has been deprecated. The new property, AutoScaleMode, is an enumeration. For Forms, it defaults to "Font".

It appears to me that this default behavior should be the same as what was in .NET 1.1.

One of the problems with auto-scaling is that the developer tends to assume that if it looks good on their machine, it will look good everywhere. In this modern day, we all expect VS2003/5 to handle this for us. But I am surprised still at how many times I try out new software only to find that I can add see the bottom of a dialog box (or a splash screen is larger than the bitmap inside of it). My main computer is a laptop with 1920 by 1200 LCD that I run at 120DPI resolution.

Perhaps if the programmer was forced to pay more attention to this, they would get it right. We all know that good UI (just like good anything) doesn't come free.

[Aaron Brethorst]

Jan - I've opened a suggestion on the MSDN Product Feedback Center, which is our public bug tracking system for Visual Studio, WinFX, and the .NET FX (which includes Winforms) for consideration in Orcas.

http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?feedbackId=FDBK39230

Thanks for the suggestion!
Aaron Brethorst
Ux Program Manager
Visual Studio Core

[Ben Karel]

///////////////
In the same light, it would be enormously valuable for WYSIWYG HTML editors or a client UI designers to offer some way to point to a visible element and ask, "Why is this thing ending up with the position and size that it has?"
/////////////////

It's more geared towards web developers, but for the past five or so years, Mozilla browsers have been able to do that for web pages. The DOM Inspector (under the Tools menu) lets you select arbitrary elements in a page and see all the CSS selectors and associated rules that are being applied to the element. (Plus other nice things, like all the attributes set on that node. Quite useful.)

[Fraxas]

...and even better than that, the Web Developer toolabr for Firefox and Mozilla lets you edit that kinda stuff on the fly (I think it does a page reflow when you hit newline), so you can *immediately* see the consequences of any particular change.

[Peter Centgraf]

Andy Ko at the Carnegie Mellon HCI Institute has done this for visual 3D programming. He calls it the "Whyline".

http://www.cs.cmu.edu/~marmalade/whyline.html