Asynchrone Programmierung in WinRT

Meine neue WebSite finden Du jetzt unter https://AttilaKrick.com.

Beispiele zu Asynchrone API

MSDN Asynchrone Programmierung

Ein Benutzer erwartet das auf seine Aktion unmittelbare Reaktion von der App erfolgt. Um so verwirrter reagiert der Benutzer wenn diese Reaktion auf sich warten lässt weil die App noch synchron mit dem laden einer Datei aus dem Internet blockiert ist. Eine flüssige App würde hier den Download asynchron durchführen, so das der Benutzer weiter mit seiner App interagieren kann.

Wer mit dem asynchronen Mustern nicht vertraut ist kann sich die Asynchronität wie eine Bestellung beim Pizza-Dienst vorstellen. Sie rufen an und geben Ihre Bestellung durch und können anschließend Ihre bisherige Tätigkeit fortsetzen. Sobald der Pizza-Man oder -Frau mit der fertig Pizza klingelt können Sie sich nun um das leckere Esswerk kümmern. Niemand würde auf die Idee kommen nach der Bestellung apathisch in Inaktivität zu verfallen bis es klingelt.

Async-Namenskonvention – Üblicherweise enden asynchrone Methoden auf ...Async. Diese Methoden finden Sie dort wo Dauer eine Rolle spielt, z.B.

ContactPicker.PickSingleContactAsync
XmlDocument.SaveToFileAsync
DataReader.LoadAsync
RandomAccessStream.CopyAsync
SyndicationClient.RetrieveFeedAsync

await & async – Wenn Sie den await-Operator in einer Methode verwenden muss diese Methode das async-Schlüsselwort enthalten. Im Konstruktor oder in einer Eigenschaft können Sie await nicht verwenden. TIPP Erstellen Sie eine Methode, lagern den await-Code dorthin aus und ruf anschließend die erstellte Methode im Konstruktor bzw. in der Eigenschaft auf.

Threads, Kontextwechsel und Verteiler spielen für Sie keine Rolle mehr. Der Aufruf einer asynchronen API mittels await erfolgt im selben Kontext wie der ursprüngliche Aufruf. Das bedeutet dass Sie die Benutzeroberfläche mit den Ergebnissen aktualisieren können ohne sich um die Rückkehr zum Benutzeroberflächen-Thread zu kümmern.

Task – Sie können aus dem .NET Framework Task und Task<TResult>
verwenden um eigene asynchrone Methode zu implementieren. Hierzu gibt es die Erweiterungsmethoden (WindowsRuntimeSystemExtensions) AsAsyncAction oder AsAsyncOperation<TResult>. Diese liefern Async-WinRT-Konforme Ergebnisse die sich in WinRT entsprechend weiter verwerten lassen. Hierzu später mehr.

Asynchrone Methoden verwenden

Angenommen wir wollen Nachrichten-Beiträge direkt aus dem Internet herunterladen. Hierbei ist es wichtig dass die App reaktionsfähig bleibt. Um diese Reaktionsfähigkeit sicherzustellen, stellt WinRT eine asynchrone Methode SyndicationClient.RetrieveFeedAsync zum Herunterladen von Newsfeeds bereit deren asynchrone Verwendung wie folgt aussieht:

async void Button_Click(object sender, RoutedEventArgs e)
{
    var feedUri = new Uri("http://rss.golem.de/rss.php?feed=RSS2.0");
    var client = new SyndicationClient();
    try
    {
        var feed = await client.RetrieveFeedAsync(feedUri);
        StatusTextBox.Text = feed.Title.Text;
    }
    catch (Exception ex)
    {
        StatusTextBox.Text = ex.Message;
    }
}

Anmerkungen

  1. Der await-Operator teilt dem Compiler mit dass Sie eine asynchrone Methode aufrufen und er zusätzliche Arbeiten für Sie erliegen muss.
  2. Das Schlüsselwort asyncmuss in der Methodendeklaration aller Methoden angegeben werden, in denen Sie den await-Operator verwenden.
  3. Durch den Aufruf von ... await client.RetrieveFeedAsync initiiert die Methode den Abruf asynchron und beendet den Click-Ereignishandler vorübergehend. Ihre App kann dadurch andere Ereignisse verarbeiten und bleibt für den Benutzer reaktionsfähig.
  4. Wenn RetrieveFeedAsync abgeschlossen und das Ergebnis SyndicationFeed verfügbar ist macht Ihre App im Click-Ereignishandler an der Stelle weiter wo sie aufgehört hat var feeds ... um den Rest des Handlers abzuarbeiten.
  5. Während des asynchronen Vorgangs könnte z.B. die Netzwerkverbindung zum RSS-Feed abbrechen. Daher können Sie wie gewohnt die Fehlertoleranz erhöhen, indem Sie den asynchronen Code in einen try-catch-Block ausführen.

