In Wpf kann man einem Binding einen Konverter mitgeben.
Das wird hier genutzt, um Messwerte in einem Datagrid mit Farbwerten zu hinterlegen - also der Konverter muss aus den Messwerten einen SolidColorBrush "berechnen".


Die Konversion erfolgt natürlich anhand von Schwellwerten - dafür habe ich ja an annerer Stelle das ThresholdDictionary erfunden
Hier, wie es instanziert, mit 8 Farb-Brushes und 7 Schwellwerten "beschickt" wird:

Aber ihr wolltet ja sicherlich den DelegateConverter sehen - wenn das man keine Enttäuschung wird:Ein Dingsbums, welches IValueConverter implementiert, und 2 DependancyProperties hat - sonst nichts. Getan wird hier eiglich nichts, aber das Ding heißt DelegateConverter, eben weils nix selber tut, sondern die Tätigkeiten delegiert.
Also was es tut ist Konvertieren (mit der Convert()-Methode) und Zurück-Konvertieren (mit der ConvertBack()-Methode - potzblitz!).
Convert() und ConvertBack() sind Bestandteile der IValueConverter-Schnittstelle - vom Framework so vorgegeben.
Einem Binding, was Konvertierung unterstützen soll, kann man ein beliebiges Dingsbums als Converter zuweisen - hauptsache, das Dingsbums implementiert IValueConverter - dann kann das Binding nämlich Convert() und ConvertBack() aufrufen, wenn ihm danach ist
Also nochmal genau DelegateConverter angeguckt: Es gibt die Property Conversion As Func(Of Object, Object), also eine Function, die ein Object entgegennimmt, und ein Object zurückgibt.
Und es gibt den Schnittstellen-Member Convert(), welcher auch ein Object entgegennimmt (und noch 2 weitere Argumente), und ein Object zurückgibt.
Und dieses Convert() tut nix anneres (Zeile#32), als die in Conversion gespeicherte Function aufzurufen, mit value als Argument, und davon das Ergebnis returnen.

Das ViewModel
Hier das bahnbrechende ViewModel, mit all seinen Properties, weil an was anneres als an Properties kann Xaml leider nicht binden:Wir haben hier 5 Public Properties vorliegen (nicht, dass eine übersehen wird ;)).

1. Public Property Measures As MeasureDts
   ein typisiertes Dataset mit Messwerten
   
2. Public Property ReLoad As RelayCommand
   ein Command zum Laden
   
3. Public Property Save As RelayCommand
   ein Command zum Speichern (kommt euch das eiglich nicht blöd vor, wenn ich erkläre, dass das Save-Commad zum Speichern ist? ;))
   
4. Public Property GenerateRandom As RelayCommand
   ein Command zum Generieren von Zufalls-Werten
   
5. Public Property ColorConversion As Func(Of Object, Object)
   eine anonyme Function, die ein Object in ein anneres konvertiert (nämlich einen Double in einen SolidColorBrush).
   

RelayCommand kennt ihr ja evtl. schon aus einem anneren Wpf-Tut: Das ist ein Objekt mit einer Aktion und optional auch einer Funktion, die ansagt, ob die Aktion ühaupt möglich ist.
Tatsächlich habe ich das DelegateConverter-Konzept von RelayCommand abgeguckt, weil die tun ja auch nix, ausser die eigentlichen Tätigkeiten an Delegaten zu delegieren (und man fragt sich, warum sie RelayCommand heißen, anstatt DelegateCommand).
Guggemol das Save-Command genau an:Da werden im Konstruktor doch gleich zwei Delegaten übergeben:

1. eine anonyme Action
   

   VB.NET-Quellcode

   1. Sub()
   2. Measures.WriteXml(_DataFile.FullName)
   3. Measures.AcceptChanges()
   4. System.Media.SystemSounds.Asterisk.Play()
   5. End Sub
   
   
2. eine anonyme Func(Of Boolean)
   

   VB.NET-Quellcode

   1. Function() Measures.HasChanges)

Damit sollte für jeden, der lesen kann, ersichtlich sein, dass dieses Save-Command nur dann ausgeführt werden kann, wenn das Measures-Dataset modifiziert wurde (Measures.HasChanges) - und die Ausführung besteht hier aus den drei Schritten:

1. Dataset auf Platte schreiben
   
2. Dataset-Status auf "unmodifiziert" setzen (Measures.AcceptChanges())
   
3. einen "Pling!" - Sound abspielen
   

Aber eiglich gehts hier ja um den DelegateConverter, und wie man dem eine Conversion beibringt, dasser auch konvertieren kann. Jo, man kann ihn einfach an eine Conversion binden - und wir haben ja auch schon eine Conversion: nämlich die ColorConversion ausm MainModel (Post#1, Listing#3, Zeile#38)!
Die ColorConversion tut übrigens auch nicht viel - castet den Wert auf Double und ruft mit diesem Key den entsprechenden SolidColorBrush vom ThresholdDictionary ab.

Ich beschränke mich hier auf die Zeilen 21 und #26-#31, oder besser sogar nur auf #21 und #29:
In #21 wird ein DelegateConverter in den Resourcen angelegt, dessen Conversion an MainModel.ColorConversion gebunden ist
In #29 wird dieser Converter benutzt, um den Background einer DataGridRow an die (MeasureRow).Value-Property des Datensatzes zu binden. Da Value aber Double ist, und kein SolidColorBrush, wird im Binding eben der Converter eingesetzt - der weiß ja, wie man einen Double in einen SolidColorBrush konvertiert

Auf eine traurige Wpf-Kinderkrankheit ist noch in Zeile#20 hingewiesen:
"<!--hier das Binding funzt zwar, läßt sich aber nicht im PropertyFenster setzen -->"
In Binding-Mismatches führe ich aus, dass man sich möglichst immer an den Angeboten des Property-Fensters orientieren soll, weil das wenigstens ein bischen Intellisense bietet.
Aber es ist eben nicht immer möglichst, und warum hier das PropertyFenster die Binding-Auswahl nicht unterstützt, ist ganz unerklärlich.
Denn wenn man dieselbe Resource im Application.Xaml anlegt, dann funzt dort das P-Fenster ganz wunderbar!
Da hat man nun also die Wahl, ohne P-Fenster-Unterstützung unsauber zu coden, oder unsauber zu coden, weil eine Application-weite Sichtbarkeit dieses Converters krass gegen das Kapselungs-Prinzip verstößt.