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?"