Ergebnisse asynchroner Methoden

Der Rückgabetyp von RetrieveFeedAsync ist kein SyndicationFeed sondern IAsyncOperationWithProgress<SyndicationFeed, RetrievalProgress>. Es ist wichtig zu Verstehen das der await-Operator tatsächlich auf Basis des Rückgabewerts und nicht auf der Methode agiert. Wenn Sie await anwenden erhalten Sie das Ergebnis der asynchronen Methoden SyndicationFeed, wenn Sie await nicht anwenden erhalten Sie IAsyncOperationWithProgress<SyndicationFeed, RetrievalProgress>.

Wenn Sie eine asynchrone Methode verwenden reflektieren Sie üben den Rückgabetyp um Infos zum Ergebnis zu erhalten. Alle asynchronen Methoden in WinRT geben einen der folgenden Typen zurück:

IAsyncAction                                    = Einfache Aktion
IAsyncActionWithProgress<TProgress>             = inkl Fortschritt 
IAsyncOperation<TResult>                        = inkl Ergebnis
IAsyncOperationWithProgress<TResult, TProgress> = inkl Ergebnis + Forts.

Diese Rückgabetypen eröffnen Ihnen weitere Möglichkeiten beim Umgang mit asynchronen Vorgängen die im weiteren Verlauf besprochen werden.

Ablaufsteuerung mithilfe asynchroner Rückgabetypen

Status

Ein asynchroner Vorgang beginnt im .Status==Started und wird mit Canceled, Completed oder Error fortgesetzt.

var feedUri = new Uri("http://rss.golem.de/rss.php?feed=RSS2.0");
var client = new SyndicationClient();

var asyncInfo = client.RetrieveFeedAsync(feedUri);
var id = asyncInfo.Id;
var status = asyncInfo.Status;

Abbrechen

In unterschiedlichen Situation kann es nötig sein einen asynchronen Vorgang abzubrechen. Rufe Sie dazu die Cancel-Methode auf:

IAsyncOperationWithProgress<SyndicationFeed, 
    RetrievalProgress> _FeedAsyncInfo;

void Starten_Click(object sender, RoutedEventArgs e)
{
    var feedUri = new Uri("http://rss.golem.de/rss.php?feed=RSS2.0");
    var client = new SyndicationClient();

    _FeedAsyncInfo = client.RetrieveFeedAsync(feedUri);
    var status = _FeedAsyncInfo.Status; // = Started
}

void Abbrechen_Click(object sender, RoutedEventArgs e)
{
    _FeedAsyncInfo**.Cancel()**;
    var status = _FeedAsyncInfo.Status; // = Canceled
}

Abschluss

Bei einem asynchronen Vorgang wird der Completed-Handler immer benötigt da dieser u. a. das tatsächliche Ergebnis liefert aber auch ausgeführt wird wenn abgebrochen wurde oder einen Fehler auftrat. Überprüfen Sie den Status und rufen nur im Erfolgsfall über GetResults() das Ergebnis ab:

var feedUri = new Uri("http://rss.golem.de/rss.php?feed=RSS2.0");
var client = new SyndicationClient();

var asyncInfo = client.RetrieveFeedAsync(feedUri);
Meldung.Text = String.Format("Start {0:ss.fff}: ID {1} STATUS {2}\n",
    DateTime.Now,
    asyncInfo.Id,
    asyncInfo.Status);

asyncInfo.Completed = async (ai, status) =>
{
    await Dispatcher.RunIdleAsync((f) =>
    {
        if (status == AsyncStatus.Completed)
            Meldung.Text = String.Format("{0:ss.fff}: ID {1} STATUS {2} ERGEBNIS {3}\n",
                DateTime.Now,
                ai.Id,
                ai.Status,
                ai.GetResults().Title.Text);

        else if (status == AsyncStatus.Canceled)
            Meldung.Text = String.Format("Abbruch {0:ss.fff}: ID {1}\n",
                DateTime.Now,
                ai.Id);

        else if (status == AsyncStatus.Error)
            Meldung.Text = String.Format("Fehler {0:ss.fff}: ID {1} "
                + "ERROR {2}\n",
                DateTime.Now,
                ai.Id, 
                ai.ErrorCode);
    });
};

