.Net 2.0

Bild nach Bytearray nach Bild

Sascha — Sun, 29 Jul 2007 12:01:57 GMT

Um binäre Dateien, wie etwa Bilder, über einen Webservice zu senden oder empfangen, kann man sie in ein ByteArray konvertieren.

public byte[] createByteArray(string imageName) 
{
   FileInfo fileInfo = new FileInfo(imageName);
   FileStream fileStream = fileInfo.OpenRead();
   byte[] byteArray = new byte[fileStream.Length];        
   int bytesRead = fileStream.Read(byteArray, 0, fileStream.Length);
   Console.WriteLine("{0} bytes have been read from {1}", 
   bytesRead.ToString(), imageName);
   return byteArray;
}

In die andere Richtung:

public void saveAsImage(byte[] bytes, string imageName) 
{
   MemoryStream memStream = new MemoryStream(bytes);
   System.Drawing.Image image = 
   System.Drawing.Image.FromStream(memStream);
   image.Save(imageName);
   Console.WriteLine("{0} was created successfully.", imageName);
}

ADO.Net und Excel

Sascha — Thu, 05 Jul 2007 19:51:49 GMT

Der Zugriff auf Exceldateien unter .Net 2.0 ist dank ADO.Net erstaunlich einfach. Dazu wird der OleDbProvider verwendet.

