WPF ViewModel Commandes CanExecute problème

Je vais avoir quelques difficultés avec les commandes de Menu Contextuel sur mon Modèle de Vue.

Je suis la mise en œuvre de l'interface ICommand pour chaque commande dans le Modèle de Vue, puis la création d'un ContextMenu dans le cadre des ressources de la Vue (MainWindow), et à l'aide d'un CommandReference de la MVVMToolkit pour accéder au DataContext (ViewModel) Commandes.

Quand je debug de l'application, il apparaît que la méthode CanExecute sur la commande n'est pas appelé, sauf à la création de la fenêtre, donc mon Contexte MenuItems ne sont pas activées ou désactivées je me serais attendu.

J'ai concocté un exemple simple (ci-joint) qui est indicatif de mon application effective et résumées ci-dessous. Toute aide serait grandement appréciée!

C'est le ViewModel

namespace WpfCommandTest
{
    public class MainWindowViewModel
    {
        private List<string> data = new List<string>{ "One", "Two", "Three" };

        //This is to simplify this example - normally we would link to
        //Domain Model properties
        public List<string> TestData
        {
            get { return data; }
            set { data = value; }
        }

        //Bound Property for listview
        public string SelectedItem { get; set; }

        //Command to execute
        public ICommand DisplayValue { get; private set; }

        public MainWindowViewModel()
        {
            DisplayValue = new DisplayValueCommand(this);
        }

    }
}

La DisplayValueCommand est telle:

public class DisplayValueCommand : ICommand
{
    private MainWindowViewModel viewModel;

    public DisplayValueCommand(MainWindowViewModel viewModel)
    {
        this.viewModel = viewModel;
    }

    #region ICommand Members

    public bool CanExecute(object parameter)
    {
        if (viewModel.SelectedItem != null)
        {
            return viewModel.SelectedItem.Length == 3;
        }
        else return false;
    }

    public event EventHandler CanExecuteChanged;

    public void Execute(object parameter)
    {
        MessageBox.Show(viewModel.SelectedItem);
    }

    #endregion
}

Et enfin, la vue est définie dans le code Xaml:

<Window x:Class="WpfCommandTest.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:WpfCommandTest"
    xmlns:mvvmtk="clr-namespace:MVVMToolkit"
    Title="Window1" Height="300" Width="300">

    <Window.Resources>

        <mvvmtk:CommandReference x:Key="showMessageCommandReference" Command="{Binding DisplayValue}" />

        <ContextMenu x:Key="listContextMenu">
            <MenuItem Header="Show MessageBox" Command="{StaticResource showMessageCommandReference}"/>
        </ContextMenu>

    </Window.Resources>

    <Window.DataContext>
        <local:MainWindowViewModel />
    </Window.DataContext>

    <Grid>
        <ListBox ItemsSource="{Binding TestData}" ContextMenu="{StaticResource listContextMenu}" 
                 SelectedItem="{Binding SelectedItem}" />
    </Grid>
</Window>

bonnes choses... j'ai été à la recherche comment faire cela aujourd'hui! +1

OriginalL'auteur LiamV | 2010-04-06

21

Remplir réponse, voici un "standard" de la mise en œuvre de la CanExecuteChanged événement :
```
public event EventHandler CanExecuteChanged
{
    add { CommandManager.RequerySuggested += value; }
    remove { CommandManager.RequerySuggested -= value; }
}
```
(à partir de Josh Smith RelayCommand classe)

Par le chemin, vous devriez probablement envisager d'utiliser RelayCommand ou DelegateCommand : vous allez vite fatigué de la création de nouvelles classes de commandes pour chaque commande de vous Viewmodel...

OriginalL'auteur Thomas Levesque
4

Vous devez garder trace du moment où le statut de CanExecute a changé et le feu de la ICommand.Événement CanExecuteChanged.

Également, vous trouverez peut-être que ça ne fonctionne pas toujours, et dans ces cas, un appel à CommandManager.InvalidateRequerySuggested() est nécessaire pour lancer la commande gestionnaire dans le cul.

Si vous trouvez que cela prend trop de temps, découvrez la réponse à cette question.

OriginalL'auteur Will

Je vous remercie pour la rapidité des réponses. Cette approche ne fonctionnera que si vous lient les commandes d'un Bouton standard dans la Fenêtre (qui a accès à la Vue du Modèle par l'intermédiaire de son DataContext), par exemple; CanExecute est montré pour être appelé assez fréquemment lors de l'utilisation du Gestionnaire de commandes comme vous le suggérez, sur ICommand la mise en œuvre de classes ou à l'aide de RelayCommand et DelegateCommand.

Cependant, la liaison de la même commandes via un CommandReference dans le ContextMenu
ne pas agir de la même manière.