Der Completed-Handler wird nicht im UI-Thread ausgeführt und kann so auch nicht direkt auf UI-Elemente zugreifen. Über await Dispatcher.RunIdleAsync(...) wäre ein Zugriff auf UI-Elemente wieder möglich da diese im UI-Thread ausgeführt werden.

Fortschritt

Einige asynchrone Methoden unterstützen Fortschrittsbenachrichtigungen während sie ausgeführt werden. Sie können diese Benachrichtigungen für aktuelle Fortschrittsberichte zum asynchronen Vorgang in der UI verwenden:

var feedUri = new Uri(FeedUri.Text);
var client = new SyndicationClient();
var asyncInfo = client.RetrieveFeedAsync(feedUri);

progressBar.Value = 0;
asyncInfo.Progress = async (ai, args) =>
{
    await Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>
    {
        progressBar.Value = args.BytesRetrieved 
            / args.TotalBytesToRetrieve * 100;
    });
};

Eigene Aufgaben asynchron ausführen

Neben den asynchronen WinRT-Methoden kann es hilfreich sein eigene Vorgänge mit großer Dauer asynchron in einem anderen Thread als den der Oberfläche auszuführen. Fügen Sie diese Aufgabe der Warteschlange des Threadpool hinzu. Implementieren wie oben einen Handler für Completed und werten darin im Erfolgsfall das Ergebnis aus.

Wenn nun der asynchrone Vorgang in der Warteschlange des ThreadPools abgeschlossen ist, wird der Completed-Handler aufgerufen. In diesem können Sie jedoch keine Änderung in der UI vornehmen da wir uns in einem anderen Thread befinden und würde sogar eine Wrong-Thread-Excaption kassieren. Um dies zu umgehen, kann der UI zugeordnete CoreDispatcher verwendet werden um die UI im richtigen Thread zu ändern.

Und so könnte z.B. das Click-Ereignis aussehen:

void Button_Click(object sender, RoutedEventArgs e)
{
    var asyncInfo = ThreadPool.RunAsync((a) =>
    {
        // Fake rechenintensiver Code
        new ManualResetEvent(false).WaitOne(2000);
    });
    asyncInfo.Completed = async (ai, status) =>
    {
        await Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>
        {
            switch (status)
            {
                case AsyncStatus.Completed:
                    LogThreadPoolRunAsync.Text += String.Format("Fertig {0:ss.fff} ID {1} STATUS {2}",
                        DateTime.Now,
                        asyncInfo.Id,
                        asyncInfo.Status);
                    break;

                case AsyncStatus.Error:
                    LogThreadPoolRunAsync.Text += String.Format("Fehler {0:ss.fff} ID {1} STATUS {2}",
                        DateTime.Now,
                        asyncInfo.Id,
                        asyncInfo.Status);
                    break;

                case AsyncStatus.Canceled:
                    LogThreadPoolRunAsync.Text += String.Format("Abbruch {0:ss.fff} ID {1} STATUS {2} EX {3}",
                        DateTime.Now,
                        asyncInfo.Id,
                        asyncInfo.Status,
                        ai.ErrorCode);
                    break;
            }
        });
    };
    LogThreadPoolRunAsync.Text = String.Format("Start {0:ss.fff} "
        + "ID {1} STATUS {2} >>> ",
        DateTime.Now,
        asyncInfo.Id,
        asyncInfo.Status);
}

Das gleiche Ergebnis mit dem await-Operator würde so aussehen:

async void Button_Click(object sender, RoutedEventArgs e)
{
    LogThreadPoolRunAsync.Text = String.Format("Start {0:ss.fff} >>> ", DateTime.Now);
    try
    {
        await ThreadPool.RunAsync((a) =>
        {
            // Fake rechenintensiver Code
            new ManualResetEvent(false).WaitOne(2000); 
        });
        LogThreadPoolRunAsync.Text += String.Format("Fertig {0:ss.fff}", DateTime.Now);
    }
    catch (Exception ex)
    {
        LogThreadPoolRunAsync.Text +=String.Format("Fehler {0:ss.fff} {1}", DateTime.Now, ex);
    }
}

Task nach WinRT-Async umwandeln

Um Ihre vorhandenen Task-Objekte im WinRT-Async-Model nutzen zu können oder über den Umweg der Task-Klasse an weitere Threading-Techniken wie z.B. den Cancel-Token zu gelangen, können Sie Task weiter verwenden und diese in die oben beschriebenen Async-Rückgabetypen umwandeln.

