Why does LayoutUpdated pass a null sender?

Because it does not mean what you think it means.

As Dave Relyea explains, LayoutUpdated is fired every time layout did anything in the tree so it’s not specific to a particular object, and you can’t use the sender to tell you what you’re interested in.

What you need is the SizeChanged event. LayoutUpdated is going to get fired an awful lot, while SizeChanged gets fired when the object you’re interested in has its size changed. It won’t get fired if the position of the object changes, but that’s probably what you want most of the time.

My particular code had a UserControl in a popup, and the UserControl had a variable size. I wanted it to always remain on screen, intelligently positioning itself so that it’s fully on screen (like a menu would) but when it’s first created (and indeed, laid out) its actual size is {0,0} because (I believe) that it hasn’t been added to the visual tree yet because the parent Popup is closed. I needed to wait until the size of the object was fully calculated before I positioned the popup, and I thought LayoutUpdated would do the trick, so I had some code like this:

void infoPane_LayoutUpdated(object sender, EventArgs e)
WalkInfoPane pane = sender as WalkInfoPane;
if (pane != null && pane.ActualHeight > 0 && pane.ActualWidth > 0)
Point anchor = PopupAnchor.TransformToVisual(null).Transform(new Point());
if (anchor.Y < 240) { PanePopup.VerticalOffset = -240 + (240 - anchor.Y); } else { PanePopup.VerticalOffset = -240; } pane.MakeVisible(); } } [/sourcecode] (PanePopup is the parent Popup. I was expecting the sender to point at the child control, but it gives null.) Not surprisingly, this code was never getting called because sender is always null. Using the same code in a SizeChanged event works perfectly. It's a shame MSDN doesn't cover details like this.



  1. “It’s a shame MSDN doesn’t cover details like this.”

    My bad …

    This was a little detail of implementation that I didn’t pick up on originally, it was not mentioned anywhere in the development specs I use as basis for documenting the API. But even so, there was a WPF implementation, which I also documented at the time (2006), and … also failed to pick up on the null sender issue and its reasons for existence and note it in the Remarks. So, double my bad.

    On the bright side, Dave Relyea’s blog, your post here, and the wonders of the internets have led me to this issue post-fact, and I will be adding some cogent remarks for the Silverlight 3 release of the documentation. Happy days.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s