Assembly: System.Windows (in System.Windows.dll)
XMLNS for XAML: Not mapped to an xmlns.
<frameworkElement Height="double"/> -or- <frameworkElement Height="Auto"/>
Dependency property identifier field: HeightProperty
is one of three writable properties on FrameworkElement that specify height information. The other two are MinHeight and MaxHeight. If there is a conflict between these values, the order of application for actual height determination is that first MinHeight must be honored, then MaxHeight, and finally, if it is within bounds, .
Several of the FrameworkElement derived objects are also derived from Shape. Not all of the Shape classes typically use or Width to specify their appearance, and instead use specific properties that might define a set of points. In this case a or Width is calculated, but is not typically set directly.
Custom classes might have similar considerations where the class might have properties that are more meaningful for specifying dimensions than are or Width. In this case or Width are both still available as members and are settable, even though the desirable behavior might be to not enable the or Width setting. In critical cases, it might be useful to shadow the and Width properties to prevent them from being set directly by consumers of the class.
If the object where the or Width properties are set is a child object in another parent's child collection, setting or Width to a value is only a suggested value for Windows Phone layout. The layout system as well as the particular layout logic of the parent's class will use the value as a nonbinding input during the layout process, and might have to clip, resize the object, resize the container, or some combination of these behaviors that spans multiple participating objects in layout. In practical terms, a FrameworkElement is almost always the child object of something else; even when you set the on the page root. (For the page root, that value is used when the underlying application model establishes the basic rendering assumptions that create the Windows Phone content area in the application.)
The return value of this property is always the same as any value that was set to it. In contrast, the value of the ActualHeight may vary. The variance can occur either statically, because the layout rejected the suggested size, or momentarily. The layout system itself works asynchronously relative to the property system's set of , and the layout system might not have processed that particular sizing property change yet.
Negative values for are not permitted. Non-integral values for are technically permitted, but should generally be avoided and are normally rounded by the default layout rounding behavior.
In addition to the validation check, there is a nondeterministic upper value bound for that is enforced by the layout system (this is a very large number, larger than Single.MaxValue but smaller than Double.MaxValue). If you exceed this bound, the object does not render, and no exception is thrown. Do not set to a value that is significantly larger than the maximum size of any possible visual display, or you might exceed this nondeterministic upper bound.
"Auto" Layout and Double.NaN
The default value of and Width is not 0, it is Double.NaN. and Width support the ability to be an unset "Auto" value. Because and Width are Double values, Double.NaN is used as a special value to represent this "Auto" behavior. The layout system interprets the "Auto" value to generally mean that the object should be sized to the available size in layout, instead of to a specific logical pixel value.
If you want the "Auto" behavior for an object when it is used in layout, leave and Width unset at their Double.NaN default value. If you have previously set values and want to reenable the "Auto" behavior, set and Width specifically to Double.NaN.
Although not a common practice except for perhaps in visual state templates, you can also explicitly set and Width attributes in XAML to be the string Auto instead of a Double value. Setting Auto in XAML is a special behavior of the XAML parser, not a TypeConverter behavior.