Hierfür enthält das System.Runtime.WindowsRuntime-Assembly Erweiterungsmethoden AsAsyncAction und AsAsyncOperation die Sie bei Task und Task<TResult>-Objekten nutzen können:

async void Button_Click(object sender, RoutedEventArgs e)
{
    LogTaskToAsyncOperationTest.Text = "Läuft ...";
    LogTaskToAsyncOperationTest.Text = await TaskToAsyncOperationAsync();
}

IAsyncOperation<string> TaskToAsyncOperationAsync()
{
    var t = Task<string>.Run(() =>
        {
            // Fake rechenintensiver Code
            new ManualResetEvent(false).WaitOne(3000);
            return "Nach 3s 43 asynchron heruntergeladen.";
        });
    return t.AsAsyncOperation();
}

Eigene erweiterte asynchrone Aufgaben ausführen

Das Umwandeln von Task mittels AsAsyncAction und AsAsyncOperation bietet grundlegende Unterstützung für Task’s in WinRT-Async. Darüber hinaus erhalten Sie erweiterter Unterstützung, wenn Sie AsyncInfo.Run und dessen Überladungen verwenden. Dazu gehören:

Abbruch

Mit AsyncInfo.Run werden Abbrüche mit asynchronen WinRT-Methoden unterstützt:

void Start_Click(object sender, RoutedEventArgs e)
{
    _JetztArbeitenAsyncInfo = JetztArbeitenAsync();
    _JetztArbeitenAsyncInfo.Completed = (asyncInfo, asyncStatus) => 
    {
        if (asyncStatus== AsyncStatus.Completed)
            LogAsyncInfoRunCancelTest.Text += String.Format("STATUS {0} "
                + "RESULT {1}",
                asyncStatus, asyncInfo.GetResults());

        else if (asyncStatus == AsyncStatus.Canceled)
            LogAsyncInfoRunCancelTest.Text += String.Format("STATUS {0}",
                asyncStatus);
    };
    LogAsyncInfoRunCancelTest.Text = String.Format("START {0} "
        + "STATUS {1} >>> ",
        _JetztArbeitenAsyncInfo.Id,
        _JetztArbeitenAsyncInfo.Status);
}

void Abbrechen_Click(object sender, RoutedEventArgs e)
{
    if (_JetztArbeitenAsyncInfo!=null)
    {
        _JetztArbeitenAsyncInfo.Cancel();
    }
}

private IAsyncOperation<string> _JetztArbeitenAsyncInfo;

public static IAsyncOperation<string> JetztArbeitenAsync()
{
    return AsyncInfo.Run(cancellationToken =>
    {
        return Task<string>.Run(() =>
        {
            for (int i = 0; i < 100; i++)
            {
                // Fake rechenintensiver Code
                new ManualResetEvent(false).WaitOne(25);

                if (cancellationToken.IsCancellationRequested)
                {
                    // Operation wurde abgebrochen
                    // Code der Aufräumen
                    cancellationToken.ThrowIfCancellationRequested();
                }
            }
            return "Fertig mit Async-Operation";
        });
    });
}

Fortschritt

AsyncInfo.Run stellt Unterstützung für Fortschrittsberichte durch asynchrone WinRT-Methoden bereit:

void Button_Click(object sender, RoutedEventArgs e)
{
    var ai = JetztArbeitenMitFortschrittAsync();
    ai.Progress = (asyncInfo, progressInfo) =>
    {
        LogAsyncInfoRunFortschrittTest.Text += String.Format("{0}% ",
            progressInfo);
    };
    LogAsyncInfoRunFortschrittTest.Text = String.Format("START {0} "
        + "STATUS {1} >>> Fortschritt ",
        ai.Id,
        ai.Status);
}

public static IAsyncOperationWithProgress<string, int> JetztArbeitenMitFortschrittAsync()
{
  return AsyncInfo.Run((CancellationToken cancellationToken, IProgress<int> progress) =>
    {
        return Task<string>.Run(() =>
        {
            for (int i = 0; i <= 10; i++)
            {
                progress.Report(i*10);

                // Fake rechenintensiver Code
                new ManualResetEvent(false).WaitOne(200);
            }
            return "Fertig mit Async-Operation";
        });
    });
}

App Studio

AppStudio Start

