ElementName Binding from MenuItem in ContextMenu

Question

Has anybody else noticed that Bindings with ElementName do not resolve correctly for MenuItem objects that are contained within ContextMenu objects? Check out this sample:

<Window x:Class="EmptyWPF.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300"
    x:Name="window">
    <Grid x:Name="grid" Background="Wheat">
        <Grid.ContextMenu>
            <ContextMenu x:Name="menu">
                <MenuItem x:Name="menuItem" Header="Window" Tag="{Binding ElementName=window}" Click="MenuItem_Click"/>
                <MenuItem Header="Grid" Tag="{Binding ElementName=grid}" Click="MenuItem_Click"/>
                <MenuItem Header="Menu" Tag="{Binding ElementName=menu}" Click="MenuItem_Click"/>
                <MenuItem Header="Menu Item" Tag="{Binding ElementName=menuItem}" Click="MenuItem_Click"/>
            </ContextMenu>
        </Grid.ContextMenu>
        <Button Content="Menu" 
                HorizontalAlignment="Center" VerticalAlignment="Center" 
                Click="MenuItem_Click" Tag="{Binding ElementName=menu}"/>
        <Menu HorizontalAlignment="Center" VerticalAlignment="Bottom">
            <MenuItem x:Name="anotherMenuItem" Header="Window" Tag="{Binding ElementName=window}" Click="MenuItem_Click"/>
            <MenuItem Header="Grid" Tag="{Binding ElementName=grid}" Click="MenuItem_Click"/>
            <MenuItem Header="Menu" Tag="{Binding ElementName=menu}" Click="MenuItem_Click"/>
            <MenuItem Header="Menu Item" Tag="{Binding ElementName=anotherMenuItem}" Click="MenuItem_Click"/>
        </Menu>
    </Grid>
</Window>

All of the bindings work great except for the bindings contained within the ContextMenu. They print an error to the Output window during runtime.

Any one know of any work arounds? What's going on here?

Ratoon

The problem obviously has something to do with namescopes... – Ratoon

Do ContextMenus define their own namescope by default? – Ratoon

Answer 1

I found a much simpler solution.

In the code behind for the UserControl:

NameScope.SetNameScope(contextMenu, NameScope.GetNameScope(this));

Ratoon

It works in 4.5 too. Amazing solution, works very well. Thanks. – Murrain

Works for 4.5.2 too. Take care... It fix the binding using "ElementName" but it does not fix the binding using "RelativeSource FindAncestor". – Vagrancy

Source={x:Reference Name=Root} from Marc answer is much better BTW because its don't need code behind and may be used in resource dictionaries – Idiolect

Answer 2

As said by others, the 'ContextMenu' is not contained in the visual tree and an 'ElementName' binding won't work. Setting the context menu's 'NameScope' as suggested by the accepted answer only works if the context menu is not defined in a 'DataTemplate'. I have solved this by using the {x:Reference} Markup-Extension which is similar to the 'ElementName' binding but resolves the binding differently, bypassing the visual tree. I consider this to be far more readable than using 'PlacementTarget'. Here is an example:

<Image Source="{Binding Image}">       
    <Image.ContextMenu>
        <ContextMenu>
            <MenuItem Header="Delete" 
                      Command="{Binding Source={x:Reference Name=Root}, Path=DataContext.RemoveImage}"
                      CommandParameter="{Binding}" />
        </ContextMenu>
    </Image.ContextMenu>
</Image>

According to the MSDN-documentation

x:Reference is a construct defined in XAML 2009. In WPF, you can use XAML 2009 features, but only for XAML that is not WPF markup-compiled. Markup-compiled XAML and the BAML form of XAML do not currently support the XAML 2009 language keywords and features.

whatever that means... Works for me, though.

Galloway

Simple, elegant and works at first try : this should marked as the solution (really better than PlacementTarget) – Firth

That quote from the MSDN documentation seems to indicate to me that using x:Reference does not allow Visual Studio (or whatever compiles XAML) to compile the XAML into a binary form. I wonder what the performance hit is. – Contexture

Impressive, it worked for me ;). Probably the easiest and elegant solution ! – Untenable

If you have your ContextMenu inside a resources-block, the designer throws with an "XamlParseException: Unresolved reference 'Root'". Running the program works, tho. – Janeejaneen

If the Root object is a parent of the MenuItem this fails at runtime with an error "Cannot call MarkupExtension.ProvideValue because of a cyclical dependency." – Adjuvant

Answer 3

Here's another xaml-only workaround. (This also assumes you want what's inside the DataContext, e.g., you're MVVMing it)

Option one, where the parent element of the ContextMenu is not in a DataTemplate:

Command="{Binding PlacementTarget.DataContext.MyCommand, 
         RelativeSource={RelativeSource AncestorType=ContextMenu}}"

