Natürlich will ich nicht alles von Lester wiederkauen, aber eine Neuerung möchte ich doch herausstellen. Bei bisherigen WPF Anwendungen ist die Darstellung von Text mit kleiner Schrift teilweise etwas (manche sagen sogar sehr) unscharf. Der Artikel Textclarity in WPF auf windowsclient.net geht ziemlich gut auf diese Problematik und mögliche Workarounds ein. In .NET 4.0 ist es nun möglich das Textrendering mit zwei attached properties zu beeinflussen.

TextOptions.TextFormattingMode kann mit zwei unterschiedlichen Werten belegt werden. Einmal mit Ideal, was dem bisherigen WPF Textrendering entspricht oder mit Display, was die Darstellung bei kleinen Schriftarten schärfer aussehen lässt.

TextOptions.TextRenderingMode legt den Algorithmus für das Antialiasing fest und kann die Werte Auto, Aliased, Greyscale oder ClearType haben.

Der folgende Screenshot zeigt einige der Einstellungen für kleine und große Schrift:

Bei der kleinen Schrift sieht man eine deutliche Verbesserung der Lesbarkeit des angezeigten Textes. Das unscharfe, verwaschene Schriftbild ist einer klaren Darstellung gewichen, was vorallem bei Businessanwendungen mit WPF sehr wichtig ist. Wer jetzt schon die neuen Features von .NET 4.0 ausprobieren möchte, kann sich weiterhin die Beta 2 von Visual Studio 2010 hier herunterladen.

Drei Sachen fallen ins Auge

1. jedes ViewModel muss INotifyPropertyChanged implementieren, d.h. den PropertyChanged Event anbieten und eine Methode zum Feuern des Events haben.
2. die EventArgs für den PropertyChanged Event bekommen als Parameter einen String, der dem Namen der Property entspricht.
3. der Code ist “zugemüllt” mit Infrastrukturcode, der eigentlich nichts zur Logik des Objekts beiträgt

Der erste Punkt lässt sich relativ einfach lösen, indem man eine ViewModel Basisklasse macht, die diese Aufgaben übernimmt.

Basisklasse für ViewModels

public abstract class ViewModelBase : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    protected void OnPropertyChanged(string propertyName)
    {
        PropertyChangedEventHandler handler = PropertyChanged;
        if (handler != null)
        {
            handler(this, new PropertyChangedEventArgs(propertyName));
        }
    }
}

Beim zweiten Punkt wird es dann schon schwieriger. Hier gibt es mehrere Ansätze, die Strings loszuwerden.

Am häufigsten trifft man wohl eine Variante mit Lambda Expressions an. Die Implementierungen reichen von einer Extensionmethod für den PropertyChangedEventHandler bis zu einer generischen ViewModel Basisklasse, welche das abgeleitete ViewModel als Type Parameter bekommt. Hier ein paar Links zum Nachlesen:

J.P. Hamilton – Generische ViewModel Basisklasse

Stefan Lieser – Implementierung direkt im ViewModel

Eric De Carufel – Extensionmethod für PropertyChangedEventHandler

Andere Lösungen, die ich gefunden habe:

Alkampfer – INotifyPropertyChanged mit CodeDom implementieren

Ayende – INotifyPropertyChanged mit Castle Dynamic Proxy

Mike Saunders – INotifyPropertyChanged mit PostSharp Aspekt

Richard Banks – INotifyPropertyChanged mit PostSharp Aspekt

Dann gibt es noch die den Verfechter von UpdateControls, Michael L. Perry. UpdateControls ist eine Open Source Bibliothek auf CodePlex, die es erlaubt, Änderungen von Eigenschaften auch ohne INotifyProperyChanged zu propagieren und z.B. an WPF Controls zu binden. Eine gute Einführung in UpdateControls kann man beim CODE Magazin lesen.

Mir gefallen bisher die Lösungen mit PostSharp am Besten. Damit lassen sich alle drei Punkte auf einmal erschlagen.

1. Mit einem PostSharp Attribut, das auf die ViewModel Klasse geklebt wird, lässt man die INotifyPropertyChanged Implementierung automatisch einweben.
2. Es gibt keine Magic Strings mehr, da auch das Feuern des ProperyChanged Events automatisch eingewoben wird. Verschreiber sind dadurch ausgeschlossen, Refactoring ist kein Problem.
3. Der Code bleibt sauber und lesbar, da der ganze Notifikationscode erst nachträglich hinzugefügt wird.

Der nächste Schritt

Ein Kollege von mir hatte die Idee, die Verwendung von PostSharp in Verbindung mit dem MVVM Pattern noch einen Schritt weiter zu treiben. Wir verwenden jetzt ein [ViewModelAspekt] PostSharp Attribut, mit dem die ViewModels versehen werden.

[ViewModelAspect]
public class MyViewModel
{
    private string _name;

    public string Name
    {
        get{ return _name;}
        set{ _name = value;}
    }

    public void Save()
    {
        // do sth.
    }
}

Dieser Aspekt macht folgendes:

• Implementierung von INotifyPropertyChanged
• Für alle public Properties wird im Setter der PropertyChanged Event gefeuert
• Für alle public void Methoden wird eine Command Property erzeugt, welche mit Hilfe des Delegate/Relay Commands wiederum diese Methode aufruft.

Dadurch haben wir es geschafft, den Overhead für die Verwendung des MVVM Patterns sehr gering zu halten. Die nächsten Wochen werden zeigen, ob sich diese Variante bewährt und alle Use Cases damit abgedeckt werden können.

Wie sieht die Struktur einer WPF Anwendung aus, die mit dem Projekttemplate von Visual Studio 2008 erstellt wurde?

Der Screenshot zeigt den Aufbau einer solchen WPF Applikation. Es fallen auf Anhieb zwei Teile auf, die jeweils aus einem XAML File und einem C# File bestehen:

• App.* – beschreiben das Applikationsobjekt
• Window1.* – beschreiben das Hauptfenster der Applikation

Und, wie nicht anders zu erwarten, läuft das Programm wenn F5 im Studio gedrückt wird. Aber was passiert hier? Dazu werfen wir einen Blick auf den Sourcecode.

XAML File für das Haupfenster

<Window x:Class="WpfApplication.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Grid>
    </Grid>
</Window>

Hier gibt es nichts spektakuläres zu sehen. Es wird ein Objekt vom Typ Window definiert, ein paar Eigenschaften wie Titel, Höhe und Breite angegeben und zwei XML Namespaces eingebunden. Interessant ist der Teil “x:Class=”WpfApplication.Window1”. Mit dem Attribut x:Class wird angegeben, dass zu diesem XAML Code noch ein weiterer Teil, nämlich der C# Teil gehört. “WpfApplication” gibt hierbei den Namespace und “Window1” den Klassennamen an. Ein Blick in das zugehörige C# File zeigt dann auch eine partielle Klasse Window1.

C# File für das Hauptfenster

using System.Windows;

namespace WpfApplication
{
    /// <summary>
    /// Interaction logic for Window1.xaml
    /// </summary>
    public partial class Window1 : Window
    {
        public Window1()
        {
            InitializeComponent();
        }
    }
}

Bei einem frisch erstellten Projekt ist diese Code-Behind Datei bis auf den Aufruf von “InitializeComponent()” ziemlich leer (die überflüssigen “using” Anweisungen habe ich gleich vom Resharper entfernen lassen).

XAML File für die Applikation

<Application x:Class="WpfApplication.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    StartupUri="Window1.xaml">
    <Application.Resources>
    </Application.Resources>
</Application>

Der Aufbau ist ähnlich wie bei dem Window. Hier taucht erstmals eine Verbindung zwischen der Applikation und dem Fenster auf, indem das StartupUri Attribut auf den Dateinamen des XAML Files des Fensters gesetzt wird.

C# File für die Applikation

using System.Windows;

namespace WpfApplication
{
    /// <summary>
    /// Interaction logic for App.xaml
    /// </summary>
    public partial class App : Application
    {
    }
}

Hier herrscht gähnende Leere. Die partielle Klasse des Applikationsobjektes ist komplett leer. Jetzt stellt sich die Frage, wo denn die “Main” Methode unserer Applikation ist. Irgendwie muss die Anwendung ja gestartet werden. Hier hilft uns der “Show All Files” Button im Solution Explorer weiter:

Jetzt werden auch alle temporären Dateien angezeigt, die während des Kompiliervorgangs entstanden sind. Aus dieser Vielzahl sehen wir uns ein File ein bisschen genauer an:

App.g.cs

Das ‘g’ im Dateinamen steht für “generated”. Es handelt sich hier also um einen generierten Teil der Applikationsklasse. Ich picke mal den interessanten Teil heraus:

...
public void InitializeComponent() {

    #line 4 "..\..\App.xaml"
    this.StartupUri = new System.Uri("Window1.xaml", System.UriKind.Relative);

    #line default
    #line hidden
}

/// <summary>
/// Application Entry Point.
/// </summary>
[System.STAThreadAttribute()]
[System.Diagnostics.DebuggerNonUserCodeAttribute()]
public static void Main() {
    WpfApplication.App app = new WpfApplication.App();
    app.InitializeComponent();
    app.Run();
}
...

Et voilà, hier findet sich auch eine Main() Methode welche den Einstiegspunkt für das Programm darstellt. In InitializeComponent() findet sich auch wieder die StartupUri Eigenschaft, die in App.xaml gesetzt wurde. Durch das setzen dieser Eigenschaft wird das von der URI referenzierte Fenster beim Start der Applikation angezeigt und als dessen Hauptfenster gesetzt (ist also über Application.Current.MainWindow erreichbar).

Auch wenn es den erfahrenen WPF Entwickler vielleicht gelangweilt haben mag – ich finde solche Grundlagen wichtig. Eventuell war ja für den einen oder anderen WPF Einsteiger etwas Neues/Interessantes dabei.

Achtung, das folgende Beispiel bringt wahrscheinlich keinen Nutzen für den täglichen Umgang mit WPF!