Kapitel Tile-Benachrichtigung und geöffnetes Beispiel-FlyoutKapitel SplashScreenSuchen nach SchlagwörternTool Viewer und Picker für FarbenTool Viewer und Picker für Glyphen aus der Schrift Segoe UI SymbolTool Viewer und Picker für AppBar-ButtonsTool Viewer aller AppIn-BeispieleViewer Illustrationen, Diagramme und Grafiken

Prolog

Was früher ein Fachbuch war ist heute App Studio die App. Pures Wissen auf den Punkt gebracht. Viele bunte Illustrationen. Interaktive Beispiele zum anfassen und experimentieren. Code einfach kopieren. Nach Schlagwörtern suchen. Überall lesen und stöbern und keinen dicken Schinken schleppen. Beispiele, Projekte, Vorlagen und Muster direkt aus der App öffnen und weiter nutzen. Ständige Updates direkt aus dem Store.

Meine neue WebSite finden Du jetzt unter https://AttilaKrick.com.

Inhalt

App Studio gibt Ihnen das Werkzeug an die Hand um Windows Store Apps zu entwerfen und im Windows Store zu veröffentlichen. Sie erfahren was Sie brauchen, wo Sie anfangen sollten und was Sie über das Erstellen wissen sollten. Die App dient als Einführung für den C# Programmierer aber auch als Nachschlagewerk für die tägliche Arbeit und das zu folgenden Themen:

Animationen               Ansichten-Status   App-Datenspeicher
Dateien und Ordner        Datenbindung       Drucken
Einstellungs-Flyout       Ressourcen         Hintergrundaufgaben
Lebenszyklus einer App    MVVM               Navigation
Gestaltung einer App      Sensoren           SpalshScreen  
Text und Typografie       Tastatur           Teilen
UI Elemente im Showroom   Touch              Video und Audio
Visual Studio 2012        Windows 8          Windows Store
WinRT und .NET            XAML               Zeichnen
Tile-, Badge-, Glyph-,    Tile- und          Toast-Benachrichtigung 
LockScreen                Suche-Funktion     u.v.m.

In App Studio direkt über die AppBar finden Sie Tools für die tägliche Arbeit wie:

Picker & Viewer für AppBar-Button Style
                    Color
                    Gylphen aus Segoe UI Symbol
                    StandardStyle
                    InApp-Beispiele

Vorlagen und Muster für Seiten-Layout
                        Schriftbild
                        Windows Store Checkliste
                        Visual Studio Handout

WCF Web Service für Test- und Debugging

DiaShow durch alle Illustrationen und Diagramme

Über den Autor

Attila Krick ist ein gestandener IT-Spezialist, Softwareentwickler, Autor und Trainer spezialisiert auf Betriebs-, Mail-, Datenbank-Systeme, .NET und Office aus dem Hause Microsoft (MCP, MCSA, MCT).

Seit 2005 ist er mit seinem Angebot für Sie tätig. Den Schwerpunkt seiner Tätigkeit gliedert sich in die Bereiche IT-Service und Beratung, Software-Entwicklung und Coaching und Schulung.

App Studio im Windows Store

 

WPF Eingabe-Validierung

Meine neue WebSite finden Du jetzt unter https://AttilaKrick.com.

 

Validierung basierend auf komplexer Regeln für Geschäftsdaten

WPF weist ein umfassendes Datenbindungssystem auf. Abgesehen davon, dass die Datenbindung wesentlich zur lockeren Kopplung der Benutzeroberfläche mit der Logik (MVVM) beiträgt, bietet es auch eine leistungsstarke und flexible Unterstützung für die Überprüfung der Daten. Dies gilt es zu beherrschen.

  • Wie arbeitet diese Überprüfung?
  • Welche Arten der Überprüfungen gibt es?
  • Wo liegen die Stärken und Schwächen?
  • Wie Können Überprüfungsfehler dem Benutzer angezeigt werden?

Vorbereitung

Kenntnisse in der WPF-Datenbindung, eine Einführung finden Sie z.B. hier Datenbindung in WPF.

Um eine Daten-Pipeline zwischen einer einzelnen Eigenschaft in einem Ziel Steuerelement und einer Datenquellen-Objekteigenschaft zu schaffen verwendet man ein Binding-Objekt.

Das eine Überprüfung eingeleitet werden kann, muss die Mode-Eigenschaft des Binding-Objektes auf TwoWay stehen.

Arten der Überprüft

Es gibt 3 miteinander kombinierbare Überprüfungs-Mechanismen, um zu ermitteln, ob über ein datengebundenes Steuerelement Benutzereingaben gültig sind.

1. Exception