Pour le même comportement, je dois aussi mentionner le Gestionnaire de Josh Smith RelayCommand, comme dans CommandReference, mais en le faisant, donc, je dois commenter un peu de code à partir de l'intérieur de la OnCommandChanged Méthode. Je ne suis pas entièrement sûr de savoir pourquoi il est là, c'est peut-être prévenir les cas de fuites de mémoire (à l'suppose!)?

  public class CommandReference : Freezable, ICommand
{
public CommandReference()
{
//Blank
}
public static readonly DependencyProperty CommandProperty = DependencyProperty.Register("Command", typeof(ICommand), typeof(CommandReference), new PropertyMetadata(new PropertyChangedCallback(OnCommandChanged)));
public ICommand Command
{
get { return (ICommand)GetValue(CommandProperty); }
set { SetValue(CommandProperty, value); }
}
#region ICommand Members
public bool CanExecute(object parameter)
{
if (Command != null)
return Command.CanExecute(parameter);
return false;
}
public void Execute(object parameter)
{
Command.Execute(parameter);
}
public event EventHandler CanExecuteChanged
{
add { CommandManager.RequerySuggested += value; }
remove { CommandManager.RequerySuggested -= value; }
}
private static void OnCommandChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
CommandReference commandReference = d as CommandReference;
ICommand oldCommand = e.OldValue as ICommand;
ICommand newCommand = e.NewValue as ICommand;
//if (oldCommand != null)
//{
//   oldCommand.CanExecuteChanged -= commandReference.CanExecuteChanged;
//}
//if (newCommand != null)
//{
//   newCommand.CanExecuteChanged += commandReference.CanExecuteChanged;
//}
}
#endregion
#region Freezable
protected override Freezable CreateInstanceCore()
{
throw new NotImplementedException();
}
#endregion
}

Merci de voir ma réponse

OriginalL'auteur LiamV

1

Cependant, la liaison de la même commandes via un CommandReference dans le
ContextMenu n'agissent pas de la même manière.

Que c'est un bug dans CommandReference mise en œuvre. Il résulte de ces deux points:
1. Il est recommandé que la mise en œuvre de ICommand.CanExecuteChanged détenir que des références faibles pour les gestionnaires (voir cette réponse).
2. Consommateurs de ICommand.CanExecuteChanged doit s'attendre (1) et doivent donc détenir de solides références pour les gestionnaires de leur inscription ICommand.CanExecuteChanged
Le commun des implémentations de RelayCommand et DelegateCommand respecter (1). Le CommandReference mise en œuvre n'est pas respecter (2) lorsqu'il s'abonne à newCommand.CanExecuteChanged. De sorte que le gestionnaire d'objet est collecté et après que CommandReference n'est plus reçoit toutes les notifications qu'il comptait sur.

Le correctif est de maintenir une forte ref pour le gestionnaire dans CommandReference:
```
    private EventHandler _commandCanExecuteChangedHandler;
public event EventHandler CanExecuteChanged;
...
if (oldCommand != null)
{
oldCommand.CanExecuteChanged -= commandReference._commandCanExecuteChangedHandler;
}
if (newCommand != null)
{
commandReference._commandCanExecuteChangedHandler = commandReference.Command_CanExecuteChanged;
newCommand.CanExecuteChanged += commandReference._commandCanExecuteChangedHandler;
}
...
private void Command_CanExecuteChanged(object sender, EventArgs e)
{
if (CanExecuteChanged != null)
CanExecuteChanged(this, e);
}
```
Pour le même comportement, je dois aussi mentionner le Gestionnaire d'événements
de Josh Smith RelayCommand, comme dans CommandReference, mais en le faisant
donc, je dois commenter un peu de code à partir de l'intérieur de la OnCommandChanged
La méthode. Je ne suis pas entièrement sûr de savoir pourquoi il est là, c'est peut-être
la prévention des cas de fuites de mémoire (à l'suppose!)?

Noter que votre approche de transfert d'abonnement pour le Gestionnaire de commandes.RequerySuggested élimine également le bug (il n'y a plus non référencées gestionnaire pour commencer), mais c'est un handicap pour la CommandReference fonctionnalité. La commande à laquelle CommandReference est associé est libre de poser CanExecuteChanged directement (au lieu de compter sur le Gestionnaire de commandes à l'émission d'un requery demande), mais cet événement serait d'ingestion et de ne jamais atteindre la source de la commande lié à la CommandReference. Cela devrait également répondre à votre question de savoir pourquoi CommandReference est mis en œuvre en vous abonnant à newCommand.CanExecuteChanged.

Mise à JOUR: soumis une question sur CodePlex

merci, cela a résolu mon problème

OriginalL'auteur alexei
1

Une solution plus facile pour moi, a été de définir le CommandTarget sur le MenuItem.
```
<MenuItem Header="Cut" Command="Cut" CommandTarget="
{Binding Path=PlacementTarget, 
RelativeSource={RelativeSource FindAncestor, 
AncestorType={x:Type ContextMenu}}}"/>
```
Plus d'infos: http://www.wpftutorial.net/RoutedCommandsInContextMenu.html

OriginalL'auteur Bendik August Nesbø

Vous devez vous connecter pour publier un commentaire.