This would work for OP's question. This won't work if you are inside of a DataTemplate. In these cases, the DataContext is often one of many in a collection, and the ICommand you wish to bind to is a sibling property of the collection within the same ViewModel (the DataContext of the Window, say).

In these cases, you can take advantage of the Tag to temporarily hold the parent DataContext which contains both the collection AND your ICommand:

class ViewModel
{
    public ObservableCollection<Derp> Derps { get;set;}
    public ICommand DeleteDerp {get; set;}
} 

and in the xaml

<!-- ItemsSource binds to Derps in the DataContext -->
<StackPanel
    Tag="{Binding DataContext, ElementName=root}">
    <StackPanel.ContextMenu>
        <ContextMenu>
            <MenuItem
                Header="Derp"                       
                Command="{Binding PlacementTarget.Tag.DeleteDerp, 
                RelativeSource={RelativeSource 
                                    AncestorType=ContextMenu}}"
                CommandParameter="{Binding PlacementTarget.DataContext, 
                RelativeSource={RelativeSource AncestorType=ContextMenu}}">
            </MenuItem>

Quiet

I think the relevant point that you are making here is that you can use tags and relative source bindings to get at data in another place in the visual tree. – Ratoon

This isn't really related to MVVM. I only use ElementName bindings when I'm trying to tie two view related controls together outside of the VM. This is a good solution for binding context menu items to commands on a VM. A good alternative is to use a routed command that ties into the VM. A good example of this is Josh Smith's CommandSink class. – Ratoon

the trick with Tag is good! It works, and doesn't drive VS2022 XAML designer crazy (as the approach with Binding Source={x:Reference Name=Root}) – Substitution

Answer 4

Context menus are tricky to bind against. They exist outside the visual tree of your control, hence they can't find your element name.

Try setting the datacontext of your context menu to its placement target. You have to use RelativeSource.

<ContextMenu 
   DataContext="{Binding PlacementTarget, RelativeSource={RelativeSource Self}}"> ...

Ellata

Setting the DataContext to the PlacementTarget would effect ElementName bindings? I think the DataContext is only used for Bindings that have no Source, RelativeSource, or ElementName property set. – Ratoon

Setting an ElementName property will only work if the layout manager can find the associated element by navigating up the visual tree. Context menus do not exist inside the visual tree of the control to which they are added. You must set the datacontext of the context menu so the layout manager can navigate up the visual tree of its placement target to find the associated element. – Ellata

Adding the DataContext to the above example didn't fix the problem. I still got the following error in the Output window: "System.Windows.Data Error: 4 : Cannot find source for binding with reference 'ElementName=window'. BindingExpression:(no path); DataItem=null; target element is 'MenuItem' (Name='menuItem'); target property is 'Tag' (type 'Object')" – Ratoon

hmmm...looking back over my code I have only done this by setting the relative source directly in the binding, I thought setting the DataContext would be simpler. Here is what worked for me: CommandTarget="{Binding PlacementTarget, RelativeSource={RelativeSource FindAncestor, AncestorType={x:Type ContextMenu}}}" The syntax will obviously be different, but perhaps setting the source attribute of your binding to the placement target will work? – Ellata

OK, that makes sense now. You are changing the ElementName reference to a RelativeSource reference through the ContextMenu. Thanks for the thoughts. – Ratoon

Answer 5

After experimenting a bit, I discovered one work around:

Make top level Window/UserControl implement INameScope and set NameScope of ContextMenu to the top level control.

public class Window1 : Window, INameScope
{
    public Window1()
    {
        InitializeComponent();
        NameScope.SetNameScope(contextMenu, this);
    }

    // Event handlers and etc...

    // Implement INameScope similar to this:
    #region INameScope Members

    Dictionary<string, object> items = new Dictionary<string, object>();

    object INameScope.FindName(string name)
    {
        return items[name];
    }

    void INameScope.RegisterName(string name, object scopedElement)
    {
        items.Add(name, scopedElement);
    }

    void INameScope.UnregisterName(string name)
    {
        items.Remove(name);
    }

    #endregion
}

This allows the context menu to find named items inside of the Window. Any other options?

Ratoon

Answer 6

I'm not sure why resort to magic tricks just to avoid a one line of code inside the eventhandler for the mouse click you already handle:

    private void MenuItem_Click(object sender, System.Windows.RoutedEventArgs e)
    {
        // this would be your tag - whatever control can be put as string intot he tag
        UIElement elm = Window.GetWindow(sender as MenuItem).FindName("whatever control") as UIElement;
    }

Casket

Doing it this way doesn't allow the menu item to become disabled automatically according to the bound command though. So while it works for execution, you would have to add more code to also disable/enable the menu item accordingly when it's loaded. Not that this is bad, it just brings back bad memories of WinFoms UI code spaghetti for lots of people. – Galactometer