Wenn beim Beschreiben der Quellobjekt-Eigenschaft eine Exception ausgelöst wird, so kann ein Überprüfungsfehler für das Binding-Objekt bestehen.

2. ValidationRule, BindingGroup

Dem Binding-Objekt können eine Sammlung von ValidationRule’s übergeben werden, die Entscheiden ob Überprüfungsfehler durch Benutzereingaben vorliegen. Die BindingGroup unterstützt diesen Xaml-Ansatz um die Möglichkeit Eigenschaftsübergreifend Überprüfungen vornehmen zu können.

3. IDataErrorInfo, INotifyDataErrorInfo

Durch Implementieren von IDataErrorInfo in das gebundene Datenquellen-Objekt Entscheidet dieses ob Überprüfungsfehler vorliegen. Das INotifyDataErrorInfo-Interface stand bis .NET 4.5 nur Silverlight zur Verfügung. Die Implementierungs-Logik unterscheidet sich zu IDataErrorInfo wird jedoch doch von Windows Store App, WPF und Silverlight unterstützt.

Wann wird überprüft

Die Überprüfung findet dann statt, wenn die Bindung die Daten in die Quellobjekt-Eigenschaft schreibt. Dieses Update-Verhalten wird im Binding-Objekt gesetzt:
Text=“{Binding Path=Aufgabe.Beschreibung, UpdateSourceTrigger=PropertyChanged}
Folgende Einstelllungen sind denkbar:

  • PropertyChanged – Bei jeder Änderung im Steuerelement. (Datum in TextBox, Sinnvoll?)
  • FocusChange – Das Update wird mit Wechsel des Steuerelement- Fokusses eingeleitet.
  • Explicit – Der Aufruf erfolgt manuell und wird z.B. in Kombination mit BindingGroup genutzt.

Arbeitsschritte der Überprüft

  1. Benutzereingabe führt zur Änderung einer UIElement-Eigenschaft
  2. Diese Daten werden ggf. in den Quellobjekt-Eigenschaftentyp umgewandelt
  3. Der Wert für die Quellobjekt-Eigenschaft wird gesetzt
  4. Binding.SourceUpdated-Ereignis wird ausgelöst
  5. Exception werden von der Bindung abgefangen, wenn diese vom Setter der Quellobjekt-Eigenschaft ausgelöst wurden
  6. OPTIONAL: IDataErrorInfo- / INotifyDataErrorInfo-Eigenschaften werden vom Quellobjekt abgerufen
  7. Der Benutzer erhält Überprüfungsfehlerangaben
  8. Validation.Error wird ausgelöst

X. OPTIONAL: ValidationRule’s auslösen, je nachdem wie ValidationStep-Eigenschaft gesetzt wurde, z.B. vor- / nach der Typkonvertierung, nach dem aktualisieren Quellobjekt-Eigenschaft oder wenn begonnen wird (s. IEditableObject) die Quellobjekt-Eigenschaft zu ändern.

Prüfung per Exception

Durch Festlegen der ValidatesOnExceptions-Eigenschaft im Binding-Objekt wird ein Überprüfungsfehler festgelegt, wenn im Setter der Quellobjekt-Eigenschaft eine Exception ausgelöst wird.

Text="{Binding Path=MitarbeiterNr, ValidatesOnExceptions=True}"

Auch würde ein Überprüfungsfehler vorliegen, wenn die Exception im Typkonvertierungs-Prozess ausgelöst wurde.

Prüfung per ValidationRule

Dem Binding-Objekt können mehrere ValidationRule-Objekte über die Eigenschaft ValidationRules hinzugefügt weden.

Um eigene ValidationRule-Objekte zu nutzen, leitet man diese Klassen von ValidationRule ab und überschreiben die Validate-Methode. Das Bindung-Objekt ruft diese Methode auf sobald sich die Daten im gebundenen Steuerelement ändern.

Wenn die Validate-Methode ein ungültiges ValidationResult-Objekt zurückgibt, wird für diese Bindung ein Überprüfungsfehler festgelegt.

public class RegexValidationRule : ValidationRule
{
    public string RegexMuster { get; set; }

    public override ValidationResult Validate(object value,
       CultureInfo cultureInfo)
    {
        if (RegexMuster == null)
            return ValidationResult.ValidResult;

        if (!(value is string))
            return new ValidationResult(
                isValid: false,
                errorContent: "Die Eingabe muss aus Text bestehen.");

        if (!Regex.IsMatch((string)value, RegexMuster))
            return new ValidationResult(
                isValid: false, errorContent: "Falsches Eingabeformat.");

        return ValidationResult.ValidResult;
    }
}

