Assembly: System.Windows (in System.Windows.dll)
XMLNS for XAML: Not mapped to an xmlns.
Use a handler based on SizeChangedEventHandler to handle this event.
The Windows Phone layout system reads properties in the SizeChangedEventArgs event data class of this event, to determine whether the reported size changes should be considered significant. This allows the layout system to avoid forcing a layout change because of visually imperceptible differences between old and new height or width values. The imperceptible differences might be caused by rounding or calculations of a floating-point value.
It is not strictly necessary to avoid calling other APIs that influence layout of the current object from within a handler. For example: setting Height or Width; calling InvalidateMeasure or UpdateLayout; calling ApplyTemplate; any operation that might resize child elements and thus invalidate the parent layout. The layout engine has internal logic that is capable of avoiding many looping issues. However, it is still possible to create sizing or rendering loops if your handler logic combined with surrounding layout is not capable of reaching an end result for the size of the relevant object.
is raised whenever the size (either ActualHeight or ActualWidth) has changed on the object, and is raised after the Measure and Arrange passes are complete (for more information about these concepts, see Layout and panels for Windows Phone). If the position of the object within a parent container changes, but not the size, is not raised.
LayoutUpdated is a similar event, but LayoutUpdated is also raised for position changes. In addition, LayoutUpdated occurrence is not scoped to a specific object's layout properties, and is instead reporting on the entire visual tree that an object is contained in. LayoutUpdated informs you that something within the overall visual tree that contains the object has changed, but the layout specifics (size, position) of the object where the handler is attached might not have changed.