EGAL! Manchmal muss man eben auch spielen . Rahmenlose Fenster sind einfach cool. Wenn dann auch noch ein guter Designer mit im Spiel ist, sieht das Ganze auch besser aus als bei meinem Versuch.

Ok, Design beiseite. Was ist zu tun um eine Anwendung mit einem rahmenlosen Fenster zu erstellen?

Der erste Schritt besteht darin, an dem Fenster der Applikation drei Eigenschaften entsprechend zu setzen:

• AllowsTransparency auf true
• WindowStyle auf None – in Verbindung mit AllowsTransparency=”True” wird erreicht, dass der Fensterrahmen und die Titelzeile verschwinden
• Background auf Transparent

  <Window x:Class="NonRectShapedWindowWPF.Window1"
      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
      Width="215"
      Height="215"
      AllowsTransparency="True"
      WindowStyle="None"
      Background="Transparent">
  ...

  In meinem Beispiel habe ich mich dazu entschieden das UI aus zwei Kreisen zusammenzusetzen. Der grosse Kreis dient als “Hauptrahmen” der Anwendung und der kleine Kreis enthält einen “Close” Button.

...
<Grid Height="200" Width="200">
    <Ellipse Fill="Red" Stroke="DarkRed"
             MouseLeftButtonDown="OnCircleMouseLeftButtonDown">
        <Ellipse.BitmapEffect>
            <OuterGlowBitmapEffect GlowSize="8" GlowColor="OrangeRed" />
        </Ellipse.BitmapEffect>
    </Ellipse>

    <Canvas...>

    <Button Margin="150 -150 0 0"
            Template="{StaticResource closeButton}"
            FontFamily="Webdings"
            FontWeight="Bold"
            FontSize="10"
            Content="r"
            Click="OnCloseButtonClick"
            ToolTip="Close">
    </Button>
</Grid>
...

Der eigentliche Inhalt der Anwendung versteckt sich in dem zusammengeklappten <Canvas> Element. Die Details dazu gibt es weiter unten.

Wie in dem XAML Code zu sehen ist, wird der “Close” Button über die Margin Eigenschaft an der gewünschten Stelle positioniert. Um dem Button ein rundes Aussehen zu verpassen, habe ich ein ControlTemplate erstellt.

...
<ControlTemplate x:Key="closeButton" TargetType="{x:Type Button}">
    <Grid>
        <Ellipse Fill="Red" Stroke="DarkRed"
                 Width="25" Height="25"/>

        <Label Content="{TemplateBinding Content}"
               Foreground="Black"
               HorizontalAlignment="Center" VerticalAlignment="Center"/>
    </Grid>
</ControlTemplate>
...

Um dem Anwender ein Verschieben des Fensters zu ermöglichen, fügt man einen Eventhandler für das MouseLeftButtonDown Event hinzu. Und zwar an dem Element, mit dem das Fenster verschoben werden soll. Das könnte z.B. eine eigene Titelleiste sein, oder wie bei mir irgendein anderes, sichtbares Element. Der Code in dem Eventhandler ist sehr einfach:

private void OnCircleMouseLeftButtonDown(object sender, MouseButtonEventArgs e)
{
    DragMove();
}

Ein weiterer Eventhandler wird für das Click Event unseres “Close” Buttons benötigt um das Fenster zu schliessen:

private void OnCloseButtonClick(object sender, RoutedEventArgs e)
{
    Close();
}

Damit sind die wichtigsten Schritte gemacht, um ein rahmenloses Fenster mit WPF zu erstellen. Es kann vom Anwender verschoben und geschlossen werden. Um ein bisschen Action in das Beispiel zu bringen, gibt es noch eine kleine Animation, die Text durch das Fenster scrollen lässt. Der Code dazu sieht so aus:

...
<Canvas Height="100" Width="120" ClipToBounds="True">
    <TextBlock x:Name="_text"
               Height="100" Width="120"
               VerticalAlignment="Center" HorizontalAlignment="Center"
               TextWrapping="Wrap"
               FontFamily="Tahoma" FontSize="12">
            <TextBlock.Text>
                Diese Anwendung ist völlig sinnlos. Zu nichts zu gebrauchen. Und doch hat es viel Spass
                gemacht sie zu erstellen.
            </TextBlock.Text>
            <TextBlock.Triggers>
                <EventTrigger RoutedEvent="TextBlock.Loaded" >
                  <BeginStoryboard>
                    <Storyboard>
                      <DoubleAnimation
                        Storyboard.TargetName="_text"
                        Storyboard.TargetProperty="(Canvas.Top)"
                        Duration="0:0:4"
                        From="110" To="-80"
                        RepeatBehavior="Forever"/>
                    </Storyboard>
                    </BeginStoryboard>
                </EventTrigger>
            </TextBlock.Triggers>
    </TextBlock>
</Canvas>
...

Das komplette Beispiel kann hier heruntergeladen werden:

Validation Rules

Hier eine Übersicht der eingebauten Validation Rules:

Validation Rules werden direkt am Binding angegeben. Für die beiden mitgelieferten Rules gibt es zwei Möglichkeiten diese zu aktivieren.

Einmal über die Eigenschaft ValidationRules:

...
<TextBox.Text>
    <Binding Source="{StaticResource cd}"
             Path="Year"
             UpdateSourceTrigger="PropertyChanged">
        <Binding.ValidationRules>
            <ExceptionValidationRule/>
            <DataErrorValidationRule/>
        </Binding.ValidationRules>
    </Binding>
</TextBox.Text>
...

Oder explizit über die beiden Eigenschaften ValidatesOnExceptions und ValidatesOnDataErrors:

...
<TextBox.Text>
    <Binding Source="{StaticResource cd}"
             Path="Year"
             UpdateSourceTrigger="PropertyChanged"
             ValidatesOnExceptions="True"
             ValidatesOnDataErrors="True">
    </Binding>
</TextBox.Text>
...

WPF teilt uns mit, dass ein ungültiger Wert eingegeben wurde, indem ein roter Rahmen um die TextBox gezeichnet wird. Das ist die Standardvisualisierung von WPF um Validierungsfehler anzuzeigen.

ErrorTemplates

Mit Hilfe eines eigenen ErrorTemplates ist es möglich, dem Anwender eine hilfreichere Visualisierung für Eingabefehler zu bieten. Das könnte z.B. so aussehen:

Aha, zumindest wird jetzt ein erklärender Text angezeigt. Die Wortwahl gefällt mir noch nicht besonders, was daran liegt, dass einfach nur der Exceptiontext der gefangenen FormatException angezeigt wird. Das werden wir später ändern. Wie sieht nun das ErrorTemplate aus?

...
<ControlTemplate x:Key="TextBoxErrorTemplate">
    <DockPanel>
        <TextBlock Margin="0 0 5 0"
                   Text="!"
                   FontSize="14"
                   FontWeight="Bold"
                   Foreground="Red"/>

        <AdornedElementPlaceholder x:Name="adornedElement"/>

        <TextBlock Text="{Binding ElementName=adornedElement,
                                  Path=AdornedElement.(Validation.Errors),
                                  Converter = {local:ValidationErrorToErrorMessageConverter}}"
                   FontSize="12"
                   Foreground="Red"
                   Margin="5 0 0 0"/>
    </DockPanel>
</ControlTemplate>
...

Im Mittelpunkt steht das zu dekorierende Element (in diesem Fall die TextBox). Über das Tag AdornedElementPlaceholder bestimmt man, an welcher Stelle im Template dieses Element platziert werden soll. Mit Hilfe eines DockPanels wird zuerst das rote Ausrufezeichen, dann die TextBox und zum Schluss noch ein TextBlock mit dem Fehlertext angezeigt. Der Fehlertext wird über Databinding von der Attached Property Validation.Errors der TextBox geholt. Das Databinding System fügt dieser Liste ein ValidationError Objekt hinzu, wenn eine Validation Rule einen Fehler zurückgibt.

Zusätzlich wird hier noch ein Value Converter verwendet. Dieser bringt die Fehler aus der Liste der ValidationErrors in ein lesbares Format (siehe hierzu auch Josh Smith’s Post für eine andere Variante). Der Code hierzu sieht so aus:

[ValueConversion(typeof(ReadOnlyObservableCollection<ValidationError>), typeof(string))]
public class ValidationErrorToErrorMessageConverter : MarkupExtension, IValueConverter
{
    private ValidationErrorToErrorMessageConverter _mySelf;

    public override object ProvideValue( IServiceProvider serviceProvider )
    {
        if (_mySelf == null)
        {
            _mySelf = new ValidationErrorToErrorMessageConverter();
        }
        return _mySelf;
    }

    public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
    {
        ReadOnlyObservableCollection<ValidationError> errors =
            value as ReadOnlyObservableCollection<ValidationError>;

        StringBuilder errorMessage = new StringBuilder();
        if(null != errors)
        {
            foreach (var error in errors)
            {
                errorMessage.AppendLine(error.ErrorContent.ToString());
            }

            return errorMessage;
        }

        return errorMessage;
    }

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}

Der Value Converter leitet sich zusätzlich noch von MarkupExtension ab. Dadurch ist es nicht mehr nötig den Converter als Ressource anzugeben, sondern dieser kann direkt über die Markupextension Syntax verwendet werden (danke an Dr. WPF für diesen Tipp).

Das ErrorTemplate wird der TextBox folgendermaßen bekanntgemacht gemacht (siehe Zeile 5):

...
<TextBox ToolTip="Please enter year of release"
         Width="60"
         Margin="10"
         Validation.ErrorTemplate="{StaticResource TextBoxErrorTemplate}">
    <TextBox.Text>
        <Binding Source="{StaticResource cd}"
                 Path="Year"
                 UpdateSourceTrigger="PropertyChanged"
                 ValidatesOnExceptions="True">
        </Binding>
    </TextBox.Text>
</TextBox>
...

Selbstgeschriebene Validation Rules