Eigenschaften, die in einer ValidationRule öffentlich verfügbar gemacht werden (s. z.B. RegexMuster), können von der XAML am Punkt der Verwendung festgelegt werden.
Das zurückgebende ValidationResult kann die Fehlermeldung die in der Benutzeroberfläche angezeigt werden soll.


  
    
      
        
      
    
  

ValidationRule-Objkete können jweils unterschiedliche Werte für die ValidationStep-Eigenschaft aufweisen.

Wenn eine ValidationRule einen Fehler zurückgibt werden die darauffolgenden Regeln nicht ausgewertet.

PRO

  • Implementierung kompliziertere Überprüfungs-Logik möglich

CONTRA

  •  Das ValidationRule-Objekt hat keinen Zugriff auf andere Eigenschaften im Quellobjekt und kann daher seinen Wert nicht mit diesen, für die Validierung in Beziehung setzen.
  • Die ValidationRule-Objkete werden im XAML, in einem erweiterten Binding-Element angeben (= Aufwand).

Prüfung per IDataErrorInfo

public interface IDataErrorInfo
{
    string Error { get; }
    string this[string columnName] { get; }
}

Durch Implementieren von  IDataErrorInfo in das Datenquell-Objekt und durch Festlegen der ValidatesOnDataErrors-Eigenschaft im Binding-Objekt, führt die Bindung Aufrufe der IDataErrorInfo-API aus.

Text="{Binding Path=Aufgabe.Beschreibung, ValidatesOnDataErrors=True}

Wenn von diesen IDataErrorInfo-Eigenschaften Zeichenfolgen zurückgegeben werden, die nicht Null oder nicht leer sind, wird ein Überprüfungsfehler festgelegt.

public class Kunde : IDataErrorInfo
{
    public string this[string propertyName]
    {
        get { return IsValid(propertyName); }
    }

    public string Email { get; set; }
    public bool IstInternetKunde { get; set; }

    private string IsValid(string propertyName)
    {
        switch (propertyName)
        {
            case "Email":
                if (!string.IsNullOrWhiteSpace(Email)
                    && IstInternetKunde)
                    return "Als Internet-Kunde wird eine"
                           + " Email-Adresse benötigt.";
                break;
        }
        return String.Empty;
    }
}

Der Indexer wird verwendet, um Fehler auf den einzelnen Eigenschaftenebenen anzugeben.

Die Error-Eigenschaft wird verwendet, um einen Fehler für das Objekt als Ganzes anzugeben, z. B. auf Datensatz-Ebene wie im DataGrid oder in einer BindingGroup.

PRO

  • Der Vorteil von IDataErrorInfo besteht darin, dass untereinander verbundene Eigenschaften einfacher verarbeitet werden können.

CONTRA

  •  Die Implementierung des Indexers führt in der Regel zu einer umfangreichen switch-case-Block.
  • Die Implementierung von IDataErrorInfo erst aufgerufen, nachdem der Eigenschaftswert bereits in dem Objekt festgelegt wurde. D.h. die anderen Objekte wurden bereits über Änderungen informiert (siehe INotifyPropertyChanged) obwohl die Daten im Anschluss als ungültig erklärt werden.
  • Nur ein Fehler pro Eigenschaft möglich.
  • Benutzen des Indexer der evtl. für eigen Logik benötigt wird.

Prüfung per INotifyDataErrorInfo

Das Konzept wurde in Silverlight eingeführt und mit der .NET 4.5 Version auch auf die anderen Bereiche wie WPF, Windows Store Apps ausgeweitet. Vom Grundgedanken her ist es dem IDataErrorInfo-Konzept ähnlich, das Interface schreibt jedoch folgende Member vor:

// Definiert Member, die von Datenentitätsklassen
// implementiert werden können, um benutzerdefinierten,
// synchronen und asynchronen Validierungssupport bereitzustellen.
public interface INotifyDataErrorInfo
{
    // Ruft einen Wert ab, der angibt, ob die Entität
    // über Validierungsfehler verfügt.
    bool HasErrors { get; }

    // Tritt ein, wenn sich die Validierungsfehler
    // für eine Eigenschaft oder für die ganze Entität geändert haben.
    event EventHandler ErrorsChanged;

    // Ruft die Validierungsfehler für eine
    // angegebene Eigenschaft oder für die ganze Entität ab.
    IEnumerable GetErrors(string propertyName);
}

