ColorPicker has Null Reference for SampleSelector variable in Loaded event handler

Aug 29, 2011 at 9:21 PM


I'm using build 69623 (version 1.4.6) and noticed that I always get a NullReferenceException in the Loaded event handler when using the ColorPicker.

This happens in two different scenarios that I tried:

  1. When the control is placed on the page with an initial visibility set to "Collapsed" (thereby forgoing the call to OnApplyTemplate)
  2. When the control is placed on the page with an initial visibility of "Visible"
    • In this scenario, the call to OnApplyTemplate does indeed occur before the Loaded event fires. 
    • As expected, at the end of the OnApplyTemplate call, the SampleSelector variable is set to an instance of Grid (as defined in Generic.xaml).  However, by the time the Loaded event handler runs, the SampleSelector variable is null once again.

As a quick fix I found that I could get around the problem by adding a call to ApplyTemplate() at the start of the Loaded event handler.  Not sure why this is necessary--or if this is an indication of a bug elsewhere--I haven't dug deeply enough into the code to find out.

Any thoughts?



Aug 30, 2011 at 4:49 PM

I found some interesting info related to this on MSDN (caveat: for Silverlight in general, not specifically WP7)

Here's an excerpt from

The timing of the Loaded event in Silverlight differs from the timing of the FrameworkElement.Loaded event in WPF. Specifically, the WPF Loaded event occurs after the template is applied. In Silverlight, the Loaded event is not guaranteed to occur after the template is applied. This might be an issue for you if you are using the Loaded event for a relatively common control scenario: you want to examine the visual tree, either to get a value as a source for something else or to change a value in the templated composition where you can know the new value only at run time. In this case, calls to the Silverlight VisualTreeHelper methods to examine the visual tree of the template content might not work if you make them directly from a Loaded handler.

There are several ways to work around this issue. Each has merits as well as possible limitations:

  • If you are deriving from an existing control, instead of adding handling for Loaded, you can override OnApplyTemplateOnApplyTemplate is specifically intended as the callback for this situation, where you have a tree from the template and now you want to examine or adjust the visuals. A limitation is that if you are just using an existing control as part of your application, you cannot change anything about OnApplyTemplate.

  • You can still continue to use Loaded. However, as the very first call in your Loaded handler, call ApplyTemplate on that control. ApplyTemplate is a synchronous method, so once you make that call and it returns, your template-created visual tree is now present. Calling ApplyTemplate in this case does not duplicate effort on the part of the Silverlight runtime. A limitation is that your element of concern does need to be a Control derived class.

  • You can handle LayoutUpdated instead of LoadedLayoutUpdated is the last "object lifetime" event in the sequence of enabling a control in Silverlight UI. The main limitation of LayoutUpdated is that the initialization is possibly not the only time that LayoutUpdated is raised. Also,LayoutUpdated is raised for objects that are involved in a layout change. For instance, a peer in layout might have changed its size. In terms of visual trees, even the peer object may have changed only a few property values and not the tree structure, and the visual tree of the object that you are handling LayoutUpdated on might not have changed at all. Therefore, you might have to apply your own logic to determine whether aLayoutUpdated event really means that you need to examine or reexamine a visual tree.

Note that there are scenarios for handling Loaded that are not affected by the timing issues of template application. For instance, you can still add event handlers or set properties for the object where Loaded is raised, even if you cannot yet access the template parts. For instance, you can create objects in code and add them into content properties or content collections at this time, or add input-type event handlers that you chose not to hook up in the initial XAML.


Aug 31, 2011 at 6:39 PM

can you log this as a bug and provide a repo for each scenario?  Thanks.  want to be sure I'm addressing each issue.

Sep 1, 2011 at 9:27 PM

No problem man.  I can completely relate.  :-)

I'm trying to push out a new beta build of YouVersion for WP7 to our testers ASAP, so I probably won't get to it until this weekend.

Thanks for the reply!