string connectionString = @"Provider=Microsoft.Jet.OLEDB.4.0;
    Data Source=D:\Excel\Workbook.xls;Extended Properties=""Excel 8.0;HDR=YES;""";

Dieser ConnectionString enthält den Speicherort der Datei und gibt an, dass die erste Zeile der Worksheets die Spaltennamen enthält.

Nachdem die Connection geöffnet ist, verhält sich alles, wie von ADO.Net gewohnt.
Mit Hilfe der GetSchema() Methode lassen sich Informationen zu den vorhandenen Tabellen (gleich Worksheets) und Spalten abrufen.

using (OleDbConnection connection = new OleDbConnection(connectionString))
{
    connection.Open();

    DataTable tables = connection.GetSchema("Tables");
    DataTable columns = connection.GetSchema("Columns");
}

In den nachfolgenden Screenshots sieht man die jeweilige DataTable mit den Schemainformationen im DataSet-Visualizer des Visual Studio Debuggers. Achtung: Excel hängt für den Tabellenname ein $ an den Namen des Worksheets. Hier: Worksheetname "Studenten" wird zu Tabelle "Studenten$".

Select-Abfragen funktionieren auch mit Parameter und das Ergebnis lässt sich an Steuerelemente binden.

OleDbCommand selectCommand = new OleDbCommand(
    "SELECT [MatrikelNr], [Vorname], [Nachname] FROM [Studenten$] " +
    "WHERE [Nachname] LIKE @Nachname", 
    connection);
selectCommand.Parameters.AddWithValue("Nachname", "A%");

OleDbDataAdapter adapter = new OleDbDataAdapter(selectCommand);

DataTable studenten = new DataTable();
adapter.Fill(studenten);

this.GridView1.DataSource = studenten;
this.GridView1.DataBind();

Auch die Insert- und Update-Commands funktionieren wie erwartet:

OleDbCommand insertCommand = new OleDbCommand(
    "INSERT INTO [Studenten$] ([MatrikelNr], [Vorname], [Nachname]) " +  
    "VALUES (@MatrikelNR, @Vorname, @Nachname)",
    connection);
insertCommand.Parameters.AddWithValue("MatrikelNr", "123459");
insertCommand.Parameters.AddWithValue("Vorname", "Bert");
insertCommand.Parameters.AddWithValue("Nachname", "Becker");
int rowsAffected = insertCommand.ExecuteNonQuery();

Color-Objekt aus einem hexadezimalen Farbcode erzeugen

Sascha — Mon, 02 Jul 2007 15:34:38 GMT

Um ein System.Drawing.Color-Objekt aus einem String mit einem hexadezimalen Farbcode zu erzeugen, muss man den System.Web.UI.WebControls.WebColorConverter verwenden. Ein direktes Erzeugen mit Hilfe des HexCodes im Konstruktor einer neuen Color-Instanz ist nicht möglich.

string hexColor = "#FF8080";
System.Web.UI.WebControls.WebColorConverter converter = 
    new WebColorConverter();
System.Drawing.Color color = 
    (System.Drawing.Color)converter.ConvertFrom(hexColor);
e.Cell.BackColor = color;

In Visual Studio 2005 für das .Net Framework 1.1 entwickeln

Sascha — Wed, 09 May 2007 12:42:51 GMT

Wer mit Visual Studio 2003 gearbeitet hat und die Vorzüge des Entwickelns unter Visual Studio 2005 einmal kennen gelernt hat, möchte eigentlich nicht mehr zurück. Trotzdem gibt es immer noch Projekte, die auf dem .Net Framework 1.1 laufen müssen. Ein Powertoy für Visual Studio 2005 hilft aus diesem Dilemma: MSBee. MSBee ist eine Erweiterung für MSBuild und steht für MSBuild Everett Environment. Everett war der Codename für das .NET Framework 1.1. Mit MSBee kann der Entwickler in Visual Studio 2005 entwickeln und das Projekt dann mit dem .Net Framework 1.1 kompilieren. Das funktioniert soweit auch ganz gut, solange man Codebibliotheken entwickelt. Für Windows Forms oder Asp.Net Seiten können die Visual Studio 2005 Designer nicht verwendet werden, weil diese die Steuerelemente für .Net 2.0 verwenden. Alle anderen Namensräume von .Net 2.0 können natürlich ebenfalls nicht verwendet werden, genauso wie z.B. partielle Klassen oder Generics, die ebenfalls unter .Net 1.1 noch nicht zur Verfügung standen. Auch die Intellisense von Visual Studio 2005 und die Hilfe passen sich nicht an .Net 1.1 an.

Installationsvoraussetzungen für MSBee:

.Net Framework 2.0 (sollte wegen VS 2005 schon vorhanden sein)
.Net Framework 1.1 Redistributable (Runtime) [2]
.Net Framework 1.1 SDK [3]

Um nach der Installation nun ein Projekt in Visual Studio 2005 zum Kompilieren mit dem .Net Framework 1.1 zu konfigurieren, müssen zunächst die MSBee .target Dateien in das Projekt geladen werden. Dazu sind folgende Schritte notwendig:

Das Projekt wie gewohnt erstellen, speichern und wieder schließen.
Anschließend die Projektdatei (.csproj / .vbproj) in Notepad öffnen.

Bei einem C# Projekt:

folgende Zeile kurz vor Dateiende in der .csproj-Datei suchen:
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
Unmittelbar unter dieser Zeile muss folgende Zeile eingefügt werden:
<Import Project="$(MSBuildExtensionsPath)\MSBee\MSBuildExtras.FX1_1.CSharp.targets" />

Bei einem Visual Basic Projekt:

folgende Zeile kurz vor Dateiende der .vbproj-Datei suchen:
<Import Project="$(MSBuildBinPath)\Microsoft.VisualBasic.targets" />
Unmittelbar unter dieser Zeile muss folgende Zeile eingefügt werden:
<Import Project="$(MSBuildExtensionsPath)\MSBee\MSBuildExtras.FX1_1.VisualBasic.targets" />

Wenn das Projekt in Visual Studio wieder geöffnet ist, müssen in den Buildeinstellungen der Projekteigenschaften die Conditional compilation symbols den Wert FX1_1 besitzen.

Nun kann das Projekt kompiliert werden. Dabei wird die .Net Framework Version 1.1 verwendet.

Das Ergebnis kann man überprüfen, indem man die erzeugte DLL mit dem Microsoft .Net Framework IL-Disassembler öffnet (Start / All Programs / Microsoft .NET Framework SDK v2.0 / SDK Command Prompt / Ildasm)

Dort sieht man im Manifest der dll-Datei die Framework-Version, mit der die Datei kompiliert wurde.

[1] MSBee, < 1 MB, http://www.microsoft.com/downloads/details.aspx?FamilyID=e0d0776f-25c4-444a-a6b9-71d06826f5b4&displaylang=en
[2] .Net Framework 1.1 Redistributable (Runtime), 24 MB, http://www.microsoft.com/downloads/details.aspx?familyid=262D25E3-F589-4842-8157-034D1E7CF3A3&displaylang=en
[3] .Net Framework 1.1 SDK, 106 MB, http://www.microsoft.com/downloads/details.aspx?familyid=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en

MemoryStreams verwenden

Sascha — Sat, 03 Mar 2007 13:31:01 GMT

Die MemoryStream-Klasse erstellt Streams, die im Arbeitsspeicher gesichert werden statt zum Beispiel im Dateisystem, wie das bei FileStreams der Fall ist. Eine Anwendung, die bisher viel mit temporären Dateien im Filesystem arbeitet, kann u. U. eine Menge Performance gewinnen, indem sie stattdessen MemoryStreams verwendet. Viele Komponenten, wie z. B. das RichTextBox-Steuerelement, akzeptieren nämlich in ihren Load() und Save() Methoden nicht nur einen Dateinamen, sondern wahlweise auch eine Stream-Instanz. Und hier kann statt einem FileStream auch ein MemoryStream übergeben werden. Das Beispiel hier zeigt die Verwendung eines MemoryStreams mit einem RichTextBox-Steuerelement.

 1 string _rtf = @"{\rtf1\ansi\ansicpg1252\deff0\deflang1031{" +
 2     @"\fonttbl{\f0\fnil\fcharset0 Microsoft Sans Serif;" +
 3     @"}}\viewkind4\uc1\pard\f0\fs17 Hallo Stream\par}";
 4 
 5 // *** RTF-Datei aus Speicher laden ***
 6 // Stream-Objekt als MemoryStream-Objekt erstellen
 7 // Byte-Array Darstellung von String im Konstruktor übergeben
 8 Stream s = new MemoryStream(UTF8Encoding.Default.GetBytes(_rtf));
 9 //Stream an LoadFile() Methode übergeben
10 this.richTextBox1.LoadFile(s, RichTextBoxStreamType.RichText);
11 
12 // *** RTF-Datei in Speicher sichern ***
13 s = new MemoryStream();
14 // Stream an SaveFile() Methode übergeben
15 this.richTextBox1.SaveFile(s, RichTextBoxStreamType.RichText);
16 // Stream in MemoryStream casten, damit ToArray() Methode
17 // aufgerufen werden kann
18 MemoryStream m = (MemoryStream)s;
19 byte[] b = m.ToArray();
20 // Byte-Array in String zurückkonvertieren
21 string t = UTF8Encoding.Default.GetString(b);
22 //ASCIIEncoding.Default.GetString
23 m.Dispose();
24 s.Dispose();

Beim Umwandeln von/ in Byte-Arrays helfen die statischen Methoden der jeweiligen Encoder-Klasse. Um ein ASCII-codiertes Byte-Array zu erstellen, hätte in Zeile 8 die Methode ASCIIEncoding.Default.GetBytes() aufgerufen werden müssen.

Custom Generic Collections oder: Filtern und Sortieren Teil 2

Sascha — Thu, 01 Mar 2007 17:58:23 GMT

Im letzten Post hatte ich eine List<T> mit Hilfe von IComparer<T> und Predicate<T> sortiert bzw. gefiltert. Das hatte so weit auch funktioniert. Das einzige, was mir an dieser Lösung noch nicht gefällt: Wenn ich mich dafür entscheiden sollte, meine MP3-Dateien jetzt nach einem Artist statt nach einem Titel zu filtern, muss ich zuerst eine entsprechende Funktion dazu erstellen, dann das Prädikat erzeugen, was auf diese Funktion zeigt, und dieses dann beim Aufruf der FindAll-Methode verwenden. Das gleiche beim Sortieren. Der vorhandene Mp3Comparer sortiert nur nach Artist. Neue Sortierung, neuer Comparer. Das muss doch einfacher gehen...

Die Lösung bietet Reflection. Zumindest in meinem Fall. Reflection ist Gift für die Performance, so dass man bei großen Listen evtl. ein Problem mit den Laufzeiten der Sort-Methode bekommt, wenn bei der Erstellung der Sortierordnung jedes Listenelement mehrfach mittels Reflection untersucht werden muss.

An den Comparer wird der Name der Eigenschaft übergeben, in der Compare-Methode wird die Eigenschaft und deren Werte per Reflection aus den zu vergleichenden Elementen ermittelt und das Ergebnis des Vergleichs zurückgeliefert.

Der bisherige MP3Comparer ist speziell auf den Vergleich von Instanzen des Typs ID3Tag ausgelegt, da er auf die Eigenschaften Titel und Artist angewiesen ist. Daher war er auch vom Typ IComparer<ID3Tag>. Der neue Comparer, den ich ReflectionComparer getauft habe, ist hingegen für alle Typen geeignet, daher vom Typ IComparer<T>. Der Comparer funktioniert aber nur, wenn der Typ der Eigenschaften, deren Werte verglichen werden sollen, selbst das IComparable Interface implementiert. Für die Standarddatentypen wie String, Int32, etc. ist dies erfüllt.

Der komplette Code für den neuen Comparer sieht nun folgendermaßen aus:

public class ReflectionComparer<T> : IComparer<T>
{
    SortType sortType;
    string sortPropertyName;

    public ReflectionComparer(string sortPropertyName)
    {
        this.sortPropertyName = sortPropertyName;
        this.sortType = SortType.Ascending;
    }

    public ReflectionComparer(string sortPropertyName,
        SortType sortType)
    {
        this.sortPropertyName = sortPropertyName;
        this.sortType = sortType;
    }

    #region IComparer<T> Members
    public int Compare(T x, T y)
    {
        // Mittels Reflection die Werte 
        //der Eigenschaften aus x und y bestimmen
        object valueX = x.GetType().GetProperty(
            sortPropertyName).GetValue(x, null);
        object valueY = y.GetType().GetProperty(
            sortPropertyName).GetValue(y, null);
        
        // Der Typ der Eigenschaft muss IComparable implementieren
        IComparable comparable = (IComparable)valueX;
        // Wert x mit Wert y vergleichen
        return (int)sortType * comparable.CompareTo(valueY);
    }
    #endregion
}

Auf sämtliche Fehlerbehandlung wurde in diesen Beispielen verzichtet. Gerade bei Reflection ist das aber wichtig, weil der Kompiler keinen Fehler meldet, wenn wir nach einem Feld sortieren wollen, das es gar nicht gibt. In der Form kann ich den IComparer wie gehabt an die Sort-Methode von List<T> anhängen. Ich möchte den Aufruf jedoch etwas intuitiver kapseln, so dass ich die Liste mit

id3Tags.Sort("Artist", SortType.Ascending);
id3Tags.Sort("Album", SortType.Descending);

entsprechend sortieren kann. Das heißt, ich muss eine eigene Generic Collection erzeugen. Es wäre jetzt naheliegend, diese CustomGenericCollection von System.Collections.Generic.List abzuleiten. Dies sollte man nach den Empfehlungen von Microsoft jedoch nicht tun, da List<T> eine große Anzahl von öffentlichen Methoden und Eigenschaften besitzt, die in den meisten Szenarien nicht relevant sind. Das heißt nicht, dass man nicht von List<T> erben könnte. Wenn man z.B. nur eine weitere Methode hinzufügen möchte, dann kann es schon Gründe geben, es auf diesem Weg machen. Es ist aber nicht möglich, sich in die Eventkette der Liste einzuklinken. Muss z.B. beim Löschen eines Elements aus der Liste ein Logeintrag erstellt werden, ist List<T> als Basisklasse nicht zu verwenden. Überhaupt bietet List<T> keine überschreibbaren Member, was auch ein Zeichen dafür ist, dass diese Klasse nicht zum vererben gemacht wurde. Auch sollten keine List<T> Objekte als Eigenschaften von Klassen nach außen gegeben werden.

FXCop meldet einen DoNotExposeGenericLists Fehler mit dem Hinweis: "System.Collections.Generic.List<T> is a generic collection designed for
performance not inheritance and, therefore, does not contain any virtual members. The following generic collections are designed for inheritance and
should be exposed instead of System.Collections.Generic.List<T>.
* System.Collections.ObjectModel.Collection<T>
* System.Collections.ObjectModel.ReadOnlyCollection<T>
* System.Collections.ObjectModel.KeyedCollection<TKey, TItem>"

Krzysztof Cwalina (Program Manager .Net Framework team at MS) hat in einem Blogpost "System.Collections vs. System.Collection.Generic and System.Collections.ObjectModel" die verschiedenen Collection-Klassen und -Interfaces in den verschiedenen Namespaces in einer Übersicht zusammengestellt. Auch sehr hilfreich war ein Auszug des Wrox Buches "Professional C# 2005"

Anders die Klasse Collection<T>, die in der MSDN als "base class for a generic collection" beschrieben wird. Diese gehört aber nicht zum Namensraum System.Collections.Generic, sondern findet sich in System.Collections.ObjectModel. Grund dafür ist eine gleichnamige, nichtgenerische Collection Klasse aus dem Microsoft.VisualBasic Namensraum, der bei Visual Basic Klassen, ebenso wie System.Collections.Generic, standardmäßig importiert wird und es dadurch zu Namenskonflikten kommen kann.
Nach aussen sind bei der Collection<T> Klasse nur die nötigsten Eigenschaften und Methoden verfügbar und intern kann die innere Liste über die Items-Eigenschaft abgegriffen werden. Zudem bietet Collection<T> überschreibbare Methoden zur Benachrichtigung bei Änderungen an der Liste, d.h. bei Hinzufügen, Aktualisieren und Löschen von Elementen. Das hört sich doch gut an, eine CustomGenericCollection ist dann schnell erstellt.

public class CustomGenericCollection<T> : System.Collections.ObjectModel.Collection<T>
    {
        protected override void InsertItem(int index, T item)
        {
            // Aktion, wenn Item hinzugefügt wird
            base.InsertItem(index, item);
        }
        
        public T[] ToArray()
        {
            return ((List<T>)base.Items).ToArray();
        }

        public void Sort(string sortPropertyName)
        {
            Sort(sortPropertyName, SortType.Ascending);
        }
        
        public void Sort(string sortPropertyName, SortType sortType)
        {
            ReflectionComparer<T> comparison = 
                new ReflectionComparer<T>(sortPropertyName, sortType);
            ((List<T>)base.Items).Sort(comparison);
        }
    }

Neben den zwei Sort-Methoden, die die innere Liste mit dem ReflectionComparer von oben aufrufen, wird zusätzlich noch die ToArray-Methode der inneren Liste nach außen geführt, die in Collection<T> der Schlankheit zuliebe eingespart wurde. In der Insert-Methode könnte man das Hinzufügen eines neuen Elements zur Liste protokollieren oder auch unterbinden.

Die Filterung sollte auch noch etwas einfacher vonstatten gehen. Das Vorgehen ist wieder ähnlich. Die bisherige Filtermethode, die mittels Prädikat an die FindAll-Methode der List<T> übergeben wurde, wollte ein Objekt vom Typ ID3Tag übergeben bekommen. Da der neue GenericFilter ebenfalls mit Reflection arbeitet, ist der Typ der generischen Filtermethode egal. Wenn eine Instanz von GenericFilter erzeugt wird, muss ihr im Konstruktor der Name der zu filternden Eigenschaft, der Vergleichswert sowie optional ein Operator mitgegeben werden. Der Code der Klasse GenericFilter sieht dann so aus:

internal class GenericFilter
{
    string filterPropertyName = "";
    string filterValue = "";
    FilterOperator filterOperator;

    public GenericFilter(string filterPropertyName, string filterValue)
    {
        this.filterPropertyName = filterPropertyName;
        this.filterValue = filterValue;
        this.filterOperator = FilterOperator.Contains;
    }

    public GenericFilter(string filterPropertyName, string filterValue, 
        FilterOperator filterOperator)
    {
        this.filterPropertyName = filterPropertyName;
        this.filterValue = filterValue;
        this.filterOperator = filterOperator;
    }

    public bool Filter<T>(T x)
    {
        // Mittels Reflection die Werte 
        // der Eigenschaften aus x und y bestimmen
        object valueX = x.GetType().GetProperty(
            filterPropertyName).GetValue(x, null);

        switch (filterOperator)
        {
            case FilterOperator.Contains:
                if (Convert.ToString(valueX).Contains(filterValue))
                    return true;
                break;
            case FilterOperator.Equals:
                if (Convert.ToString(valueX).Equals(filterValue))
                    return true;
                break;
            case FilterOperator.GreaterThan:
                if (Convert.ToInt32(valueX).CompareTo(Convert.ToInt32(filterValue)) > 0)
                    return true;
                break;
            case FilterOperator.LessThan:
                if (Convert.ToInt32(valueX).CompareTo(Convert.ToInt32(filterValue)) > 0)
                    return true;
                break;
            default:
                return false;
        }
        return false;
    }
}

Der Filter kann für Texteigenschaften die Operatoren Contains und Equals anwenden und für ganzzahlige Eigenschaften einen GreaterThan oder LessThan Vergleich anstellen. Auch hier wieder eine ziemlich laxe Fehlerbehandlung ;-)

Wie dem auch sei, jetzt muss nur noch die FindAll-Methode meiner CustomGenericCollection das Prädikat mit dem Verweis auf die neue Filter-Funktion erstellen und das dann an die FindAll-Methode der inneren Liste weiterreichen. Als Ergebnis wird ein Array vom Typ T nach außen gegeben.

public T[] FindAll(string filterPropertyName, string filterValue, FilterOperator filterOperator)
{
    GenericFilter genericFilter = new GenericFilter(filterPropertyName, filterValue, filterOperator);

    // Prädikat vorbereiten
    Predicate<T> filterGeneric = new Predicate<T>(genericFilter.Filter<T>);
    // Filtern und als Array zurückgeben
    return ((List<T>)base.Items).FindAll(filterGeneric).ToArray();
}

public T[] FindAll(string filterPropertyName, string filterValue)
{
    return FindAll(filterPropertyName, filterValue, FilterOperator.Contains);
}

Die Liste von ID3Tags muss noch auf den neuen Typ CustomGenericCollection umgestellt werden.

//List<ID3Tag> id3Tags = new List<ID3Tag>();
CustomGenericCollection<ID3Tag> id3Tags = new CustomGenericCollection<ID3Tag>();

Nun lässt sie sich anständig filtern:

ID3Tag[] filteredItemsArray;
filteredItemsArray = 
    id3Tags.FindAll("Year", "1990", FilterOperator.GreaterThan);
filteredItemsArray =
    id3Tags.FindAll("Title", "Love", FilterOperator.Contains);

Ich hätte die neuen Filter- und Sortiermethoden nicht unbedingt generisch halten müssen. Nimmt man den geringen Mehraufwand in Kauf, wird man mit hoher Wiederverwendbarkeit belohnt, wie der folgende und letzte Codefetzen zeigt. Was er tut, erahnen Sie sicherlich.

public class Person
{
    string nachname;
    string vorname;

    public Person(string nachname, string vorname)
    {
        this.nachname = nachname;
        this.vorname = vorname;
    }

    public string Nachname
    {
        get { return nachname; }
    }
    public string Vorname
    {
        get { return vorname; }
    }

    public override string ToString()
    {
        return String.Format("{0}, {1}", nachname, vorname);
    }
}

...

CustomGenericCollection<Person> persColl = 
    new CustomGenericCollection<Person>();
persColl.Add(new Person("Frietsch", "Sascha"));
persColl.Add(new Person("Schimmel", "Jochen"));
persColl.Add(new Person("Janczik", "Sebastian"));

persColl.Sort("Nachname", SortType.Descending);
Person[] persArray = persColl.ToArray();

persArray = persColl.FindAll("Vorname", "Sascha", FilterOperator.Equals);

Filtern von generischen Listen mit Hilfe von Prädikaten

Sascha — Thu, 01 Mar 2007 11:21:16 GMT

Nachdem ich meine Liste von ID3Tags jetzt sortieren kann, fehlt noch das Filtern einer generischen Liste.

Die Typen System.Collections.Generic.List und System.Array stellen eine Reihe von Methoden zur Verfügung, die einen einzigen Parameter vom Typ Predicate<T> erwarten.

Exists
Find
FindAll
FindIndex
FindLast
FindLastIndex
ForEach
RemoveAll
TrueForAll

Für meinen Filter will ich die FindAll Methode verwenden, die als Ergebnis eine List<T> liefert, welche nur die Elemente der Ursprungsliste enthält, die das übergebene Prädikat erfüllen.

Prädikate sind eines der neuen generischen Features, die seit Version 2.0 des .Net Frameworks zur Verfügung stehen. Der Delegat System.Predicate wird wie folgt definiert:

Public Delegate Function Predicate(Of T)(obj As T) As Boolean

Eine Funktion, die als Prädikat fungieren soll, muss also einen einzigen Parameter akzeptieren, der vom gleichen Typ sein muss, wie die Elemente der Liste, die mit Hilfe dieses Prädikats bearbeitet werden soll. Der Rückgabewert ist ein Booleanwert, der angibt, ob das untersuchte Element in die Ergebnismenge übernommen werden soll.

Um alle Instanzen von ID3Tags zu bekommen, deren Titel das Wort "Happy" enthält, könnte man einen Code in dieser Form verwenden:

string compareValue = "Happy";
List<ID3Tag> titleFilteredList = new List<ID3Tag>(); 
foreach (ID3Tag id3Tag in id3Tags)
{
    if (id3Tag.Title.Contains(compareValue))
    {
        titleFilteredList.Add(id3Tag);
    }
}

Alle Elemente der Ausgangsliste werden durchlaufen; wenn der Titel den gesuchten Wert enthält, wird das Element der Ergebnismenge angefügt. Achtung: in diesem Beispiel wird nur eine Referenz auf das Element in die Ergebnisliste angefügt, keine Kopie!

Die FindAll-Methode funktioniert vom Prinizip her genauso wie die Schleife im obigen Code. Das übergebene Prädikat entspricht der Überprüfung innerhalb der Schleife. Es bestimmt, was beim einzelnen Element geprüft werden soll. Zunächst muss also eine Funktion definiert werden, die ein Element vom Typ ID3Tag entgegennimmt und nach der Überprüfung des Elements einen booleschen Wert zurückgibt. Der Vergleichswert wird schon im Konstruktor der SearchFilter-Klasse übergeben.

internal class SearchFilter
    {
        // Vergleichswert
        private string compareValue = "";

        public SearchFilter(string compareValue)
        {
            this.compareValue = compareValue;
        }

        // Suche nach Teil von Titel
        public bool TitleContains(ID3Tag id3Tag)
        {
            return id3Tag.Title.Contains(compareValue);
        }
    }

Jetzt kann das Prädikat erzeugt und der FindAll()-Methode übergeben werden. Das Prädikat ist - als Delegat - lediglich die Adresse einer aufrufbaren Methode.

//Vergleichswert für Suche nach Titel im Konstruktor übergeben
SearchFilter titleSearchFilter = new SearchFilter("Happy");
// Prädikat vorbereiten
Predicate<ID3Tag> filterByTitle =
    new Predicate<ID3Tag>(titleSearchFilter.TitleContains);
// Liste mit gefiltertem Ergebnis
List<ID3Tag> titleFilteredList = id3Tags.FindAll(filterByTitle);

Die anderen Methoden, die ich oben erwähnt hatte und die ebenfalls ein Pedicate<T> als Parameter erwarten, funktionieren ähnlich. So iteriert Exists ebenfalls durch alle Elemente und gibt true zurück, wenn das Prädikat das erste mal für ein Element true zurückgibt. FindLastIndex durchläuft die Liste von hinten nach vorne und gibt den Index des Elements aus, bei dem das Prädikat das erste mal true zurückgibt, usw. Interessant sind auch die ForEach()- und RemoveAll()-Methoden.

Mit Prädikaten spart man sich den Code, um durch Elemente einer Liste zu iterieren. OK, vielleicht nicht so triftig, dieser Grund. Aber bezüglich Wiederverwendbarkeit und Austauschbarkeit zur Laufzeit haben Prädikate ihren Charme.

Sortieren von generischen Listen

Sascha — Wed, 28 Feb 2007 18:08:01 GMT

Ich war auf der Suche nach einem einigermaßen sinnvollen Beispiel für die Programmierung von Powershell Cmdlets. Das erste Cmdlet soll Informationen aus ID3Tags von MP3-Dateien auslesen. Man muss das Rad nicht jedesmal neu erfinden, daher verwende ich die Bibliothek ID3Sharp von Chris Woodbury, die man auf sourceforge.net finden kann.

Die MP3-Dateien aus einem Verzeichnis werden nacheinander eingelesen. Für jede Datei werden die Informationen aus dem ID3-Tag in einer Instanz vom Typ ID3Tag zurückgegeben. Diese besitzt lediglich einige öffentliche Eigenschaften für die gängigen Informationen wie Artist, Title, Album, etc. Diese einzelnen Instanzen von ID3Tags werden in einer generischen Liste gesammelt.

List<ID3Tag> id3Tags = new List<ID3Tag>();

Es wäre schön, auf diese Liste nun Filter und Sortierungen anzuwenden. Geht natürlich auch ;-)

Fangen wir mit dem Sortieren an. Die generische Klasse List<T> bietet von Haus aus eine Sort() Methode in drei möglichen Überladungen.

List<T>.Sort () ohne weitere Argumente verwendet den default comparer. Das bedeutet, dass der Typ T das IComparable- oder das generische IComparable-Interface implementieren muss. Da dies bei ID3Tag nicht der Fall ist, würde sich die Liste bei einem Sort()-Aufruf mit einer InvalidOperationException bedanken.

Für die beiden anderen Überladungen wird eine Vergleichsmethode benötigt, die als Parameter zwei Variablen vom Typ T verarbeiten muss, in unserem Falle also zwei Objekte vom Typ ID3Tag. Der Rückgabewert der Methode ist -1, 0 oder 1, je nachdem, ob x kleiner, gleich, oder größer y ist. Ich überlasse hier die Berechnung des Rückgabewertes der String.CompareTo()-Methode der Artist- bzw. Title-Eigenschaft.

Für die Sortierung List<T>.Sort (Generic Comparison) muss die Vergleichsmethode in einer statischen Methode mit den oben erwähnten Parameter definiert werden:

public static int CompareID3TagsByArtist(ID3Tag x, ID3Tag y)
{
    if (x.Artist == y.Artist)
        return x.Title.CompareTo(y.Title);
    else
        return x.Artist.CompareTo(y.Artist);
}

Diese Methode habe ich in einer Klasse SearchFilter erstellt. Der Aufruf zum Sortieren der Liste lautet daher:

id3Tags.Sort(SearchFilter.CompareID3TagsByArtist);

Die letzte Möglichkeit, List<T>.Sort(Generic IComparer), verstaut die Vergleichsmethode in einer eigenen Klasse, die das generische IComparer<T>-Interface implementiert. Um das Interface zu implementieren, muss exakt eine Methode erstellt werden - die Vergleichsmethode. Die ganze Klasse sieht dann so aus:

internal class Mp3Comparer : IComparer<ID3Tag>
{
    #region IComparer<ID3Tag> Members

    public int Compare(ID3Tag x, ID3Tag y)
    {
        if (x.Artist == y.Artist)
            return x.Title.CompareTo(y.Title);
        else
            return x.Artist.CompareTo(y.Artist);
    }
    #endregion
}

Für den Sortieraufruf muss dann ein Objekt vom Type Mp3Comparer erzeugt werden, welches an die Sortmethode übergeben wird.

Mp3Comparer mc = new Mp3Comparer();
id3Tags.Sort(mc);

Als letztes Schmankerl fehlt noch ein aufsteigendes oder absteigendes Sortieren. Dafür lässt sich der Code für die Mp3Comparer Klasse zum Beispiel wie folgt ändern:

#region IComparer<ID3Tag> Members

public int Compare(ID3Tag x, ID3Tag y)
{
    if (x.Artist == y.Artist)
        return (int)sortType * x.Title.CompareTo(y.Title);
    else
        return (int)sortType * x.Artist.CompareTo(y.Artist);
}

#endregion

public Mp3Comparer()
{
    this.sortType = SortType.Ascending;
}

public Mp3Comparer(SortType sortType)
{
    this.sortType = sortType;
}

private SortType sortType;
public enum SortType {Descending = -1, Ascending = 1}

Es ist ein neuer Konstruktor hinzugekommen, der eine Sortierrichtung als Parameter akzeptiert. Ist ein Nicht-Standardkonstruktor definiert, muss auch der Standardkonstruktor explizit angegeben werden. Die bisherige Sortierrichtung war aufsteigend. Dies soll auch der Standardwert sein, wenn keine Richtung angegeben wurde. Soll absteigend sortiert werden, wird der Rückgabewert von Compare gerade mit -1 multipliziert.

Um die Liste nun absteigend zu sortieren, wird folgender Aufruf verwendet:

Mp3Comparer mc = new Mp3Comparer(Mp3Comparer.SortType.Descending);
id3Tags.Sort(mc);