Dieses Konzept arbeitet idealerweise mit der ValidationContext-Klasse sowie den Mebmern des Namensraumes System.ComponentModel.DataAnnotations zusammen. Hierbei werden die Validierungsregeln als Attribute der Eigenschaften im Quell-Objekt beschrieben.

Eine Implementierung würde Konzeptionell wie folge Dargestellt:

public class Kunde : INotifyDataErrorInfo
{
    #region Bindables

    public string Email { get; set; }

    public bool IstInternetKunde { get; set; }

    #endregion

    #region INotifyPropertyChanged Members

    public event EventHandler ErrorsChanged;

    public bool HasErrors { get {
      return _FehlerListe == null ? false : _FehlerListe.Count > 0; } }

    public IEnumerable GetErrors(string propertyName)
    {
        IList list;
        return _FehlerListe.TryGetValue(propertyName, out list)
          ? list : Enumerable.Empty();
    }

    #endregion

    #region Helpers for INotifyDataErrorInfo

    // Im Setter der jeweiligen Eigenschaft aufrufen
    // Ideale Kombiniert mit Techniken aus dem
    // Namespace System.ComponentModel.DataAnnotations
    private void Validate([CallerMemberName] string propertyName = null)
    {
        switch (propertyName)
        {
            case "Email":
                if (!string.IsNullOrWhiteSpace(Email)
                     && IstInternetKunde)
                    SetErrors(propertyName, new[]{"Als Internet-Kunde"
                     + " wird eine Email-Adresse benötigt."});
                else
                    ClearErrors(propertyName);
                break;
        }
    }

    private void SetErrors(string propertyName,
                  IEnumerable validationResults)
    {
        _FehlerListe[propertyName] = validationResults.ToList();
        OnErrorsChanged(propertyName);
    }

    private void ClearErrors(string propertyName)
    {
        _FehlerListe.Remove(propertyName);
        OnErrorsChanged(propertyName);
    }

    private void OnErrorsChanged(string propertyName)
    {
        if (ErrorsChanged != null)
            ErrorsChanged(this, new DataErrorsChangedEventArgs(
                         propertyName));
    }

    private readonly IDictionary<string, IList> _FehlerListe
             = new Dictionary<string, IList>();

    #endregion
}

Prüfen per BindingGroup

Eine BindingGroup ist speziell so konzipiert, dass die Überprüfung in einer Gruppe von Bindungen gleichzeitig ausgewertet werden können. Dies ist z.B. nützlich, wenn ein Benutzer-View erst auf OK-Klick validiert werden soll.
Um eine BindingGroup zu verwenden, benötigen Sie eine Gruppe von Steuerelementen mit normalen Bindungen, die ein Vorgängerelement gemeinsam verwenden.


    
        
            
                
            
        
    

Eine ValidationRule, die mit einer BindingGroup verknüpft ist, funktioniert etwas anders als eine ValidationRule, die mit einer einzigen Bindung verknüpft ist.

public class KundeValidationRule : ValidationRule
{
    public override ValidationResult Validate(
         object value, CultureInfo cultureInfo)
    {
        BindingGroup bindingGroup = value as BindingGroup;
        if (bindingGroup == null)
            return new ValidationResult(false, "KundeValidationRule"
                             + " arbeitet nur mit einer BindingGroup");

        object item = bindingGroup.Items[0];
        if ('Prüfung für item' == false)
            return new ValidationResult(false, "Fehlermeldung ....");

        return ValidationResult.ValidResult;
    }
}

Anzeige von Überprüfungsfehlern

Die standardmäßige Kennzeichnung für einen Überprüfungsfehler ist ein roter Rahmen um das Steuerelement ohne einer Anzeige der verknüpfte Fehlermeldung.
Das Hinzufügen einer ToolTip-Anzeige, die den Fehlertext anzeigt, ist ganz einfach:


    
        
            
                
                    
                
            
        
    

Um die standardmäßige Überprüfungsfehleranzeige 100% den eigenen Vorstellung anzupassen, müssen Sie die angefügte Validation.ErrorTemplate-Eigenschaft festlegen:


    
        
            
                
                    
                    
                
            
        
        
    

Die Verknüpfung dieser Vorlage mit einem Steuerelement würde so aussehen:


    

Gut zu wissen

Wenn Sie in der View eine spezielle Aufgabe bei ungültige Daten ausführen müssen, z.B. Controls deaktivieren nutzen Sie das Validation.Error-Event.