Control Lifecycle

Dave Relyea — Sat, 11 Oct 2008 20:28:00 GMT

What happens when you create a Control? When do overrides get called and events get raised? When do styles get applied?

In response to this thread on silverlight.net, I've whipped this simple table up. There are some subtle differences between instantiating a control in XAML, and instantiating it via code that I've called out, but most of the lifecycle is the same.

Action	Control instantiated in XAML	Control instantiated in code
Control ctor	As soon as begin tag is parsed.	When you call it.
Explicit Style applied	If the Style property is set in XAML, it will be applied as soon as the end tag is parsed.	As soon as Style property is set.
Built-in Style (from generic.xaml) applied	As soon as the end tag is parsed, after the explicit Style (if any) has been applied. Will not override explicit Style.	When the control enters the tree. Will not override explicit Style.
Properties set	When the attributes are parsed.	When you set them.
Loaded event	Posted when the element is been added to the tree. Fired before the next frame. Happens before layout.	Same.
Template applied (i.e. control's visual are created from the Template)	In the Measure pass of layout. The Template property will be applied if the control has no visual tree. The control starts life with no visual tree, and the visual tree will be cleared when the Template property is set. You can also call ApplyTemplate yourself.	Same.
OnApplyTemplate called	Whenever the Template is applied. It is not necessary to call the base OnApplyTemplate for the Template to be applied, but inherited types might be relying on it for their implementations.	Same.
Visuals first available	In OnApplyTemplate. Use GetTemplateChild.	Same.
MeasureOverride called	In the Measure pass of layout. If the Template was expanded during this Measure pass, MeasureOverride will be called after the Template has been expanded.	Same.
ArrangeOverride called	In the Arrange pass of layout, which occurs after the Measure pass.	Same.
SizeChanged event	After the Measure and Arrange passes have completed.	Same.
LayoutUpdated event	After SizeChanged events have fired.	Same.

Layout Events - SizeChanged and LayoutUpdated

Dave Relyea — Tue, 27 May 2008 17:20:00 GMT

Executive Summary: Most of the time, SizeChanged is the right event to use, and LayoutUpdated is the wrong event.

The Silverlight 2 layout system offers two events: SizeChanged and LayoutUpdated. They look the same...here is how they are hooked up in C#:

public Page()

{

InitializeComponent();

LayoutRoot.SizeChanged += LayoutRoot_SizeChanged;

LayoutRoot.LayoutUpdated += LayoutRoot_LayoutUpdated;

}

The handlers are a bit different, though. Note that the LayoutUpdated event just has a standard EventArgs, while the SizeChanged event has the SizeChangedEventArgs, which very helpfully contains the old and new sizes.

void LayoutRoot_LayoutUpdated(object sender, EventArgs e)

{

}

private void LayoutRoot_SizeChanged(object sender, SizeChangedEventArgs e)

{

}

So far, they look pretty much the same, except for the additional information provided by the SizeChanged event. But this is not the case.

SizeChanged

The SizeChanged event is an "instance event" that is raised whenever the size of the element you have attached the handler to has changed. Note that if the position of the element on the screen changes, but not its size, this event does not get raised.

LayoutUpdated

The LayoutUpdated event is a "static event" that is fired every time layout had anything to do anywhere in the tree. You may find that it is getting fired much more often than you thought it would be. That's the reason why.

Sequence of events

The two events are also raised at different times. Here is roughly the way that the layout loop works:

while any element needs to be measured or arranged
{
    while any element needs to be measured
    {
        measure everything that needs measuring
    }

    while anything element needs to be arranged and no element needs to be measured
    {
        arrange everything that needs to be arranged
    }

    if any element needs to be measured or arranged
    {
        continue
    }

    if there are any SizeChanged events to raise
    {
        raise the SizeChanged events
    }

    if any element needs to be measured or arranged
    {
        continue
    }

    if layout did anything
    {
        raise the LayoutUpdated event
    }
}

Layout keeps looping until there was nothing for it to do or until the cycle detection kicks in. This means that you can change properties that affect layout in the SizeChanged and LayoutUpdated event handlers. In fact, it is kind of assumed that you'll be doing that in your SizeChanged handlers. The LayoutUpdated event fires when the layout system thinks it is all finished. I used it for my Snapper element only because I needed to be notified when the Snapper moved, not just when it changed size, and there is no other way to get that information.

Example

Here's an example of an app the handles the SizeChanged and LayoutUpdated events.

Don't forget to modify the x:Class to match your app.

<UserControl x:Class="LayoutEvents.Page"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">

<Grid.RowDefinitions>

</Grid.RowDefinitions>

</StackPanel>

</Grid>

</UserControl>

...and here's the code. Don't forget to make sure that the namespace matches the XAML.

using System;

using System.Windows;

using System.Windows.Controls;

namespace LayoutEvents

{

public partial class Page : UserControl

{

public Page()

{

InitializeComponent();

LayoutRoot.SizeChanged += LayoutRoot_SizeChanged;

LayoutRoot.LayoutUpdated += LayoutRoot_LayoutUpdated;

}

void LayoutRoot_LayoutUpdated(object sender, EventArgs e)

{

if (!updating)

{

updating = true;

++layoutUpdated;

UpdateCaption();

}

else

updating = false;

}

private void LayoutRoot_SizeChanged(object sender, SizeChangedEventArgs e)

{

caption.Visibility = (e.NewSize.Width < 300 || e.NewSize.Height < 300) ? Visibility.Collapsed : Visibility.Visible;

if (!updating)

{

++sizeChanged;

UpdateCaption();

}

private void ButtonAdd_Click(object sender, RoutedEventArgs e)

{

buttonPanel.Width += 10;

}

private void ButtonSubtract_Click(object sender, RoutedEventArgs e)

{

buttonPanel.Width -= 10;

}

private void UpdateCaption()

{

caption.Text = "LayoutUpdated: " + layoutUpdated + " SizeChanged: " + sizeChanged;

}

int layoutUpdated, sizeChanged;

bool updating;

}

You will see that the caption area only appears when the browser is large enough. By resizing the browser (assuming that your HTML page autosizes the Silverlight plugin to be fill the page) you can see both events being raised. But when you click on the Buttons, you will notice that the LayoutUpdated event is raised, even though you attached the handler to the LayoutRoot and the LayoutRoot has not changed at all.

DevDave - Dave Relyea's Silverlight Blog : SizeChanged

Control Lifecycle

Layout Events - SizeChanged and LayoutUpdated