Zusätzlich zu den mitgelieferten Validation Rules hat man natürlich die Möglichkeit eigene Rules zu implementieren. Dazu wird die eigene Klasse von ValidationRule abgeleitet und die Methode Validate implementiert. Eine Validation Rule um zu prüfen, ob in unserem Beispiel die eingegebene Jahreszahl innerhalb des gewünschten Zeitraums ist, könnte so aussehen:

public class NumberInRangeValidationRule : ValidationRule
{
    public int MaxValue { get; set; }
    public int MinValue { get; set; }

    public override ValidationResult Validate(object value, CultureInfo cultureInfo)
    {
        Debug.WriteLine("entering NumberInRangeValidationRule.Validate");

        // InvalidCast Exception is wanted if this rule is used the wrong way.
        int intValue = (int)value;

        if( intValue < MinValue || intValue > MaxValue )
        {
            return new ValidationResult(false,
                                        string.Format("Please enter a number between {0} and {1}.",
                                                      MinValue, MaxValue));
        }

        return ValidationResult.ValidResult;
    }
}

Diese Validation Rule bietet die Möglichkeit über zwei Eigenschaften den gewünschten Wertebereich anzugeben. In der Validate Methode wird dann überprüft, ob der eingegebene Wert innerhalb dieses Bereichs ist. Ist das nicht der Fall, wird ein ValidationResult mit einem entsprechenden Text zurückgegeben. Warum aber der Test, ob der übergebene Wert vom Typ int ist (Zeile 10)? Schauen wir uns mal an, wie diese Rule im XAML verwendet wird:

...
<TextBox.Text>
    <Binding Source="{StaticResource cd}"
             Path="Year"
             UpdateSourceTrigger="PropertyChanged"
             ValidatesOnExceptions="True">
        <Binding.ValidationRules>
            <local:NumberInRangeValidationRule MinValue="1980"
                                               MaxValue="2009"
                                               ValidationStep="ConvertedProposedValue"/>
        </Binding.ValidationRules>
    </Binding>
</TextBox.Text>
...

Ab .Net 3.5 SP1 gibt es die Eigenschaft ValidationStep an der Klasse ValidationRule. Darüber kann man angeben, zu welchem Zeitpunkt während des Databindingvorganges die Validierung erfolgen soll. Es stehen vier Möglichkeiten zur Auswahl:

1. RawProposedValue – Das ist der Defaultwert. Die Validierung wird vorgenommen bevor der Wert konvertiert wird. In dem Beispiel mit der TextBox muss damit ein String validiert werden (die Text Eigenschaft ist vom Typ String).
2. ConvertedProposedValue – Bei dieser Einstellung wird der konvertierte Wert validiert. Im Beispiel also ein Integer.
3. UpdatedValue – Die Validierung erfolgt nachdem die Quelle aktualisiert wurde.
4. CommittedValue – Die Validierung erfolgt nachdem der Wert an die Quelle übergeben wurde.

Die letzten beiden Optionen sind mir ein bisschen suspekt. Mir ist kein Anwendungsfall eingefallen und der Unterschied zwischen beiden ist mir auch nicht klar.

Die oben gezeigte NumberInRangeValidationRule arbeitet auf Integer Werten, weshalb ich “ConvertedProposedValue” als ValidationStep angegeben habe. Bei der Implementierung ist eine InvalidCastException gewollt, damit eine falsche Benutzung sofort bemerkt wird.

So, jetzt fehlt nur noch ein schönerer Text für den Fall, dass keine Zahl sondern irgendwas anderes eingegeben wird. Dazu schreiben wir noch eine IsValidIntegerValidationRule:

public class IsValidIntegerValidationRule : ValidationRule
{
    public override ValidationResult Validate( object value, System.Globalization.CultureInfo cultureInfo )
    {
        Debug.WriteLine( "entering IsValidIntegerValidationRule.Validate" );
        string inputString = value as string;

        if (null != inputString)
        {
            int inputNumber;
            if( false == int.TryParse(inputString, out inputNumber ) )
            {
                return new ValidationResult( false, "Please enter a valid number." );
            }
        }

        return ValidationResult.ValidResult;
    }
}

Für diese Validation Rule belassen wir den ValidationStep beim Default, also “RawProposedValue”. Damit sieht die finale Konfiguration für das Databinding so aus:

...
<TextBox ToolTip="Please enter year of release"
         Width="60"
         Margin="10"
         Validation.ErrorTemplate="{StaticResource TextBoxErrorTemplate}">
    <TextBox.Text>
        <Binding Source="{StaticResource cd}"
                 Path="Year"
                 UpdateSourceTrigger="PropertyChanged">
            <Binding.ValidationRules>
                <local:NumberInRangeValidationRule MinValue="1980"
                                                   MaxValue="2009"
                                                   ValidationStep="ConvertedProposedValue"/>
                <local:InputMustBeIntegerValidationRule ValidationStep="RawProposedValue"/>

            </Binding.ValidationRules>
        </Binding>
    </TextBox.Text>
</TextBox>
...

Uns so sieht das Ganze dann im UI aus:

Jetzt gibt es noch ein Problem, für das ich bisher noch keine zufriedenstellende Lösung gefunden habe. Beim Start der Anwendung wird über das TwoWay Binding der Initiale Wert aus der Quelle geholt. Dieser Wert ist bei einem Integer 0. Der Wert 0 liegt nicht im Wertebereich der NumberInRangeValidationRule, es wird aber keine Validierungsmeldung angezeigt. Es sieht so aus, also ob die Validierung nur von Ziel zu Quelle durchgeführt wird. Hier bin ich für Ideen bzw. Lösungsvorschläge sehr dankbar.

Der nächste Post zum Thema Validierung mit WPF widmet sich dem IDataErrorInfo Interface. Die Unterstützung dafür wurde mit .Net 3.5 SP1 in WPF eingeführt. Ich bin gespannt.

Das komplette Beispiel kann hier heruntergeladen werden:

Zur Verdeutlichung soll folgendes UI dienen:

Die TextBox für den Username ist über Databinding an die “Username” Eigenschaft des ViewModels angebunden. Bei dem Ok Button ist “IsDefault” auf True gesetzt. Mit Hilfe einiger Traces kann man im Ausgabefenster des Visual Studio sehen, was vom Benutzer eingegeben wurde.

...
public string Username
{
    get { return _userName; }
    set
    {
        _userName = value;
        Trace.WriteLine(string.Format("Username {0} entered.", _userName));
    }
}
...
private void OnOkCommand()
{
    Trace.WriteLine("Ok button pressed.");
    Trace.WriteLine(string.Format("Current username {0}", _userName));

}
...

Bei einer TextBox die per Databinding angebunden ist, wird die Quelle per Default bei Verlust des Fokus aktualisiert. D.h. die Eigenschaft “UpdateSourceTrigger” des Bindings hat den Wert “LostFocus”. Scheinbar wird beim Auslösen eines Defaultbuttons der Fokus nicht auf diesen Button gesetzt. Es wird dann zwar das Command ausgeführt welches mit dem Button verknüpft ist, aber die Quelle der TextBox wurde nicht aktualisiert.

Es gibt mehrere Möglichkeiten das Problem zu lösen.

1. Durch Setzen der “UpdateSourceTrigger” Eigenschaft am Binding auf “PropertyChanged”. Dadurch wird die Quelle bei jeder Veränderung aktualisiert.
2. Durch manuelles Setzen des Fokus im Click-Eventhandler des Buttons
3. Durch manuelles Aktualisieren des Bindings im Click-Eventhandler des Buttons

Bei Variante zwei muss der entsprechende Code in die Code-Behind Datei der View verlagert werden, da ein direkter Zugriff auf das Button Control notwendig ist:

private void OnOkButtonClick(object sender, RoutedEventArgs e)
{
    FocusManager.SetFocusedElement(this, (Button)sender);
}

Den Code für die dritte Lösung könnte man (technisch) auch ins ViewModel packen. Gefällt mir aber nicht, da ich im ViewModel keine Kenntnis von UI Controls haben möchte. Deshalb kommt auch hier die Code-Behind Datei zu Zuge:

private void OnOkButtonClick(object sender, RoutedEventArgs e)
{
    TextBox focusedTextBox = Keyboard.FocusedElement as TextBox;
    if( null != focusedTextBox )
    {
        BindingExpression bindingExpression = focusedTextBox.GetBindingExpression(TextBox.TextProperty);
        if (null != bindingExpression)
        {
            bindingExpression.UpdateSource();
        }
    }
}

Bisher gefällt mir die zweite Variante am Besten. Mir sind auch noch keine Nachteile oder Probleme aufgefallen. Den “richtigen” Code, der beim Auslösen des Defaultbuttons ausgeführt werden soll, kann man im ViewModel lassen. Das Command welches mit dem Button verknüpft ist, wird erst nach dem Click Event ausgeführt.

Weiss zufällig jemand, ob es diesen Effekt mit dem Defaultbutton und LostFocus auch unter WinForms gibt?

