Grundlagen - Commands

    • WPF

    Es gibt 2 Antworten in diesem Thema. Der letzte Beitrag () ist von LaMiy.

      Grundlagen - Commands

      Hallo Community,

      in diesem Tutorial möchte ich euch die grundlegenden Konzepte von Commands in WPF näher bringen. Ich werde hier alle Erklärungen ausschließlich im Zusammenhang mit dem MVVM-Pattern (Model-View-ViewModel-Pattern) liefern, das Tutorial setzt daher Kenntnisse über dieses Pattern voraus (dies schließt die nötigen XAML-Kenntnisse mit ein).


      Was sind Commands und wofür brauche ich sie?

      Ein Großteil der WPF-Anwärter stammt aus dem Bereich der Vorgängertechnologie WindowsForms, welches Eventbasiert funktioniert. Es ist daher nicht verwunderlich, dass häufig die Codes von Anfängern in dem Gebiet WPF nach dem selben Prinzip funktionieren - und man kann es ihnen auch nicht verübeln, denn sie kennen es ja nicht anders.
      So findet man dann z.B. dergleichen Codes vor:

      XML-Quellcode

      1. <Button x:Name="Button1" Click="Button1_OnClick"/>

      Und der Eventhandler befindet sich logischerweise im Codebehind des Windows, ganz wie unter WindowsForms:

      C#

      C#-Quellcode

      1. public partial class MainWindow : Window
      2. {
      3. void Button1_OnClick(object sender, RoutedEventArgs e)
      4. {
      5. //some code here
      6. }
      7. }
      VB.Net

      VB.NET-Quellcode

      1. Class MainWindow
      3. Private Sub Button1_OnClick(ByVal sender As Object, ByVal e As RoutedEventArgs)
      4. 'some code here
      5. End Sub
      6. End Class

      Warum genau ist das jetzt schlecht?
      Events im Windows-Forms-Sinne sind mit dem MVVM-Pattern, welches in WPF eigentlich Pflicht ist, nicht oder nur schwer vereinbar. Grund ist, dass sich die Logik der Anwendung im ViewModel des Windows befindet, nicht im COdebehind der Window-Klasse. Man kann natürlich tricksen und die Events irgendwie an das ViewModel weiterleiten, aber das erfordert weiteren Code im Codebehind, der dort ebensowenig was zu suchen hat wie die Eventhandler. Sinn von MVVM ist es nämlich, dass im Codebehind nur Code steht, der wirklich nur das View (die Benutzeroberfläche) betrifft, Verknüfungen an das ViewModel sollten ausschließlich über Bindings erfolgen, und die legt man am einfachsten im XAML-Code an.

      Aber wie werden Events denn dann gebunden?
      Die Antwort ist: gar nicht, genau hier kommen unsere Commands in Spiel, die die Events an dieser Stelle ersetzen werden. Commands in WPF basieren auf dem ICommand-Interface und stellen eine Instanz da, die eine Benutzereingabe zu der entsprechen auzuführenden Aktion delegiert. Wichtig dabei ist, dass das Ziel des Commands vom Command allein verwaltet wird, das Steuerelement, welches das Command ausführt, muss davon nichts wissen. Dadurch können wir uns von den Handlern in der Window-Klasse verabschieden und alles ins ViewModel verlagern, wos hingehört. Zusätzlich können Commands dem View mitteilen, ob sie überhaupt ausgeführt werden können, die Steuerelemente können darauf entsprechend (z.B. mit Ausgrauung) reagieren.


      Relay-Commands

      Die simpelste Art von Commands sind die Relay-Commands. Sie tun nichts weiter als eine ihnen (über einen Delegaten) zugewiesene Aktion auszuführen.
      Leider existiert in der Standard-WPF-Klassenbibliothek keine universelle RelayCommand-Klasse, diese gibts nur mit TeamFoundation. Damit man sich aber sparen kann, für jedes Command eine neue Klasse zu implementieren, kann man sich einfach diese relativ simple Klasse selbst bauen. Die hier präsentierte Version stammt von mir und ist selbstverständlich nicht zwangsläufig das Nonplusultra.

      C#

      C#-Quellcode

      1. class RelayCommand : ICommand
      2. {
      3. readonly Action methodToExecute;
      4. readonly Func<bool> canExecuteEvaluator;
      6. public event EventHandler CanExecuteChanged
      7. {
      8. add { CommandManager.RequerySuggested += value; }
      9. remove { CommandManager.RequerySuggested -= value; }
      10. }
      12. public RelayCommand(Action methodToExecute, Func<bool> canExecuteEvaluator)
      13. {
      14. this.methodToExecute = methodToExecute;
      15. this.canExecuteEvaluator = canExecuteEvaluator;
      16. }
      18. public RelayCommand(Action methodToExecute)
      19. : this(methodToExecute, () => true)
      20. { }
      22. public bool CanExecute(object parameter)
      23. {
      24. return canExecuteEvaluator.Invoke();
      25. }
      27. public void Execute(object parameter)
      28. {
      29. methodToExecute.Invoke();
      30. }
      31. }
      VB.Net

      VB.NET-Quellcode

      1. Class RelayCommand : Implements ICommand
      2. Private ReadOnly _methodToExecute As Action
      3. Private ReadOnly _canExecuteEvaluator As Func(Of Boolean)
      5. Public Custom Event CanExecuteChanged As EventHandler Implements ICommand.CanExecuteChanged
      6. AddHandler(value As EventHandler)
      7. AddHandler CommandManager.RequerySuggested, value
      8. End AddHandler
      10. RemoveHandler(value As EventHandler)
      11. RemoveHandler CommandManager.RequerySuggested, value
      12. End RemoveHandler
      14. RaiseEvent(sender As Object, e As EventArgs)
      15. End RaiseEvent
      16. End Event
      18. Public Sub New(methodToExecute As Action, canExecuteEvaluator As Func(Of Boolean))
      19. _methodToExecute = methodToExecute
      20. _canExecuteEvaluator = canExecuteEvaluator
      21. End Sub
      23. Public Sub New(methodToExecute As Action)
      24. Me.New(methodToExecute, Function() True)
      25. End Sub
      27. Public Function CanExecute(parameter As Object) As Boolean Implements ICommand.CanExecute
      28. Return _canExecuteEvaluator.Invoke()
      29. End Function
      31. Public Sub Execute(parameter As Object) Implements ICommand.Execute
      32. _methodToExecute.Invoke()
      33. End Sub
      34. End Class

      Bemerkenswert an dieser Klasse ist, dass sie selbst erkennt, wann sich der Rückgabewert des canExecuteEvaluators ändert, ihr müsst also nicht erst das Event manuell auslösen. Dahinter steckt der CommandManager, dessen Magie ich selbst nicht erklären kann, aber es funktioniert.

      Mit Hilfe des RelayCommand können wir jetzt das schlechte Beispiel von weiter oben korrigieren. Wir statten das ViewModel mit dem Command für den Button als Eigenschaft aus, damit wir daran binden können. Im Konstruktor können wir dann das RelayCommand erstellen und die auzuführende Funktion auswählen sowie optional eine Ausführungsbedingung.

      C#

      C#-Quellcode

      1. class MainViewModel : NotifyPropertyChangedBase
      2. {
      3. static MainViewModel instance;
      5. public static MainViewModel Instance
      6. {
      7. get { return instance ?? (instance = new MainViewModel()); }
      8. }
      10. public ICommand ButtonCommand { get; private set; }
      12. private MainViewModel()
      13. {
      14. ButtonCommand = new RelayCommand(ButtonClicked, CanClickButton);
      15. }
      17. private bool CanClickButton()
      18. {
      19. return true;
      20. }
      22. private void ButtonClicked()
      23. {
      24. //some code here
      25. }
      26. }
      VB.Net

      VB.NET-Quellcode

      1. Class MainViewModel : Inherits NotifyPropertyChangedBase
      2. Private Shared _instance As MainViewModel
      4. Public Shared ReadOnly Property Instance As MainViewModel
      5. Get
      6. If (_instance Is Nothing) Then _instance = New MainViewModel()
      7. Return _instance
      8. End Get
      9. End Property
      11. Private _buttonCommand As ICommand
      13. Public Property ButtonCommand As ICommand
      14. Get
      15. Return _buttonCommand
      16. End Get
      17. Private Set(value As ICommand)
      18. _buttonCommand = value
      19. End Set
      20. End Property
      22. Private Sub New()
      23. ButtonCommand = New RelayCommand(AddressOf ButtonClicked, AddressOf CanClickButton)
      24. End Sub
      26. Private Function CanClickButton() As Boolean
      27. Return True
      28. End Function
      30. Private Sub ButtonClicked()
      31. 'some code here
      32. End Sub
      33. End Class

      Im XAML können wir dann die ButtonCommand-Eigenschaft an die Command-Eigenschaft des Buttons binden, sofern das ViewModel korrekt als DataContext festgelegt wurde. Die Namensgebung für den Button wird hier auch redundant, ein Zeichen, dass wir auf dem richtigen Weg sind, in WPF und MVVM benötigen die wenigsten Steuerelemente einen Namen.

      XML-Quellcode

      1. <Button Command="{Binding ButtonCommand}"/>



      Routed-Commands

      Manchmal möchte man Commands nicht an das ViewModel sondern an bestimmte Controls senden, zum Beispiel um einer Textbox mitzuteilen, sie solle ihren Inhalt in die Zwischenablage kopieren. Im Gegensatz zum RelayCommand existiert in der WPF-Klassenbibliothek bereits eine RoutedCommand-Klasse, die wir verwenden können.
      Routed-Commands sind statisch und können von mehreren Steuerelementen empfangen werden (welches Steuerelement dann tatsälich das Command ausführt, wird durch den VisualTree bestimmt, dazu später mehr). Einige Standard-Commands sind in der statischen ApplicationCommands-Klasse vordefiniert, die auch teilweise von den Standard-Stuerelementen bereits behandelt werden (z.B. reagiert die Textbox auf ApplicationCommands.Copy). Im Gegensatz zu den Relay-Commands bestimmt bei den Routed-Commands das Empfängersteuerelement das Verhalten des Commands, dies geschieht über sog. Commandbindings, die direkt im XAML des Steuerelements oder im Codebehind definiert werden können. Wenn also einem bestehenden Steuerelement ein Commandbinding hinzugefügt werden soll, muss eine abgeleitete Klasse implementiert werden, bei Usercontrols sind XAML und Codebehind ohnehin schon vorhanden.
      Der Einfachheit halber habe ich hier ein Commandbinding am MainWindow eingerichtet, da wir uns so die Erstellung eines Usercontrols oder eines abgeleiteten Controls sparen können. Die Erstellung erfolgt hier im XAML und gebunden wir das Copy-Command aus den ApplicationCommands.

      XML-Quellcode

      1. <Window.CommandBindings>
      2. <CommandBinding Command="Copy" CanExecute="CanCopy" Executed="ExecuteCopy"/>
      3. </Window.CommandBindings>

      Die Methoden CanCopy und ExecuteCopy befinden sich im Codebehind des MainWindow. Bedenkt, dass damit nur Code dort hin gehört, der das Steuerelement (also in dem Fall das MainWindow) betrifft, solltet ihr das Geühl haben, der Code gehöre ins ViewModel, ist ein RoutedCommand die falsche Wahl und ihr solltet ein RelayCommand verwenden.
      Beachtet auch, dass hier die Kurzform für das Copy-Command verwendet wurde, äquivalent dazu wäre diese Schreibweise:

      XML-Quellcode

      1. <Window.CommandBindings>
      2. <CommandBinding Command="{x:Static ApplicationCommands.Copy}" CanExecute="CanCopy" Executed="ExecuteCopy"/>
      3. </Window.CommandBindings>

      Das Codebehind des MainWindow sieht nun so aus:

      C#

      C#-Quellcode

      1. public partial class MainWindow : Window
      2. {
      3. private void CanCopy(object sender, CanExecuteRoutedEventArgs e)
      4. {
      5. e.ContinueRouting = false;
      6. e.CanExecute = true;
      7. }
      9. private void ExecuteCopy(object sender, ExecutedRoutedEventArgs e)
      10. {
      11. //some code here
      12. }
      13. }
      VB.Net

      VB.NET-Quellcode

      1. Class MainWindow
      3. Private Sub CanCopy(sender As Object, e As CanExecuteRoutedEventArgs)
      4. e.ContinueRouting = False
      5. e.CanExecute = True
      6. End Sub
      8. Private Sub ExecuteCopy(sender As Object, e As ExecutedRoutedEventArgs)
      9. 'some code here
      10. End Sub
      11. End Class

      Interessant ist der Inhalt der CanCopy-Methode. e.CanExecute entspricht hier dem Rückgabewert des canExecuteEvaluator aus dem RelayCommand, gibt also an, ob das Command ausgeführt werden kann. e.ContinueRoutung setze ich hier zur Demonstration auf false, obwohl dies eigentlich nicht nötig ist (Standardwert ist false). Wird dieser Wert jedoch auf true gesetzt, wird das CommandBinding für das Steuerelement an das entsprechende Command ignoriert, sodass andere Steuerelemente das Command empfangen können (auch dazu später mehr).

      Das Copy-Command muss jetzt auch irgendwo ausgelöst werden, damit etwas passieren kann. Ich verwende hier wieder einen normalen Button:

      XML-Quellcode

      1. <Button Command="Copy"/>

      Sobald der Button jetzt gedrückt wird, wandert das Routed-Command den Baum der Steuerelemente nach oben, bis ein Steuerelement gefunden wird, welches das Command per CommandBinding gebunden hat und e.ContinueRouting false ist. Dort wird dann das Command ausgeführt und die Executed-Funktion aufgerufen.
      Sollte kein Steuerelement gefunden worden sein und das RoutedCommand erreicht das Ende des Baumes, wird das Command ignoriert.

      Eigene Routed-Commands erstellen
      Ihr könnte selbstverständlich auch eigene Routed-Commands erstellen und auf diese reagieren.
      Das RoutedCommand muss öffentlich und statisch vorliegen, an welcher Stelle ist egal, ich verwende für dieses Beispiel eine neue statische Klasse:

      C#

      C#-Quellcode

      1. static class Commands
      2. {
      3. static ICommand customRoutedCommand;
      4. public static ICommand CustomRoutedCommand
      5. {
      6. get { return customRoutedCommand ?? (customRoutedCommand = new RoutedCommand()); }
      7. }
      8. }
      VB.Net

      VB.NET-Quellcode

      1. Module Commands
      3. Private _customRoutedCommand As ICommand
      4. Public ReadOnly Property CustomRoutedCommand As ICommand
      5. Get
      6. If _customRoutedCommand Is Nothing Then _customRoutedCommand = New RoutedCommand()
      7. Return _customRoutedCommand
      8. End Get
      9. End Property
      10. End Module

      Alles, was wir tun müssen, um unser eigenes RoutedCommand statt einem vorgefertigten zu nutzen, ist, es im XAML auszutauschen:

      XML-Quellcode

      1. <Window.CommandBindings>
      2. <CommandBinding Command="local:Commands.CustomRoutedCommand" CanExecute="CanExecuteCustomCommand" Executed="ExecuteCustomCommand"/>
      3. </Window.CommandBindings>
      5. <Button Command="local:Commands.CustomRoutedCommand"/>



      Command-Gruppen

      Es kommt vor, dass ein einzelnes Steuerelement mehrere Commands ausführen soll und mit der CommandGroup-Klasse wird dies möglich. Leider existiert auch diese Klasse ausschlißlich unter TeamFoundation, aber auch hier können wir uns mit einer eigenen Implementierung Abhilfe schaffen:

      C#

      C#-Quellcode

      1. [ContentProperty("Commands")]
      2. class CommandGroup : ICommand
      3. {
      4. public event EventHandler CanExecuteChanged;
      6. readonly ObservableCollection<ICommand> commands;
      8. public ObservableCollection<ICommand> Commands
      9. {
      10. get { return commands; }
      11. }
      13. public CommandGroup()
      14. {
      15. commands = new ObservableCollection<ICommand>();
      16. commands.CollectionChanged += OnCommandsChanged;
      17. }
      19. protected virtual void OnCanExecuteChanged(EventArgs e)
      20. {
      21. if (CanExecuteChanged != null)
      22. CanExecuteChanged(this, e);
      23. }
      25. private void OnChildCanExecuteChanged(object sender, EventArgs e)
      26. {
      27. OnCanExecuteChanged(e);
      28. }
      30. protected virtual void OnCommandsChanged(object sender, NotifyCollectionChangedEventArgs e)
      31. {
      32. if (e.NewItems != null && e.NewItems.Count > 0)
      33. {
      34. foreach (ICommand command in e.NewItems)
      35. command.CanExecuteChanged += OnChildCanExecuteChanged;
      36. }
      38. if (e.OldItems != null && e.OldItems.Count > 0)
      39. {
      40. foreach (ICommand command in e.OldItems)
      41. command.CanExecuteChanged -= OnChildCanExecuteChanged;
      42. }
      44. OnCanExecuteChanged(EventArgs.Empty);
      45. }
      47. public bool CanExecute(object parameter)
      48. {
      49. return commands.All(command => command.CanExecute(parameter));
      50. }
      52. public void Execute(object parameter)
      53. {
      54. foreach (ICommand command in commands)
      55. command.Execute(parameter);
      56. }
      57. }
      VB.Net

      VB.NET-Quellcode

      1. <ContentProperty("Commands")>
      2. Class CommandGroup : Implements ICommand
      3. Public Event CanExecuteChanged As EventHandler Implements ICommand.CanExecuteChanged
      5. ReadOnly _commands As ObservableCollection(Of ICommand)
      7. Public ReadOnly Property Commands As ObservableCollection(Of ICommand)
      8. Get
      9. Return _commands
      10. End Get
      11. End Property
      13. Public Sub New()
      14. _commands = New ObservableCollection(Of ICommand)()
      15. AddHandler _commands.CollectionChanged, AddressOf OnCommandsChanged
      16. End Sub
      18. Protected Overridable Sub OnCanExecuteChanged(e As EventArgs)
      19. RaiseEvent CanExecuteChanged(Me, e)
      20. End Sub
      22. Private Sub OnChildCanExecuteChanged(sender As Object, e As EventArgs)
      23. OnCanExecuteChanged(e)
      24. End Sub
      26. Protected Overridable Sub OnCommandsChanged(sender As Object, e As NotifyCollectionChangedEventArgs)
      27. If e.NewItems IsNot Nothing AndAlso e.NewItems.Count > 0 Then
      28. For Each command As ICommand In e.NewItems
      29. AddHandler command.CanExecuteChanged, AddressOf OnChildCanExecuteChanged
      30. Next
      31. End If
      33. If e.OldItems IsNot Nothing AndAlso e.OldItems.Count > 0 Then
      34. For Each command As ICommand In e.NewItems
      35. RemoveHandler command.CanExecuteChanged, AddressOf OnChildCanExecuteChanged
      36. Next
      37. End If
      39. OnCanExecuteChanged(EventArgs.Empty)
      40. End Sub
      42. Public Function CanExecute(parameter As Object) As Boolean Implements ICommand.CanExecute
      43. Return _commands.All(Function(command) command.CanExecute(parameter))
      44. End Function
      46. Public Sub Execute(parameter As Object) Implements ICommand.Execute
      47. For Each command As ICommand In _commands
      48. command.Execute(parameter)
      49. Next
      50. End Sub
      51. End Class

      Was hier geschieht mag auf den ersten Blick kompliziert wirken, aber eigentlich werden hier nur mehrere Commands in einer Liste gespeichert, das CanExecuteChanged-Event durchgeleitet und in Execute alle Commands ausgeführt.
      Ich habe die Klasse so designt, dass man bei Bedarf auch davon ableiten kann.

      Sollen nur RoutedCommands in eine CommandGroup gesteckt werden, können wir diese gleich im XAML definieren:

      XML-Quellcode

      1. <Button>
      2. <Button.Command>
      3. <local:CommandGroup>
      4. <x:StaticExtension Member="ApplicationCommands.Copy"/>
      5. <x:StaticExtension Member="local:Commands.CustomRoutedCommand"/>
      6. </local:CommandGroup>
      7. </Button.Command>
      8. </Button>

      Sollen auch RelayCommands mit enthalten sein oder soll die Liste im Laufe der Programmausführung geändert werden, kommen wir nicht darum herum, die CommandGroup im ViewModel zu erstellen:

      C#

      C#-Quellcode

      1. class MainViewModel : NotifyPropertyChangedBase
      2. {
      3. static MainViewModel instance;
      5. public static MainViewModel Instance
      6. {
      7. get { return instance ?? (instance = new MainViewModel()); }
      8. }
      10. public ICommand ButtonCommand { get; private set; }
      12. public ICommand CommandGroup { get; private set; }
      14. private MainViewModel()
      15. {
      16. ButtonCommand = new RelayCommand(ButtonClicked, CanClickButton);
      17. var commandGroup = new CommandGroup();
      18. commandGroup.Commands.Add(ButtonCommand);
      19. commandGroup.Commands.Add(ApplicationCommands.Copy);
      20. commandGroup.Commands.Add(Commands.CustomRoutedCommand);
      21. CommandGroup = commandGroup;
      22. }
      24. private bool CanClickButton()
      25. {
      26. return true;
      27. }
      29. private void ButtonClicked()
      30. {
      31. Debug.Print("Relay command executed!");
      32. }
      33. }
      VB.Net

      VB.NET-Quellcode

      1. Class MainViewModel : Inherits NotifyPropertyChangedBase
      2. Private Shared _instance As MainViewModel
      4. Public Shared ReadOnly Property Instance As MainViewModel
      5. Get
      6. If (_instance Is Nothing) Then _instance = New MainViewModel()
      7. Return _instance
      8. End Get
      9. End Property
      11. Private _buttonCommand As ICommand
      12. Private _commandGroup As ICommand
      14. Public Property ButtonCommand As ICommand
      15. Get
      16. Return _buttonCommand
      17. End Get
      18. Private Set(value As ICommand)
      19. _buttonCommand = value
      20. End Set
      21. End Property
      23. Public Property CommandGroup As ICommand
      24. Get
      25. Return _commandGroup
      26. End Get
      27. Private Set(value As ICommand)
      28. _commandGroup = value
      29. End Set
      30. End Property
      32. Private Sub New()
      33. ButtonCommand = New RelayCommand(AddressOf ButtonClicked, AddressOf CanClickButton)
      34. Dim commandGroup = New CommandGroup()
      35. commandGroup.Commands.Add(ButtonCommand)
      36. commandGroup.Commands.Add(ApplicationCommands.Copy)
      37. commandGroup.Commands.Add(Commands.CustomRoutedCommand)
      38. Me.CommandGroup = commandGroup
      39. End Sub
      41. Private Function CanClickButton() As Boolean
      42. Return True
      43. End Function
      45. Private Sub ButtonClicked()
      46. Debug.Print("Relay command executed!")
      47. End Sub
      48. End Class

      Hier können wir dann wiederum ganz normal binden:

      XML-Quellcode

      1. <Button Command="{Binding CommandGroup}"/>



      Typische Anwendungen für Commands

      Buttons
      Buttons werden eigentlich immer mit einem Command verknüpft, ansonsten machen sie ja nicht sonderlich viel Sinn (zumindest aus funktionaler Sicht, aber was weiß ich schon, wofür ihr eure Buttons benutzt. :P ).
      Da oben bei allen Beispielen Buttons verwendet wurden, muss ich hier, glaube ich, nicht mehr viel erklären, die Syntax lautet:

      XML-Quellcode

      1. <Button Command="CommandXYZ"/>



      Menüitems
      Auch Menüitems sind gute Kandidaten für Commands, gerade New, Open, Save, Copy, Paste, Cut, Undo oder Redo sind häufig in Menüs zu finden und lassen sich gut mit Commands umsetzen.
      Die Syntax ist der vom Button nahezu identisch und ebenso simpel:

      XML-Quellcode

      1. <MenuItem Command="CommandXYZ"/>



      InputBinings
      Wenn Menüitems vorhanden sind möchte man diese üblicherweise auch mit Tastenkombinationen verbinden. Das geht in WPF mit den sog. InputBindings, welche ebenfalls auf Basis von Commands funktionieren, womit es dann kein Problem ist, ihnen einfach den selben Command zuzuordnen wie ihrem entsprechenden Menüitem.
      Hier sind z.B. einige Inputbindings für die Menüeinträge Neu, Öffnen und Speichern, wie man sie in Editoren aller Art findet:

      XML-Quellcode

      1. <Window.InputBindings>
      2. <KeyBinding Modifiers="Control" Key="N" Command="{Binding NewCommand}"/>
      3. <KeyBinding Modifiers="Control" Key="O" Command="{Binding OpenCommand}"/>
      4. <KeyBinding Modifiers="Control" Key="S" Command="{Binding SaveCommand}"/>
      5. </Window.InputBindings>

      Neben Tastatureingaben können auch Mauseingaben mit Hilfe von MouseBindings an Commands gebunden werden.




      Ich hoffe ich konnte euch mit diesem Tutorial einige hilfreiche Informationen vermitteln. Anbei findet ihr noch ein Beispielprojekt für C# und VB.Net, in dem ihr euch alles hier besprochene noch einmal ausprogrammiert ansehen könnt.
      Dateien

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Artentus“ ()

      Ich hab mal ein bischen praktische Beispiele dazu entwickelt, ursprünglich aufbauend auf einer Vorlage, die du mir gemailt hattest:
      Angezeigt wird eine Liste von Personen, und wenn man auf eine doppelklickt, dann öffnet sich ein Person-Editier-Dialog.
      Der PersonEditor öffnet sich auch, wenn man eine Person anwählt und Enter drückt.
      Auch gibts Buttons dafür, und auch einen Button zum Hinzufügen einer neuen Person.
      Und mit Strg-N erzeugt man auch eine neue Person. Und mit Delete natürlich löschen.
      Besonderes Schmankerl: Mit Alt-Q schließt die Anwendung.
      Der Person-Editier-Dialog wird mit Button oder Enter bestätigt, und mit Escape gecancelt.

      RelayCommands
      Also im MainViewmodel sind die RelayCommands cmdNew, cmdDelete, cmdEdit angelegt wie folgt:

      VB.NET-Quellcode

      1. Private __Persons As New ObservableCollection(Of Person)()
      2. Public Property Persons() As ICollectionView = CollectionViewSource.GetDefaultView(__Persons)
      4. Public Property cmdNew() As New RelayCommand(AddressOf CreateNewPerson)
      6. Public Property cmdDelete() As New RelayCommand( _
      7. Sub() __Persons.RemoveAt(Persons.CurrentPosition), _
      8. Function() Persons.CurrentPosition >= 0)
      10. Public Property cmdEdit() As New RelayCommand( _
      11. Sub() Call New wndPerson(__Persons(Persons.CurrentPosition)).ShowDialog(), _
      12. Function() Persons.CurrentPosition >= 0)
      14. Public Sub CreateNewPerson()
      15. Dim person = New Person("a Name", "-", DateTime.Now)
      16. Dim editor = New wndPerson(person)
      17. If CBool(editor.ShowDialog()) Then
      18. __Persons.Add(person)
      19. Persons.MoveCurrentToPosition(__Persons.Count - 1)
      20. End If
      21. End Sub
      Während das Editieren der Current-Person ein anonymer Einzeiler ist (#11), ist das Anlegen einer neuen Person bisserl aufwändiger, und daher in eine richtige Methode gepackt (#14 - #21), die mit AddressOf addressiert wird (#4).
      Die Command-Ausführbarkeits-Bedingung ist beim Löschen und Editieren die gleiche: Die Person-CollectionView muss eine gültige CurrentPosition haben (#8, #12)
      Hingegen cmdNew (#4) braucht keine solche Bedingung, denn Zufügen kann man immer.
      c#

      C#-Quellcode

      1. public ICollectionView Persons { get; private set; }
      2. private ObservableCollection<Person> _Persons = new ObservableCollection<Person>();
      4. public RelayCommand cmdNew { get; private set; }
      6. public RelayCommand cmdEdit { get; private set; }
      8. public RelayCommand cmdDelete { get; private set; }
      10. private MainViewModel() {
      11. Persons = CollectionViewSource.GetDefaultView(_Persons);
      12. cmdNew = new RelayCommand(CreateNewPerson);
      13. cmdEdit = new RelayCommand(
      14. () => new wndPerson(_Persons[Persons.CurrentPosition]).ShowDialog(),
      15. () => Persons.CurrentPosition >= 0);
      16. cmdDelete = new RelayCommand(
      17. () => _Persons.RemoveAt(Persons.CurrentPosition),
      18. () => Persons.CurrentPosition >= 0);
      19. //...
      20. }
      22. public void CreateNewPerson() {
      23. var person = new Person("a Name", "-", DateTime.Now);
      24. var editor = new wndPerson(person);
      25. if ((bool)editor.ShowDialog()) {
      26. _Persons.Add(person);
      27. Persons.MoveCurrentToPosition(_Persons.Count - 1);
      28. }
      29. }
      In c# kann man Properties nicht mit der Deklaration initialisieren, sondern muss Konstruktor-Code schreiben. Ist dafür bischen sauberer, denn so sind die Properties public readonly


      Bindings an RelayCommands
      Geradezu langweilig einfach sind Button-Bindings an RelayCommands:

      XML-Quellcode

      1. <Button Content="New Person" Margin="3" Command="{Binding cmdNew}"/>
      2. <Button Content="Edit Person" Margin="3" Command="{Binding cmdEdit}"/>
      3. <Button Content="Delete Person" Margin="3" Command="{Binding cmdDelete}"/>
      (Ebenso wäre es auch mit MenuItem gegangen)

      InputBindings an RelayCommands
      Ich habe auch ein paar KeyBindings erstellt, damit Tastendrücke auch was tun: Auf UserControl-Ebene verarbeite ich Strg-N und Strg-Q

      XML-Quellcode

      1. <UserControl x:Class="uclDatagrid" DataContext="{x:Static my:MainViewModel.Instance}" [...] >
      2. <UIElement.InputBindings>
      3. <KeyBinding Command="{Binding cmdNew}" Gesture="Ctrl + N" />
      4. <KeyBinding Command="Close" Gesture="Alt + Q" />
      5. </UIElement.InputBindings>
      Das bewirkt - egal wo im Ucl der Focus ist - drückt einer Strg-N, kommt der "neue Person"-Dialog.
      Das andere KeyBinding löst das vorgefertigte Application.Close-Command aus. Selbiges leite ich via CommandBinding um in ein Event, um das Fenster zu schließen.
      Also das Application.Close kommt im Viewmodel überhaupt nicht an - doch dazu später.

      Den Scope von InputBindings wählen
      Erstmal im DataGrid hab ich auch InputBindings definiert, die sollen aber nicht im ganzen UserControl wirken, sondern speziell nur auf dem ItemsPanel des Datagrids:

      XML-Quellcode

      1. <ItemsControl.ItemsPanel>
      2. <ItemsPanelTemplate>
      3. <StackPanel>
      4. <UIElement.InputBindings>
      5. <MouseBinding Command="{Binding cmdEdit}" Gesture="LeftDoubleClick" />
      6. <KeyBinding Command="{Binding cmdEdit}" Gesture="Enter" />
      7. </UIElement.InputBindings>
      8. </StackPanel>
      9. </ItemsPanelTemplate>
      10. </ItemsControl.ItemsPanel>
      Nämlich Key.Enter oder Mouse.LeftDoubleClick auf eine Person sollen auch den Editier-Vorgang auslösen. :thumbsup:

      Wpf nervt
      Ich habe denselben View auch mit Listview statt Datagrid umgesetzt. Listview ist eigentlich angebrachter, denn die Editier-Funktionalität des Datagrids ist hier ja unerwünscht.
      Aber - nerv! - im Listview funktioniert das MouseBinding nicht, denn Listview empfängt die Mausklicks selber und leitet sie nicht weiter. Damit sind wir - extra für ListView-Doppelklickse - wieder bei Event-Verarbeitung und CodeBehind:

      XML-Quellcode

      1. <ListView MouseDoubleClick="ListView_MouseDoubleClick" [...] >
      CodeBehind:

      VB.NET-Quellcode

      1. Private Sub ListView_MouseDoubleClick(sender As Object, e As MouseButtonEventArgs)
      2. e.Handled = e.ChangedButton = MouseButton.Left AndAlso MainViewModel.Instance.cmdEdit.TryExecute
      3. End Sub
      Also wenns LeftDoubleClick ist wird versucht, das Edit-Command auszuführen, und dementsprechend wird e.Handled gesetzt.
      Wirklich nicht schön, dasses nicht mit Bindings geht, sondern dass man über die global zugreifbare MainViewmodel-Instanz eingrabschen muss. :thumbdown:

      CommandBindings und RoutedCommands
      CommandBindings sind nur an statische Commands möglich. Richtig (wie mit RelayCommands) ins Viewmodel hinein-commanden kann man daher gar nicht. Auch executen diese statischen RoutedCommands überhaupt nichts, sondern Wirkung entsteht erst durch die CommandBindings, welche Events feuern.
      Also statische RoutedCommands sind eigentlich nur Schlüssel-Werte, an die Buttons und InputBindings binden können, und via CommandBinding wird das in ein Event umgeleitet ins CodeBehind (und nicht ins Viewmodel :( ).
      Ziemlich um 3 Ecken gedacht, und hat mit Databinding und Commanding herzlich wenig zu tun.
      Hier das CommandBinding fürs "Close-Command":

      XML-Quellcode

      1. <Window x:Class="wndMain" [...] >
      2. <UIElement.CommandBindings>
      3. <CommandBinding Command="Close" Executed="Close_Executed"/>
      4. </UIElement.CommandBindings>
      Und hier der EventHandler dazu:

      VB.NET-Quellcode

      1. Private Sub Close_Executed(sender As Object, e As RoutedEventArgs)
      2. Me.Close()
      3. End Sub
      Also für ein RoutedCommand braucht man ein statisches RoutedCommand, Buttons oder KeyBindings daran, ein CommandBinding, was Events feuert, und CodeBehind, der die Events behandelt.
      In diesem Beispiel aber bemerkenswert, dass das Close wirklich gerouted wird: Nämlich es wird in UserControls ausgelöst - ein UserControl kann aber gar nicht geschlossen werden 8| ! (sondern nur das Window, wo es aufsitzt)
      Das CommandBinding zum Close-Command (und seine Event-Behandlung) befinden sich daher im MainWindow. Ist nur eine Spielerei - logischer und einfacher wäre gewesen, das Close-Command auch im MainWindow auszulösen, wo es verarbeitet werden kann.
      (also mit den RoutedCommands hat man eine Lösung mit dem Problem, ein Problem für diese Lösung zu finden, scheint mir :thumbdown: )
      Jdfs. in diesem Sample werden RoutedCommands insgesamt nur benötigt, um Fenster zu schließen (CommandBinding+RoutedCommand = View-Sache).

      Custom RoutedCommands
      Neben dem vorgefertigten Application.Close-RoutedCommand habe ich für den Person-Edit-Dialog zum Fenster-schließen noch 2 weitere Commands, selbstgemacht, sog. "Custom-Commands": Ok und Cancel
      VB

      VB.NET-Quellcode

      1. Imports System.Windows.Input
      3. Public NotInheritable Class Commands
      5. Shared _Cancel As New RoutedCommand
      6. Public Shared ReadOnly Property Cancel() As ICommand
      7. Get
      8. Return _Cancel
      9. End Get
      10. End Property
      12. Shared _OK As New RoutedCommand
      13. Public Shared ReadOnly Property OK() As ICommand
      14. Get
      15. Return _OK
      16. End Get
      17. End Property
      19. End Class
      c#

      C#-Quellcode

      1. static class Commands {
      3. private static RoutedCommand _Cancel = new RoutedCommand();
      4. public static ICommand Cancel { get { return _Cancel; } }
      6. private static RoutedCommand _OK = new RoutedCommand();
      7. public static ICommand OK { get { return _OK; } }
      9. }
      (Habe ich den "Helpers" zugeordnet, denn diese RoutedCommands braucht man für jeden Dialog, den man schreibt :) )

      CommandBindings daran
      Beim Ok-Command-CommandBinding im Person-Dialog muss - im Gegensatz zum Cancel - auch das CanExecute-Event behandelt werden, um ungültige Eingaben zu verhindern:

      XML-Quellcode

      1. <Window x:Class="wndPerson" xmlns:my="clr-namespace:CommandsSampleVb" [...] >
      2. <UIElement.CommandBindings>
      3. <CommandBinding Command="my:Commands.OK" Executed="OK_Executed" CanExecute="OK_CanExecute"/>
      4. <CommandBinding Command="my:Commands.Cancel" Executed="Cancel_Executed" />
      5. </UIElement.CommandBindings>
      CodeBehind:

      VB.NET-Quellcode

      1. Private Sub OK_CanExecute(sender As Object, e As CanExecuteRoutedEventArgs)
      2. e.CanExecute = _DataContext.[Error] Is Nothing
      3. End Sub
      4. Private Sub OK_Executed(sender As Object, e As ExecutedRoutedEventArgs)
      5. _DataContext.CopyTo(_Person)
      6. DialogResult = True
      7. End Sub
      8. Private Sub Cancel_Executed(sender As Object, e As ExecutedRoutedEventArgs)
      9. DialogResult = False
      10. End Sub
      Ok kann nur executen, wenn _DataContext (eine temporäre Person) keinen Error hat. Und das Executen (Übernahme der Daten) besteht darin, dass _DataContext in die richtige _Person kopiert wird.
      Abschließend wirds DialogResult gesetzt, und das schließt den Dialog.

      Zur SampleSolution:
      Hab ich in Vb und in c# ausgeführt, und den View hab ich mal mit DataGrid und mal mit ListView umgesetzt (jeweils ein UserControl).
      Es ist wirklich gemein: Beim Listview ist die LeftDoubleClick-Gesture unmöglich. Datagrid reagiert komisch auf die Tab-Taste, Listview hingegen kann seine Spaltenbreite nicht automatisch anpassen.
      Also hat sich nichts geändert: der :evil: steckt im Detail.
      Dateien

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „ErfinderDesRades“ ()

      In diesem Zusammenhang auch ganz interessant: Patterns for Asynchronous MVVM Applications: Commands
      https://msdn.microsoft.com/en-us/magazine/dn630647.aspx

      Geht halt darum, wie man async-Methoden und Commands behandelt.
      Das Ergebnis, was in dem Artikel erarbeitet wird, ist sehr schön.

      Mit einigen wenigen XAML Zeilen und ein bisschen Code erstellt man eine kleine Anwendung, die in der Lage ist, je nach Status des Tasks bestimmte Aktionen auszuführen.

      Bilder





      (Bilder von MSDN)

    Facebook
    Telefonspende