Question

Download repro project

Edit

The solution working sometimes completely threw me off my initial wondering why this is working in the first place. After all, the items aren’t part of the Visual tree. In the end, it makes total sense:

• The buttons in that collection aren’t in the visual tree and thus element bindings don’t work.
• Applying the templates puts them into the visual tree and binding, if applied at this time, start working.
• This confirms the suspected race condition.

A colleague of mine did some extended debugging that showed the issue as well – in the cases the binding succeeded, OnApplyBinding was invoked first. So using the collection without adjusting the logical tree was simply flawed.

Thanks for the replies that put back on the right track!

---

Original Post

I have a view control that exposes an ObservableCollection, My view can contain arbitrary elements, e.g. buttons. Note the ElementName binding on the button:

<local:ViperView>    
    <local:ViperView.MenuItems>
        <Button Content="{Binding ElementName=btn, Path=Content}" />
    </local:ViperView.MenuItems>

    <Grid>
        <Button x:Name="btn" Content="HELLO WORLD" />
    </Grid>
</local:ViperView>

The control’s ControlTemplate just renders the content using an ItemsControl:

<ControlTemplate ...
...

    <ItemsControl
        x:Name="PART_NavigationMenuItemsHost"
        ItemsSource="{Binding MenuItems, RelativeSource={RelativeSource TemplatedParent}}" />
 </ControlTemplate>

The view above is assigned to the ActiveView property of my main view model. The main window just displays the view via data binding.

Now the problem: The ElementName binding within that view doesn’t work reliably if the view is not immediately assigned to the view model after it’s creation.

ElementName bindings work like this:

MainViewModel.ActiveView = new ViperView();

ElementName bindings works sometimes using normal priority:

var view = new ViperView();
Dispatcher.BeginInvoke(() => MainViewModel.ActiveView  view);

ElementName binding always fails if the view model property is set with low priority:

var view = new ViperView();
Dispatcher.BeginInvoke(DispatcherPriority.Render, () => MainViewModel.ActiveView = view);

ElementName binding sometimes works if the property is set from a worker thread (Binding engine marshalls back to the UI thread):

var view = new ViperView();
Task.Factory.StartNew(() => MainViewModel.ActiveView = view);

ElementName binding always fails if the worker thread has a delay:

var view = new ViperView();
var view = new ViperView();
Task.Factory.StartNew(() => 
{
    Thread.Sleep(100);
    MainViewModel.ActiveView = view;
});

I don’t have an answer to this. It appears to be related to timings. For example, if I add a short Thread.Sleep to the Task sample above, this always causes the bindings to break, while without the sleep, it only sometimes breaks.

This is quite the show stopper for me – any pointer are appreciated…

Thanks for your advice
Philipp

Answer 1

Given that the ElementName binding in part fails before the buttons in the sample are even added to the collection of the parent view, there’s not much I can do to intercept the bindings. A slightly dirty workaround would be to just refresh the bindings in those controls once the template has been applied and the visual tree established:

Fron OnApplyTemplate, invoke:

internal static class BindingUtil
{
    /// <summary>
    /// Recursively resets all ElementName bindings on the submitted object
    /// and its children.
    /// </summary>
    public static void ResetElementNameBindings(this DependencyObject obj)
    {
        IEnumerable boundProperties = obj.GetDataBoundProperties();
        foreach (DependencyProperty dp in boundProperties)
        {
            Binding binding = BindingOperations.GetBinding(obj, dp);
            if (binding != null && !String.IsNullOrEmpty(binding.ElementName)) //binding itself should never be null, but anyway
            {
                //just updating source and/or target doesn’t do the trick – reset the binding
                BindingOperations.ClearBinding(obj, dp);
                BindingOperations.SetBinding(obj, dp, binding);
            }
        }

        int count = VisualTreeHelper.GetChildrenCount(obj);
        for (int i = 0; i < count; i++)
        {
            //process child items recursively
            DependencyObject childObject = VisualTreeHelper.GetChild(obj, i);
            ResetElementNameBindings(childObject);
        }
    }


    public static IEnumerable GetDataBoundProperties(this DependencyObject element)
    {
        LocalValueEnumerator lve = element.GetLocalValueEnumerator();

        while (lve.MoveNext())
        {
            LocalValueEntry entry = lve.Current;
            if (BindingOperations.IsDataBound(element, entry.Property))
            {
                yield return entry.Property;
            }
        }
    }
}

Another fix, and probably preferable, would be to change the logical tree at runtime. Adding the code below to my view solves the issue, too:

public class ViperView : ContentControl
{
    private readonly ObservableCollection<object> menuItems = new ObservableCollection<object>();

    public ObservableCollection<object> NavigationMenuItems
    {
        get { return menuItems; }
    }


    public ViperView()
    {
        NavigationMenuItems.CollectionChanged += OnMenuItemsChanged;
    }

    private void OnMenuItemsChanged(object sender, NotifyCollectionChangedEventArgs e)
    {
        if (e.NewItems != null)
        {
            foreach (var newItem in e.NewItems)
            {
                AddLogicalChild(newItem);
            }
        }
    }

    protected override IEnumerator LogicalChildren
    {
        get
        {
            yield return this.Content;
            foreach (var mi in NavigationMenuItems)
            {
                yield return mi;
            }
        }
    }
}