• KAXAML – Ein super XAML Editor, mit dem mal schnell mal was ausprobieren kann ohne gleich das Visual Studio zu starten. Er bietet ein geteiltes Fenster, so dass der XAML Code und das gerenderte Ergebnis auf einem Blick zu sehen sind. Syntax-Highlighting und Codevervollständigung gehören auch zum Funktionsumfang. In der aktuellen Beta Version wird auch Silverlight 2 unterstützt.
• Snoop – Snoop könnte man als “Visual Debugger” bezeichnen. Das Tool kann sich zur Laufzeit an eine WPF Anwendung “attachen” und zeigt dann den Visual Tree derselben an. Dort lassen sich z.B. Properties verändern und Routed Events verfolgen. Wie man Databindingprobleme mit Snoop findet, habe ich hier beschrieben.
• ShowMeTheTemplate – Zeigt die Templates (ControlTemplate, DataTemplate und ItemsPanelTemplate) für alle mit WPF ausgelieferten Controls an. Auf MSDN gibt es auch Beispiele für ControlTemplates: “Control Template Examples”.
• Crack.Net – Crack.Net ist zwar kein Tool das speziell für WPF entwickelt wurde, es wurde aber mit WPF entwickelt. Ähnlich wie Snoop “attached” sich Crack.Net an eine laufende .Net Anwendung. Es ist möglich, den managed Heap der Applikation zu untersuchen, Objekte können direkt verändert werden und mit IronPython ist sogar Scripting Support vorhanden. Der Entwickler Josh Smith hat hier konsequent das M-V-VM Pattern verwendet. Ein Blick auf den Sourcecode kann hier nicht schaden.
• Performance Profiling Tools for WPF – Sammlung von fünf Tools von Microsoft, die helfen sollen Performanceprobleme bei WPF Anwendungen zu finden bzw. zu vermeiden. Mit dem enthaltenen Visual Profiler lässt sich auch mal schnell ein Performancevergleich zwischen zwei Rechnern machen.
• Mole – Ein Visualizer für Visual Studio mit dem während des Debuggens nicht nur sämtliche Eigenschaften eines Objekts editiert werden können, sondern bei WPF Anwendungen auch der Logical/Visual Tree betrachtet werden kann.
• Dr. WPF’s Code Snippets – sind zwar kein Tool, aber auch sehr hilfreich. Momentan sind Snippets für Dependency Properties, Routed Commands und Routed Events enthalten. Wer selber Code Snippets schreibt, findet mit dem Snippet Editor einen Helfer.
• Microsoft Expression Blend – Das Design Tool für WPF und Silverlight (mit SP1 für Expression Blend). Bisher habe ich es nur rudimentär verwendet. Ich glaube aber, dass es auch für Entwickler sehr hilfreich ist, dieses Tool zumindest in den Grundzügen zu beherrschen.

Tools können sehr hilfreich sein, sind aber natürlich kein Allheilmittel! Bei vielen Problemen kann es auch helfen, einfach einen Kollegen über den Code schauen zu lassen.

Welche Tools verwendet ihr bei der WPF Entwicklung?

In der Assembly DataTemplateDemo gibt es eine Klasse Data:

namespace DatatemplateDemo
{
    public class Data
    {
        private string _name;

        public Data(string name)
        {
            _name = name;
        }

        public string Name
        {
            get { return _name; }
        }
    }
}

Im UI wird ein DataTemplate für diesen Typ definiert:

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

    <Window.Resources>
        <DataTemplate x:Key="DataTemplate_Data" DataType="{x:Type local:Data}">
            <StackPanel Orientation="Horizontal">
                <TextBlock Margin="2" Text="Name: "/>
                <TextBlock Margin="2" Text="{Binding Path=Name}"/>
            </StackPanel>
        </DataTemplate>

    </Window.Resources>

    <Grid>
        <ListBox x:Name="_listBox" ItemTemplate="{StaticResource DataTemplate_Data}"/>
    </Grid>
</Window>

Wenn man nun versucht diesen Code zu übersetzen wird man mit dieser Fehlermeldung konfrontiert:

error MC3066: The type reference cannot find a public type named ‘Data’. Line 8 Position 80.

Nach einigem Rumprobieren hat sich herausgestellt, dass die Übersetzung wunderbar klappt, wenn bei der Deklaration des XML Namespace die Assembly weggelassen wird:

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

    ...

</Window>

Der Fehler tritt nicht nur mit DataTemplates auf, sondern z.B. auch wenn man einen Style definiert und der TargetType entsprechend angegeben wird.

Ich merke mir: wenn ein Namespace aus einem lokalen Assembly in ein XAML File mit xmlns importiert wird, gebe ich den “assembly” Parameter NICHT mit an! Vielleicht erspart die Info ja dem einen oder anderen die Fehlersuche. Ach ja, das Intellisense des Visual Studio macht es automatisch so und gibt den “assembly” Parameter nicht mit an, wenn der importierte CLR Namespace im gleichen Assembly liegt.

• Bindings können sowohl in XAML als auch im Code erzeugt werden.
• Konvertierung von Daten. Über sog. Value Converter ist es möglich, die Daten die von der Quelle kommen anzupassen bzw. zu verändern.
• Data Templates – mit Data Templates kann man die Visualisierung der Daten festlegen.
• Data Validation – wie unterstützt mich WPF bei der Validierung der vom Benutzer eingegebenen Daten?

Um Data Validation soll es in den nächsten Posts gehen. Ich kann leider keine Weisheiten zu dem Thema bieten, sondern möchte vielmehr meinen Lernprozess (mit)teilen. In mehreren Postings nähere ich mich Schritt für Schritt dem Thema. Danach wissen wir hoffentlich alle ein bisschen mehr über Databinding und Data Validation mit WPF.

Um erst mal die Grundlagen zu verstehen, fange ich ganz klein an. So klein, dass es mir schon fast zu klein vorkommt… aber nur fast. So sieht das Fenster der Testanwendung aus:

Das zugehörige XAML ist auch ganz einfach:

