Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Langsam bin ich immer mehr am verzweifeln. Folgendes möchte ich machen.
Ich möchte ein Command an einen Button binden. Mein Vorgehen bisher:
1. Ich habe eine Klasse (AppCommands.cs) erstellt, wo zuerst ein neues Command erzeuge:
Code:
public static class AppCommands
{
public static ICommand Exit { get; set; } = new ExitCommand();
}
2. Außerdem eine Klasse (ExitCommands.cs ) worin ich mein Command anlege:
Code:
public class ExitCommand : ICommand
{
public event EventHandler CanExecuteChanged;
public bool CanExecute(object parameter)
{
return true;
}
public void Execute(object parameter)
{
// Hier würde ich jetzt gern eine Ausgabe in der Statuszeile machen, bevor die App geschlossen wird
Application.Current.Shutdown();
}
}
3. In meiner MainWindow.xaml bin ich das ganze an einen Button folgendermaßen:
Mal die dumme Frage: warum überhaupt, wenn sie eh schließt? Und was heißt "Statuszeile"? Ein eigenes Control bei dir oder was Windows-spezifisches oder so? Mir fehlt noch ein bisschen der Durchblick was genau du eigentlich erreichen willst. Also...ich weiß was du meinst, aber nicht was genau du jetzt machen möchtest.
Normalerweise würde ich mich evtl. auf ein OnClosing-Event registrieren oder man triggert im Exit-Command etwas bestimmtes, wie ne Shutdown Methode in einem zentralen Service oder so...aber wie gesagt, da fehlen mir die Details. Vlt kannst du da ja mal ein genaueres Beispiel liefern.
Sowas lässt sich reinbasteln. Hier wird das Shutdown in einem Hintergrundtask mit einer Sekunde Verzögerung ausgelöst:
Code:
public void Execute(object parameter)
{
// Hier würde ich jetzt gern eine Ausgabe in der Statuszeile machen, bevor die App geschlossen wird
TextAusgeben();
Task.Run(async ()=>
{
await Task.Delay(1000);
Application.Current.Shutdown();
}):
}
Die Statusbar ist eine normale Statusbar unten im Window. Hier kommen halt Texte rein, wie z.B. "kopiert, fertig" usw.
Die Statusbar befindet sich auf dem Hauptfenster.
@michi.o
Mit einer Methode habe ich es auch schon versucht, doch wie kann ich in der Command Klasse auf die Status Bar zugreifen?
public void Execute(object parameter)
{
((Textblock)parameter).Text = "123";
}
Ist jetzt aber nicht die saubere Art. Eigentlich definiert man gemäß dem MVVM Pattern ein ViewModel, welches INotifyPropertyChanged implementiert und setzt dieses ViewModel als DataContext für das Fenster. Danach kann man per Databinding Texte direkt im ViewModel ändern.
Bei dem zweiten Weg kann ich das Command gleich mit in die ModelViewKlasse schreiben? Oder ist es günstiger eine eigene Command Klasse dafür zu erstellen?
Was passiert, wenn ich noch ein zweites, anderes Command erstelle? Dann ein eigenes ViewModel?
Wäre nett, wenn du mal einen groben Plan geben könntest, wo ich wann was erstellen muss?
Ja, du kannst den Code, den Dein Command ausführen soll, direkt ins ViewModel schreiben. Es gibt immer ein Paar aus Execute und CanExecute. Die Klasse MyCommand in meinem Beispiel wird häufig als RelayCommand bezeichnet (meine Version ist stark vereinfacht). Mit dieser Klasse kannst Du die beiden zu einem ICommand verbinden. Ich hab mal der Vollständigkeit halber die volle Version eines Relay Commands als Textdatei angehängt.
Ein zweites ViewModel ist nicht nötig. Das Fenster kann nur einen DataContext haben. Einzelnen Elementen kann man aber wiederrum einen separaten DataContext zuweisen. Ansonsten erben die den vom Fenster.
Also kannst Du im Prinzip diesen Teil hier in deinem ViewModel beliebig oft kopieren, wenn es mehrere ICommands geben soll:
C#:
public ICommand StatusCommand
{
get
{
return new MyCommand(ExecuteStatusCommand, CanStatusCommandExecute);
}
}
void ExecuteStatusCommand(object o)
{
StatusText = "123";
}
bool CanStatusCommandExecute(object o)
{
return true;
}
Hmm... das habe ich bisher noch nicht genutzt. Von den Beispielen im Internet sieht es so aus als könnte man damit vordefinierte Standardkommandos mit einem Button verknüpfen.
Help gehört zu den vordefinierten. Ich vermute, dass hinter diesen Kommandos auch bestimmte Tastenkombinationen stecken. Help_CanExecute und Help_executed wären dann wieder Methoden im ViewModel.
Ich habe das ganze jetzt mal ein wenig versucht aufzuschreiben, wie genau ich grundlegend vorgehen würde
1. MainViewModel erstellt
C#:
public class MainWindowViewModel
{
}
2. Klasse anlegen wo alle meine Commands rein kommen
C#:
public static class AppCommands
{
public static ICommand Exit { get; set; } = new ExitCommand();
public static ICommand Copy { get; set; } = new CopyCommand();
}
3. Klasse anlegen welche meine Commands kennt.
C#:
internal class CopyCommand : ICommand
{
public event EventHandler CanExecuteChanged;
public bool CanExecute(object parameter)
{
return true;
}
public void Execute(object parameter)
{
throw new NotImplementedException();
}
}
Am Ende sieht meine Klasse so aus:
C#:
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Linq;
using System.Text;
using System.Windows;
using System.Windows.Input;
namespace WinInfos
{
public class MainWindowViewModel
{
public static class AppCommands
{
public static ICommand Exit { get; set; } = new ExitCommand();
public static ICommand Copy { get; set; } = new CopyCommand();
}
internal class CopyCommand : ICommand
{
public event EventHandler CanExecuteChanged;
public bool CanExecute(object parameter)
{
return true;
}
public void Execute(object parameter)
{
MessageBox.Show("Copy");
}
}
internal class ExitCommand : ICommand
{
public event EventHandler CanExecuteChanged;
public bool CanExecute(object parameter)
{
return true;
}
public void Execute(object parameter)
{
MessageBox.Show("Exit");
}
}
}
}
Liege ich soweit erst einmal richtig? Habe ich gravierende Fehler im Code oder in meiner Denkweise?
Klassen kommen bitte auch in separate Files. Dein Viewmodel kann die Commands dann kennen, besitzt sie aber niemals. Wie man Commands implementiert und nutzt, da gibt es verschiedene Ansätze, sollte aber so klappen wie du es machst, die Grundstruktur sieht schon nicht schlecht aus.
Wenn du bestimmte Commands immer wieder nutzt und diese nur datenunabhängige Aktionen ausführen kannst du die natürlich in einer separaten Klasse implementieren, sobald sie kontextabhängig werden müssten sie dann aber in das dazugehörige ViewModel rein.
Hier ein Beispiel aus eigener Verwendung (ggf. etwas überfordernd, bei Fragen bitte gezielt nachfragen.).
Wir benutzen in unserer Solution folgende Command-Struktur:
C#:
public class MyCommand : ICommand
{
private readonly Action _targetExecuteMethod;
private readonly Func<bool> _targetCanExecuteMethod;
public MyCommand( Action targetExecuteMethod, Func<bool> targetCanExecuteMethod )
{
_targetExecuteMethod = targetExecuteMethod;
_targetCanExecuteMethod = targetCanExecuteMethod;
}
public MyCommand(Action targetExecuteMethod) : this(targetExecuteMethod, () => true) { }
public void RaiseCanExecuteChanged()
{
CanExecuteChanged?.Invoke( this, EventArgs.Empty );
}
public bool CanExecute( object parameter = null )
{
// wenn canExecute != null gib das zurück, sonst schau ob wenigstens Execute != null ist
return _targetCanExecuteMethod?.Invoke( ) ?? _targetExecuteMethod != null;
}
public void Execute( object parameter = null )
{
_targetExecuteMethod?.Invoke( );
}
// weak reference, if command instance lifetime is longer than lifetime of UI objects hooked up to the command
public event EventHandler CanExecuteChanged = delegate { };
}
C#:
public class MyCommandWithParameter : ICommand
{
private readonly Action<object> _targetExecuteMethod;
private readonly Func<object,bool> _targetCanExecuteMethodWithParameter;
private readonly Func<bool> _targetCanExecuteMethod;
public MyCommandWithParameter(Action<object> targetExecuteMethod, Func<object,bool> targetCanExecuteMethod)
{
_targetExecuteMethod = targetExecuteMethod;
_targetCanExecuteMethodWithParameter = targetCanExecuteMethod;
}
public MyCommandWithParameter(Action<object> targetExecuteMethod, Func<bool> targetCanExecuteMethod)
{
_targetExecuteMethod = targetExecuteMethod;
_targetCanExecuteMethod = targetCanExecuteMethod;
}
public MyCommandWithParameter(Action<object> targetExecuteMethod) : this(targetExecuteMethod, () => true) { }
public void RaiseCanExecuteChanged()
{
CanExecuteChanged?.Invoke(this, EventArgs.Empty);
}
public bool CanExecute(object parameter = null)
{
// wenn canExecute != null gib das zurück, sonst schau ob wenigstens Execute != null ist
if ( _targetCanExecuteMethodWithParameter != null )
{
return _targetCanExecuteMethodWithParameter?.Invoke( parameter ) ?? _targetExecuteMethod != null;
}
return _targetCanExecuteMethod?.Invoke() ?? _targetExecuteMethod != null;
}
public void Execute(object parameter)
{
_targetExecuteMethod?.Invoke(parameter);
}
// weak reference, if command instance lifetime is longer than lifetime of UI objects hooked up to the command
public event EventHandler CanExecuteChanged = delegate { };
}
Ob man gewisse Feinheiten daraus benutzt (wie die alternativen Konstruktoren o. ä.) oder nicht sei mal dahingestellt, die sind nicht zwingend notwendig. Das Grundprinzip ist dabei aber relativ einfach:
Es gibt eine Basisklasse, die die gewünschte ICommand-Struktur implementiert. Jeweils als parameterloses Command (also nur CanExecute und Execute) sowie mit Berücksichtigung eines Parameters, der mit CommandParameter im WPF reingereicht werden kann. Das sieht dann zum Beispiel so aus:
C#:
ViewModel:
// Property-Definition
public MyCommand ExitCommand { get; set; }
...
// Initialisierung im Konstruktor oder durch eine entsprechende Init-Methode
ExitCommand = new MyCommand(Exit, CanExit);
// alternativ: kann immer ausgeführt werden -> nutze anderen Konstruktor
ExitCommand = new MyCommand(Exit);
// alternativ: keine Delegaten reinwerfen, sondern Lambda-Ausdrücke benutzen
ExitCommand = new MyCommand(() => window.Close(), () => window.IsVisible == true);
Im XAML wird das Command dann einfach an das UI-Element gebunden, was das können soll:
XML:
<!--DataContext muss im XAML oder Codebehind auf das ViewModel gesetzt sein-->
<Button Command = {Binding ExitCommand} />
Durch das Binding wird der Button, wenn CanExecute negativ ist, automatisch deaktiviert. Man muss dann lediglich darauf achten bei Änderungen, die die CanExecute-Bedingung verändern, ExitCommand.RaiseCanExecuteChanged(); aufzurufen.
Das Command mit Parameter funktioniert ähnlich, nur dass die Execute-Delegaten einen Parameter des Typs object bekommen, auf den man sich dann im Command beziehen kann.
Ein kleines Beispiel hierzu:
Per Binding im CommandParameter wird das Item selbst übergeben, es entspricht {Binding Path=/}. Damit kann man dann zum Beispiel im ViewModel wieder folgendes anstellen:
Dann müssen die Properties von MyItemType lediglich INotifyPropertyChanged benutzen und die ganze UI wird automatisch aktualisiert.
------------------
Schlussendlich hast du dann eine einzelne, grundlegende Basisklasse für deine Commands. Diese werden separat im ViewModel deklariert und erzeugt. Deine UI benutzt das ViewModel als DataContext und kann darauf binden. Die Anzeigelogik verbleibt automatisiert in der UI, deine Datenlogik im ViewModel.
Nein, da hast Du was nicht verstanden. Bitte keine internen Klassen definieren und auch keine statischen (static) Klassen nutzen.
Speichere die RelayCommand Klasse, die ich oben angehängt habe in eine neue *.cs Datei, mit Namespace drum herum.
Hier nochmal mein Beispiel, angepasst mit 2 Buttons und 2 ICommands + der RelayCommand Klasse:
