I have a custom command and I try to execute them from the context menu, but they are always displayed as disabled unless I click any button on the UI (buttons do not have anything to do with commands).
After clicking a button, commands start to be displayed correctly (when they are unavailable they get disabled and enabled if available).
Edit: it turns out that it is not the button click which makes command work correctly, but button or other controls in focus (e.g. if I tab into a control this also enables my commands).
Here is the code for commands:
<Window.InputBindings>
<KeyBinding Command="{x:Static local:MainWindow.Quit}" Key="Q" Modifiers="Ctrl"/>
<KeyBinding Command="{x:Static local:MainWindow.Disconnect}" Key="D" Modifiers="Ctrl"/>
</Window.InputBindings>
<Window.ContextMenu>
<ContextMenu Opacity="95">
<MenuItem Header="Quit Application Ctrl + Q" Command="{x:Static local:MainWindow.Quit}"/>
<MenuItem Header="Disconnect from the pump Ctrl + D" Command="{x:Static local:MainWindow.Disconnect}"/>
</ContextMenu>
</Window.ContextMenu>
Here is the commands CanExecuteMethod:
public static RoutedCommand Quit = new RoutedCommand();
private void QuitCanExecute(object sender, CanExecuteRoutedEventArgs e)
{
e.CanExecute = true;
e.Handled = true;
}
This issue is due to the ContextMenu being on a separate Visual and Logical Tree to that of the Window and its Controls.
For anyone still looking for an answer to this issue - After trawling the internet I have found the most effective answer to be to include the following in any declaration of a MenuItem that needs its commands to be heard by it's "owner".
In layman's terms; if you want the commands of your context menu to be heard by the thing you're right clicking on. Add this code:
CommandTarget="{Binding Path=PlacementTarget,
RelativeSource={RelativeSource AncestorType=ContextMenu}
}"
Example:
<ContextMenu>
<MenuItem Header="Close" Command="Application.Close"
CommandTarget="{Binding Path=PlacementTarget, RelativeSource={RelativeSource AncestorType=ContextMenu}}" />
</ContextMenu>
This will also work within Templates (something I found a lot of another solutions not to support). Here is an explanation of the meaning of the statement taken from elsewhere (I'm appalling at explaining things):
Every FrameworkElement has a DataContext that is an arbitrary object. The default source for a data binding is that DataContext. You can use RelativeSource.Self to change the source for a binding to the FrameworkElement itself instead of its DataContext. So the RelativeSource part just moves you "up one level" from the DataContext of the FrameworkElement to the FrameworkElement itself. Once you are at the FrameworkElement you can specify a path to any of its properties. If the FrameworkElement is a Popup, it will have a PlacementTarget property that is the other FrameworkElement that the Popup is positioned relative to.
In short, if you have a Popup placed relative to a TextBox for example, that expression sets the DataContext of the Popup to the TextBox and as a result {Binding Text} somewhere in the body of the Popup would bind to the text of the TextBox.
I honestly hope that this information saves someone who's new to WPF the headache I've gone through this weekend... though it did teach me a lot!
Completely different track, now:
there is indeed something special about the ContextMenu as the carrier for commands:
the menu is not regarded as part of the window and therefore does not behave like an element in its visual tree would.
There are different solutions for your problems defined here:
http://www.wpftutorial.net/RoutedCommandsInContextMenu.html
The easiest approach seems to be adding this to your XAML (for the window):
FocusManager.FocusedElement="{Binding RelativeSource={x:Static RelativeSource.Self}, Mode=OneTime}"
I just ran into this while trying to implement a custom context menu for AvalonDock. None of the solutions suggested above worked for me.
I got the context menu working by explicitly registering my command handlers on the ContextMenu class in addition to the main widow. The function below is a helper I used for command registration.
void RegisterCmd(RoutedCommand command, ExecutedRoutedEventHandler handler, CanExecuteRoutedEventHandler canExecute)
{
var binding = new CommandBinding(command, handler, canExecute);
this.CommandBindings.Add(binding);
CommandManager.RegisterClassCommandBinding(typeof(ContextMenu), binding);
}
There is probably some change "behind the scenes" that would normally enable the commands, but the view is not aware of this change.
One would need to see the Command-implementations to give more precise hints.
You can either make anything that changes your command-enable-state notify the view or manually trigger a command-refresh via CommandManager.InvalidateRequerySuggested(), for example when the context-menu opens.
WPF ICommands work that way; they requery their CanExecute function whenever something in the view changes (e.g. PropertyChanged-event is fired or a button is clicked), but they don't requery if they have no reason to.
This is a known bug. If there is no focused element in the window's main focus scope, the CanExecute routing will stop at the ContextMenu, so it will not reach to the CommandBinding on the Window, one workaround is to bind MenuItem's CommandTarget to the main window, as following code demonstrates:
<Window.ContextMenu>
<ContextMenu >
<ContextMenu.Items>
<MenuItem Command="ApplicationCommands.Open"
CommandTarget="{Binding Path=PlacementTarget,RelativeSource={RelativeSource AncestorType={x:Type ContextMenu}}}"/>
</ContextMenu.Items>
</ContextMenu>
</Window.ContextMenu>
Related
I have read some thread about how to work on WPF ListView command binding.
Passing a parameter using RelayCommand defined in the ViewModel
Binding Button click to a method
Button Command in WPF MVVM Model
How to bind buttons in ListView DataTemplate to Commands in ViewModel?
All of them suggest write the logic code inside ViewModel class, for example:
public RelayCommand ACommandWithAParameter
{
get
{
if (_aCommandWithAParameter == null)
{
_aCommandWithAParameter = new RelayCommand(
param => this.CommandWithAParameter("Apple")
);
}
return _aCommandWithAParameter;
}
}
public void CommandWithAParameter(String aParameter)
{
String theParameter = aParameter;
}
It is good practice or anyway so I can move the CommandWithAParameter() out of the ViewModel?
In principle, MVVM application should be able to run to its full potential without creating the views. That's impossible, if some parts of your logic are in View classes.
On top of that, ICommand has CanExecute, which will autamagically disable buttons, menu items etc. if the command should not be run.
I understand why with basic RelayCommand implementation it can be hard to see the benefits, but take a look at ReactiveCommand samples.
ReactiveCommand handles async work very well, even disabling the button for the time work is done and enabling it afterwards.
Short example: you have a login form. You want to disable the login button if the username and password are empty.
Using commands, you just set CanExecute to false and it's done.
Using events, you have manualy disable/enable the button, remember that it has to be done in Dispatcher thread and so on - it gets very messy if you have 5 buttons depending on different properties.
As for ListView, commands are also usefull - you can bind current item as command parameter:
<ListView ItemsSource="{Binding MyObjects}">
<ListView.ItemTemplate>
<DataTemplate>
<DockPanel>
<!-- change the context to parent ViewModel and pass current element to the command -->
<Button DockPanel.Dock="Right" Command="{Binding ElementName=Root, Path=ViewModel.Delete}" CommandParameter="{Binding}">Delete</Button>
<TextBlock Text="{Binding Name}"/>
</DockPanel>
</DataTemplate>
</ListView.ItemTemplate>
</ListView>
To simplify the issue I'm having, consider this hypothetical scenario.
In the XAML for my control, I have defined a TreeView and two fixed root TreeViewItem nodes, 'AItemsNode' and 'BItemsNode'. In its ViewModel, I expose two child collections: AItems and BItems. I then bind each root node's ItemsSource property to the respective collection on the ViewModel. This works great and displays exactly what I want.
Now what I'd like to do is add a CommandBinding for ApplicationCommands.Open to the child TreeViewItem nodes of the two root nodes. Specifically I want the children under the root 'AItemsNode' to have their 'Open' CommandBinding point to 'OpenAItem_Executed' and children of the second root node to point theirs at 'OpenBItem_Executed'.
The issue I'm having is I don't know how to set the CommandBindings on the TreeViewItem objects themselves. I can't figure this out at all via XAML, and if I were to do it in the code-behind, I'd have to integrate with the ItemContainerGenerator, inspect what's being generated and add the bindings, essentially writing so much code I may as well add the 'Open' CommandBinding to the TreeView itself and inspect the SelectedObject and go from there. Not optimal as I now have a single Open_Executed handler that delegates all over the place based on data type, but it does work!
Still, I'm hoping someone can show me how to add a CommandBinding directly to a generated TreeViewItem to avoid that and segregate out the code much more cleanly.
So... how can one apply specific CommandBindings via a style (or any other way in XAML) for a TreeViewItem?
Implemented mvvm, I would suggest using interaction triggers.
Hope this helps you in the right direction.
Xaml:
xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity"
<TreeView >
<TreeView.Resources>
<DataTemplate x:Key="ItemATemplate">
<TextBlock Text="{Binding MyNodeTitle}">
<i:Interaction.Triggers>
<i:EventTrigger EventName="PreviewMouseDown">
<i:InvokeCommandAction Command="{Binding AChildCommand}" CommandParameter="{Binding}"/>
</i:EventTrigger>
</i:Interaction.Triggers>
</TextBlock>
</DataTemplate>
<DataTemplate x:Key="ItemBTemplate">
<TextBlock Text="{Binding MyNodeTitle}">
<i:Interaction.Triggers>
<i:EventTrigger EventName="PreviewMouseDown">
<i:InvokeCommandAction Command="{Binding BChildCommand}" CommandParameter="{Binding}"/>
</i:EventTrigger>
</i:Interaction.Triggers>
</TextBlock>
</DataTemplate>
</TreeView.Resources>
<TreeView.Items>
<TreeViewItem Header="AItemRootNode" ItemsSource="{Binding SomeAStuff}" ItemTemplate="{StaticResource ItemATemplate}"/>
<TreeViewItem Header="BItemRootNode" ItemsSource="{Binding SomeBStuff}" ItemTemplate="{StaticResource ItemBTemplate}"/>
</TreeView.Items>
</TreeView>
ViewModel:
private ICommand _aChildCommand;
public ICommand AChildCommand
{
get
{
if (_aChildCommand == null)
_aChildCommand = new DelegateCommand(OnAChild);
return _aChildCommand;
}
}
private void OnAChild(object obj)
{
}
I take that you havent implemented MVVM (which would have intuitively solved this issue for you by making use of RelayCommands / DelegateCommands instead of RoutedCommands)
However in your case, you need to handle the Initialized event of TreeViewItem via Style targetted to TreeViewItem. Use EventSetter in the Style. And put your code that adds the CommandBinding to the e.OriginalSource value (which is the TreeViewItem itself that is getting initialized) incoming to the TreeViewItem.Initialized event handler.
Let me know if this makses sense.
EDIT
I understand that your have x number keyborad shortcuts for x number of distinct TreeViewItems. If so x number of styles make sense to me.
But if you want to do this cluttered in a single handler at the tree view level, then may be you would have to handle an attached event at that level ... I dont think Initialised / Loaded events bubble from indv treeviewitem all the way to the parent tree view, but it would be interesting to check that and I would be happy to have proved wrong!
Plus this would potentially not work for collapsed tree view items.
So suppose you define "Ctrl + o" shortcut for a specific tree view item which is within a collapsed tree branch or is it in the opened branch however it is outside the scroll view, the routed event based mechanisms (and thus command bindings) woudnt work because they need the item to be devirtualised (in UI memory) for routing to work ...
So my solution (as I understand now) becomes a little impractical in that case.
Solution
What is visible all the time?
TreeView!
So use that to your advantage. Add all command bindings (and shortcuts) to the TreeView itself!
And within the handler (which could be common across all command bindings) devise a mechanism to identify the individual item using a ItemsSource of TreeViewItemViewModels by searching within them and then inside the relevant TreeViewItemViewModel have mechanism to Open the branch hierarchy by Binding IsOpen property (INotifyable) to the IsExpanded property of the TreeViewItem via a generic style.
I have a UserControl with some InputBindings. I wanted to make one of the input bindings (arrow key press) execute a command on a GUI control in my UserControl . So
e.g.
<UserControl.InputBindings>
<KeyBinding Key="Up" Command="{Binding ElementName=MyViewElement, Path=MoveUpCommand}"/>
<KeyBinding Key="Down" Command="{Binding ElementName=MyViewElement, Path=MoveDownCommand}"/>
</UserControl.InputBindings>
But, this fails because MyViewElement is not found because I assume it is declared later in the XAML. If I move my InputBindings to the end of the XAML file everything works as intended.
I kinda prefer my InputBindings to be at the top, is it possible to make it ignore the declaration order?
#Stewbob What are you talking about?
Take a look at this: http://msdn.microsoft.com/en-us/library/ms752308.aspx
<Window.CommandBindings>
<CommandBinding Command="ApplicationCommands.Open"
Executed="OpenCmdExecuted"
CanExecute="OpenCmdCanExecute"/>
</Window.CommandBindings>
According to what you said this should never work properly but it does:
<StackPanel>
<Menu>
<MenuItem Command="ApplicationCommands.Paste"
CommandTarget="{Binding ElementName=mainTextBox}" />
</Menu>
<TextBox Name="mainTextBox"/>
</StackPanel>
From what you said the binding comes first also it will be executed first and therefore the binding to mainTextBox should never work. Thats very not true.
Sure you can do everything in XAML, including such Binding at Window level. Show more code of your XAML/MyViewElement. Maybe we could tell you how to do it without errors. Also post your error here please.
But, this fails because MyViewElement is not found because I assume it is declared later in the XAML.
To avoid that, you can use the following in the code behind instead of the constructor:
protected override void OnInitialized(EventArgs e)
{
SomeCommand = new DelegateCommand(SomeExecuteMethod);
InitializeComponent();
base.OnInitialized(e);
}
This ensures the commands are already instantiated before you use them with:
Command="{Binding ElementName=MyUserCOntrol, Path=SomeCommand}"
I have a WPF/MVVM app with a ListBox which displays data through a DataTemplate. I managed to change the selected item in the ListBox when pressing a button so the CommandParameter is linked to the ListBox's SelectedItem, but I cannot get the buttons to be enabled/disabled correctly in the same way. For example, if I have 2 items and the button should be enabled in one and disabled in the other, when I select an element BOTH buttons have the same state, and they BOTH change state when I select another item.
I am using a RelayCommand as used in many MVVM Frameworks.
Here is my XAML (removed "not interesting" parts):
<UserControl.Resources>
<DataTemplate x:Key="ItemTemplate">
<Grid>
<Button Content="Something" Name="EnabledDisabledButton" Click="Button_Click"
Command="{Binding RelativeSource={RelativeSource AncestorType={x:Type UserControl}}, Path=DataContext.SomeCommand}"
CommandParameter="{Binding RelativeSource={RelativeSource AncestorType={x:Type ListBox}}, Path=SelectedItem}"/>
</Grid>
</DataTemplate>
<Style TargetType="{x:Type ListBoxItem}" x:Key="ContainerStyle">
<Setter Property="ContentTemplate" Value="{StaticResource ItemTemplate}" />
</Style>
</UserControl.Resources>
<ListBox x:Name="myListBox" ItemsSource="{Binding ElementList}"
IsSynchronizedWithCurrentItem="True" ItemContainerStyle="{StaticResource ContainerStyle}"/>
I tried to pass the SelectedItem as a parameter to the RelayCommand's CanExecute method, but the result was the same as before.
Is there a way to pass the actual ListBoxItem in which the button "lives in" as a parameter to the command, so each one will be processed separately by the CanExecute method? Would it work if I got this? (right now I am handling the Click event to select the correct item in the list before executing the command).
In my CanExecute method I am evaluating some property of the SelectedItem in order to enable/disable the corresponding button. An alternative would be to evaluate this property for all elements, but I cannot think of a way to do it inside the ViewModel, and then communicate to the view the result (if it is even possible while using a DataTemplate for the items).
Thanks for your input, regards!
Converting My comment into an answer:
Why not just CommandParameter="{Binding}"?
You mention "MVVM" in the question, but it seems you use the MVVM way to your full advantage.
I would not have a Button_Click event in the style at all. That is because it is in fact a style, which per definition could be changed to another style which does not have the same event, which again will make the application stop working as wanted if you choose to have a style-based app in the future.
A rule I use is that a style is a style. A style has to do with the UI and "looks" of the app.
Functionality should be separate from the UI. The programmer can define the Command, and the designer can decide how the user will use that in the best way.
That's exactly where the code separation from the MVVM pattern cames into grip.
To separate the "looks" and user behavior and the app's logic.
Like...it should not matter to the model if a command fires from a button, a menu, a datacontext or a key stroke.
If this particular problem was handled to ME, I would solve it by having a HOLDER-class.
This is a class (DependencyObject which implements INotifyPropertyChanged) that holds a ICommand property as well as the "row" that will be displayed in the various rows in the ListBox.
The ICommand property will be bound to the Button, having the row (class) itself as CommandParameter to the call.
Then the actual row would be used in the ItemTemplate on the ListBox, with Bindings to different elements (proprty with or withouy Converters) to make whatever desired display available.
I hope I explained good enough...
Feel free to ask more if you want more details to my solution alternative.
I'm attempting to use a Command, defined in my view model with EventTriggers as defined in xmlns:i="http://schemas.microsoft.com/expression/2010/interactivity"
I have changed the control from a Microsoft.Surface.Presentation.Controls.SurfaceSlider-derived control to a regular WPF Button. With the Button, the same ConfirmOrderCommand gets fired if I use the EventName="MouseEnter", but if I use EventName="Click" nothing happens. The XAML for the Button is here.
<Button Name="ConfirmButton"
IsEnabled="{Binding IsEnabled}"
Style="{StaticResource ConfirmButtonStyle}"
>
<i:Interaction.Triggers>
<i:EventTrigger EventName="Click">
<i:InvokeCommandAction Command="{Binding ConfirmOrderCommand}"/>
</i:EventTrigger>
</i:Interaction.Triggers>
</Button>
I want the user to be able to click the button to fire the command. Can I get the Click event to work for a Button, or do I need to look for another event? I've also failed to get MouseLeftButtonUp to work.
Try EventName="Button.Click". Anyways, you can just set the Command Property of the Button itself, and remove the Interaction.Triggers part.
The actual reason the Button.Click would not work, was determined after much pain and finally asking someone on the project after he woke up in the morning.
Our application was stealing almost all of the Button events with FrameworkElement Preview delegates.
public static void RegisterEvents(FrameworkElement parent)
{
parent.PreviewMouseDown += MouseDown;
parent.PreviewMouseUp += MouseUp;
// even more of these
}
The delegates would then use System.Window.Input.TouchDevice to ReportDown() in the case of MouseDown etc. All this time I just thought I didn't know how the standard WPF button usually works. I guess the moral of this story is events don't have to start at the child control and then propagate up to their containers until Handled = true. Preview allows the container to capture the events first.