<Window x:Class="DataValidationWPF.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="clr-namespace:DataValidationWPF"
    Title="Data validation with WPF"
    Height="130" Width="300">

    <Window.Resources>
        <local:CompactDisc x:Key="cd" />
    </Window.Resources>

    <StackPanel>
        <TextBlock Text="Please enter a value between 1980 and 2009"
                   Margin="10"/>
        <StackPanel Orientation="Horizontal">
            <TextBlock Text="Year:" Margin="10" />
            <TextBox ToolTip="Please enter year of release"
                     Width="60"
                     Margin="10"
                     Text="{Binding Source={StaticResource cd},
                            Path=Year,
                            Mode=TwoWay,
                            UpdateSourceTrigger=PropertyChanged}"/>
        </StackPanel>
    </StackPanel>
</Window>

Als Datenklasse muss wieder die CompactDisc herhalten. Diesmal total abgespeckt in ihrer Minimalausführung:

public class CompactDisc
{
    private int _year;

    public int Year
    {
        get
        {
            Debug.WriteLine("Get year: " + _year);
            return _year;
        }

        set
        {
            _year = value;
            Debug.WriteLine("Set year to: " + _year);
        }
    }
}

Es wird also die “Year” Eigenschaft einer Instanz der CompactDisc Klasse an die “Text” Eigenschaft einer TextBox im UI gebunden. Als Mode für die Bindung habe ich “TwoWay” angegeben. D.h. der Datenaustauch erfolgt in beide Richtungen. Nach dem Starten der Applikation wird direkt der Wert ‘0’ in der TextBox angezeigt. 0 ist der Default Wert für den Typ int. Das TwoWay Binding funktioniert also. Selbst bei diesem einfachen Beispiel passiert schon einiges unter der Databinding Haube. Damit überhaupt ein Integer Wert in einer TextBox angezeigt werden kann, durchläuft dieser eine implizite Konvertierung zu einem String.

Zu Diagnosezwecken wurden im Setter und Getter der Eigenschaft jeweils eine Debugausgabe eingebaut. Damit kann man dann im Output Fenster des Visual Studios sehen, ob überhaupt etwas geändert wurde. Um auch wirklich alle Änderungen, die im UI in der TextBox gemacht werden mitzubekommen, habe ich die Eigenschaft “UpdateSourceTrigger” auf den Wert “PropertyChanged” gesetzt. Das bewirkt, dass die Quelle des Bindings (die Year Eigenschaft) aktualisiert wird, sobald in der TextBox editiert wird. Los geht’s. Applikation im Debug Modus aus dem Visual Studio starten und die Debug Ausgaben im Auge behalten.

Sobald die ‘0’ aus der TextBox gelöscht wird, taucht auch schon die erste Fehlermeldung im Output Fenster auf:

A first chance exception of type ‘System.FormatException’ occurred in mscorlib.dll

A first chance exception of type ‘System.Reflection.TargetInvocationException’ occurred in mscorlib.dll

A first chance exception of type ‘System.FormatException’ occurred in mscorlib.dll

System.Windows.Data Error: 7 : ConvertBack cannot convert value ” (type ‘String’). BindingExpression:Path=Year; DataItem=’CompactDisc’ (HashCode=59835590); target element is ‘TextBox’ (Name=”); target property is ‘Text’ (type ‘String’) FormatException:’System.FormatException: Input string was not in a correct format.

   at System.Number.StringToNumber(String str, NumberStyles options, NumberBuffer& number, NumberFormatInfo info, Boolean parseDecimal)

   at System.Number.ParseInt32(String s, NumberStyles style, NumberFormatInfo info)

   at System.String.System.IConvertible.ToInt32(IFormatProvider provider)

   at System.Convert.ChangeType(Object value, Type conversionType, IFormatProvider provider)

   at MS.Internal.Data.SystemConvertConverter.ConvertBack(Object o, Type type, Object parameter, CultureInfo culture)

   at System.Windows.Data.BindingExpression.ConvertBackHelper(IValueConverter converter, Object value, Type sourceType, Object parameter, CultureInfo culture)’

The thread 0xf44 has exited with code 0 (0×0).

Bei der impliziten Konvertierung gibt es eine FormatException. Die Anwendung läuft trotzdem ohne Probleme weiter. Offensichtlich wird die Exception vom Databinding System geschluckt. Man sieht auch, dass der Setter der Year Eigenschaft nicht aufgerufen wird. Bisher bekommen wir also in unserem Code nichts mit und haben dadurch auch nicht die Möglichkeit dem Benutzer einen entsprechenden Hinweis zu geben (z.B. eine Meldung “Year must not be empty”). Aber hier soll uns ja Data Validation weiterhelfen. Wird eine gültige Zahl in die TextBox eingegeben läuft alles nach Plan, der Setter wird aufgerufen und das Datenobjekt ist auf Stand.

So, das war’s für den ersten Teil. Man sieht, dass selbst bei so einfachen Anwendungen mit Databinding eine Menge passiert. Ich bin gespannt, was WPF bzgl. Validierung für uns Entwickler bereithält.