Why, in WPF, do we set an object to Stretch via its Alignment properties instead of Width/Height?
Posted
by
Jonathan Hobbs
on Programmers
See other posts from Programmers
or by Jonathan Hobbs
Published on 2013-07-02T03:53:11Z
Indexed on
2013/07/02
5:13 UTC
Read the original article
Hit count: 271
In WPF's XAML, we can tell an element to fill its container like this:
<Button HorizontalAlignment="Stretch" VerticalAlignment="Stretch" />
Why is it that when we set an element to Stretch, we do it via the HorizontalAlignment and VerticalAlignment properties? Why did the WPF design team decide to take this approach over having Width="Stretch" and Height="Stretch"? I presume it was a calculated decision, and I'm curious about the reasoning.
CSS, among other technologies, follows the convention that stretching is done via the width and height properties, and that alignment affects positioning exclusively. This seems intuitive enough: stretching the element is manipulating its width and height, after all! Using the corresponding alignment property to stretch an element seems counter-intuitive and unusual in comparison. This makes me think they didn't just pick this option for no reason: they made a calculated decision and had reasons behind it.
Width and Height use the double data type, which would ordinarily mean assigning it a string would be silly. However, WPF's Window objects can take Width="Auto", which gets treated as double.NaN. Couldn't Width="Stretch" be stored as double.PositiveInfinity or some other value?
© Programmers or respective owner
