Partager via

Why are some buttons 26 pixels high?

  • Article

In VS.NET that is.  If you’ve got a sharp eye, you’ve probably noticed that some dialogs in VS have normal 23 pixel high buttons and some dialogs have 26 pixel high buttons.

 

The reason?  It turns out that 15% makes a difference.

 

Last week one of the devs on the WinForms team was investigating a bug in Whidbey stating that all managed dialogs in VS were 15% taller when hosted in VS than when they were created in the designer.  At first he thought this might have has something to do with the layout and AutoSize changes we've made in Whidbey.  But he couldn't find any code changes that would've caused this behavior. 

 

He then came by to report that he'd found nothing.  So we started looking into how Forms look as they come out of the designer and started looking at the AutoScaleBaseSize code in Form.

 

For those unaware, AutoScaleBaseSize is the way Windows Forms deals with different font sizes at runtime.  At designtime, the height and width of the font the Form was designed with is stored in InitializeComponent.  At runtime, this figure is compared to the current font and the Form is scaled up or down appropriately.

 

What is the "appropriate" amount of scaling?  Well, take the new font height and divide it by the old font height, then add .08 if the ratio is greater than 1, or subtract .08 if the ratio is less than 1. 

 

The .08 value is a fudge factor we had to add as bugs were found that the scaling wasn't aggressive enough.  If you think this method of scaling seems a bit odd, you're right, but I'll talk about that a bit later.

 

Also, feel free to harass ChrisAn about the .08 fudge factor as this was his invention.  J

 

Back to the bug at hand.  If a Form is designed in VS with the standard font of MS Sans Serif, 8.25, the AutoScaleBaseSize will be 5, 13.  The default font in VS is Tahoma 8.25.  Which has a font width of 5 and a height of 14.

 

If you divide 14 by 13 and add .08, you get approximately .15.  This is why buttons on collection editors are 26 pixels tall when they were originally 23 pixels tall.  Of course the rest of the dialog will also grow 15% taller.

 

So it turns out that this isn't a bug new to Whidbey, but a bug that'd been around since Visual Studio .NET 2002.

 

The simple workaround is to set AutoScaleBaseSize to 5, 14 for designer dialogs.  The right fix is for us to rethink the way AutoScaleBaseSize works and make sure that a font height delta of 1 doesn't yield a button 3 pixels taller.

Comments

  • Anonymous
    January 26, 2004
    The comment has been removed
  • Anonymous
    March 18, 2004
    I've come to hate AutoScaleBaseSize.

    I run in 120dpi, other devs run in 96dpi. Dialogs I design look wrong when they open them and vice versa.

    Basically we need some form of auto-scaling at design time as well. I guess everyone at MS must use 96dpi. But my eyes doth protest.

    Makes me miss good old dialog units.
  • Anonymous
    July 11, 2005
    It all stems back to a rather unfortunate implementation of Control.DefaultFont.   Raymond...