Analyse von Windows Presentation Foundation

Aus Winfwiki

Fallstudienarbeit
Hochschule:	Hochschule für Oekonomie & Management
Standort:	Essen
Studiengang:	Bachelor Wirtschaftsinformatik
Veranstaltung:	Fallstudie / Wissenschaftliches Arbeiten
Betreuer:	Prof._Dr._Uwe_Kern
Typ:	Fallstudienarbeit
Themengebiet:	GUI Design
Autor(en):	Feraz Kadah, Artur Pajonk
Studienzeitmodell:	Abendstudium
Semesterbezeichnung:	WS10
Studiensemester:	2
Bearbeitungsstatus:	begutachtet
Prüfungstermin:
Abgabetermin:

Inhaltsverzeichnis 1 Vorwort 2 Einleitung 3 Architektur 3.1 DisplayEngine 3.2 WindowsBase 3.3 PresentationCore 3.4 PresentationFramework 4 XAML 4.1 Syntax 4.2 Namespaces 4.2.1 Der XML-Namespace der WPF 4.2.2 Der XML-Namespace von XAML 4.3 Eigenschaften 4.4 Konverter 4.5 Erweiterungen 4.6 Collections 4.6.1 System.Collections.IList 4.6.2 System.Collections.IDictionary 5 Steuerelemente 5.1 ContentControls 5.2 ItemsControls 5.3 TextControls 5.4 Sonstige Controls 6 Gestaltung 6.1 Layoutprozess 6.2 Layoutfunktionalität 7 Schlussbetrachtung 7.1 Fazit 7.2 Ausblick 8 Anhang 8.1 Abbildungsverzeichnis 8.2 Tabellenverzeichnis 8.3 Abkürzungsverzeichnis 8.4 Glossar 8.5 Fußnoten 8.6 Literatur- und Quellenverzeichnis

1 Vorwort

Unter dem Thema "Analyse der Windows Presentation Foundation" ist diese Fallstudie im Rahmen des Bachelor-Studienganges "Wirtschaftsinformatik" an der Hochschule für Ökonomie & Management (FOM) unter der Leitung von Prof. Dr. Uwe Kern entstanden.

In dieser Ausarbeitung werden sowohl die Grundlagen der Windows Presentation Foundation, als auch die dahinter liegenden Ideen zur Umsetzung erläutert und analysiert.

Die Entscheidung zur Wahl dieses Themas begründet sich in der Anwendbarkeit dieser Technologie im täglichen Berufsleben. Steigende Anforderungen an moderne Benutzeroberflächen und die zunehmend hohe Komplexität der darunter liegenden Anwendungsfälle erfordern in Zukunft zwei konkrete Dinge: Zum Einen die Umsetzbarkeit von skalierbaren, hochgradig animierten und mit dem Benutzer interagierenden grafischen Oberflächen und zum Anderen eine klare und saubere Trennung der GUI-Gestaltung von der tatsächlichen Geschäftslogik.

Der daraus augenscheinlich resultierende Konflikt der Berufsfelder Designer und Entwickler soll mit Hilfe der Windows Presentation Foundation gelöst oder zumindest abgeschwächt werden.

Ziel dieser Fallstudie ist es zu klären, ob Microsoft dabei den richtigen Weg eingeschlagen hat und worin die Stärken und Schwächen dieses Frameworks liegen.

2 Einleitung

Die Windows Presentation Foundation (WPF) ist eine von Microsoft strategisch ausgerichtete Plattform zur Entwicklung von Benutzeroberflächen und wird als offizieller Nachfolger der Windows Forms beworben. Letztere sind seit .NET 1.0 Bestandteil des Frameworks, wirken allerdings vor Allem auf modernen Betriebssystemen wie Windows Vista oder Windows 7 schnell veraltet und nicht mehr zeitgemäß. Das liegt hauptsächlich daran, dass diese Betriebssysteme vermehrt auf 3D-Effekte und Animationen während der täglichen Arbeit mit Geschäftsanwendungen setzen. Damit versucht man auch die nicht besonders spannenden Arbeiten etwas freudiger zu gestalten und den Geschäftsalltag dadurch gezielt zu lockern.

Die WPF ist aber nicht nur auf multimediale Applikationen ausgerichtet. Auch klassische Client-Server-Anwendungen mit hohem Datendurchsatz profitieren von der Technologie und den Funktionalitäten der WPF. Hierbei sei beispielsweise das mächtige und ausgeklügelte Data Binding erwähnt.

Nicht zuletzt legt die WPF auch einen starken Fokus auf die individuelle Gestaltung von Anwendungen durch Benutzer bzw. Unternehmen. Anwendungen können mit vergleichsweise wenig Aufwand und mit Hilfe von Styles und Templates ein ganzes Corporate Design annehmen. Der Fantasie von Kunden und Anwendern sind damit fast keine Grenzen mehr gesetzt.

3 Architektur

Vor der Einführung der WPF gab es lange Zeit nur eine Möglichkeit Windows-Anwendungen zu programmieren: "Mit der Programmiersprache C wurde zur Erstellung von Fenstern und zur Verwendung weiterer Systemfunktionalität auf die Funktionen der ebenfalls in C geschriebenen Windows-Programmierschnittstelle - kurz Windows-API - zugegriffen. Mit der Umstellung auf eine 32-Bit-Architektur wurden die Bibliotheken der Windows-API angepasst und erweitert. [...] Man spricht in diesem Zusammenhang statt von der Windows-API auch von der Win32-API."^[1]

Die GDI+ Programmbibliothek - ein Teil der Windows-API - leitet entsprechende Befehle an die Grafikkarte weiter. Dadurch werden die Steuerelemente auf den Bildschirm gerendert. Abbildung 1 verdeutlicht diesen Mechanismus bildlich. Hierbei wird - aus Windows-Sicht - jedes einzelne Control als eigenes Fenster angesehen.

Im Gegensatz dazu wählt die WPF einen innovativeren Weg: Die Controls werden nicht mehr als einzelnes Fenster angesehen. Dies ermöglicht das Zeichnen auf den Pixeln anderer Controls, was durch die Glas- und Transparenzeffekte in Windows Vista und Windows 7 verdeutlichen.

Dieses innovativere Vorgehen wurde dadurch möglich, dass sich die Architektur der WPF in zwei wesentlichen Punkten von den bisherigen Programmiermodellen unter Windows unterscheidet. Zum Einen geschieht die Generierung von Benutzeroberflächen mit Hilfe der Beschreibungssprache XAML und zum Anderen baut die grafische Darstellung erstmals nicht auf der GDI-Komponente der Windows-API auf. Stattdessen greift die WPF zur Darstellung des Fensterinhalts auf die bisher meist nur von Spielen genutzte DirectX-Suite zu. Diese ermöglicht die direkte Kommunikation zwischen der Anwendung und der Grafikkarte eines Systems. Bisher blieb meistens die Rechenleistung einer Grafikkarte völlig ungenutzt. Abbildung 2 zeigt die WPF-Architektur mit ihren Hauptkomponenten.

3.1 DisplayEngine

Die WPF beinhaltet zur Darstellung verschiedener Effekte und Komponenten (z. B. 3D, 2D, Text, Video, Bilder, Effekte und Animationen) den sogenannten MilCore. Dieser MilCore dient in Form eines Wrappers für DirectX als Basis für alles, was in der WPF gezeichnet wird.

Ein entscheidender Vorteil des MilCore für WPF-Anwendungen ist die vektorbasierte Darstellung der gesamten Inhalte. Dies führt dazu, dass Anwendungen beliebig skaliert werden können, ohne an "Schärfe" zu verlieren.

Der MilCore verwaltet dazu den darzustellenden Bildschirminhalt in Form einer Baumstruktur (CompositionTree). Dieser Baum besteht aus einzelnen Knoten (CompositionNodes), die Zeichnungsinformationen enthalten. Wird der Inhalt des CompositionTree geändert, erstellt MilCore die entsprechenden DirectX-Befehle, durch welche die Änderungen visuell umgesetzt und mit Hilfe der Grafikkarte auf den Bildschrim gerendert werden. Die vielen CompositionNodes werden durch MilCore zu einem großen, zu zeichnenden Bild zusammengesetzt, welches als Komposition bezeichnet wird. Anschließend wird das zusammengesetzte Bild auf dem Bildschirm dargestellt.

In früheren Architektur-Modellen, wie z. B. Windows Forms, hatte jedes Control seinen eigenen Ausschnitt, in dem es sich selbst zeichnen durfte. Diesen Ausschnitt konnte das Control nicht überschreiten. Diese Art von System wird als Clipping-System bezeichnet, da am Rand gekappt bzw. "geclippt" wird.

Bei einem Composition-System wird nicht abgeschnitten sondern jedes Control ist befähigt überall zu zeichnen. Am Ende werden die einzelnen Controls zu einem Ganzen zusammenfügt. Mit der Komposition im MilCore kann ein Control auch über die Pixel eines anderen Controls zeichnen, was die aus Windows Vista/7 bekannten Halbtransparenz-Effekte ermöglicht.

Der CompositionTree ist mit allen Zeichnungsinformationen zwischengespeichert. Dadurch kann die GUI sehr effektiv und schnell neugezeichnet werden, und zwar auch dann, wenn die Anwendung gerade "beschäftigt" ist. Dies beendet die Ära der "aufgehangenen" Programme, die auf keinerlei Eingaben mehr reagieren.

Der CompositionTree, welcher zur Laufzeit mit Zeichnungsinformationen bestückt und in der MilCore-Komponente befindlich ist, besitzt auf .NET-Seite ein Gegenstück: Den VisualTree. Dieser VisualTree setzt - wie der Name besagt - alle visuellen Komponenten der WPF-Anwendung zusammen. Das Konzept der Entwicklung von WPF-Anwendungen besteht darin, mit XAML und/oder C# eine Hierarchie von visuellen Elementen zu erzeugen (z. B. Window, TextBox und Button). Die einzelnen Controls in dieser Hierarchie setzen sich wiederum aus einfacheren visuellen Elementen zusammen (z. B. Rectangle, TextBlock oder Border). Die gemeinsame Hierarchie, einschließlich der einfachen visuellen Elemente, wird daher als VisualTree bezeichnet.

CompositionTree und VisualTree sind über einen Kommunikationkanal miteinander verbunden. Über diesen werden Änderungen gegenseitig übertragen. Dabei sind die beiden Bäume nicht vollkommen identisch, z. B. können einem Knoten im VisualTree mehrere Knoten im CompositionTree entsprechen. Objekte mit hohem Speicherplatzbedarf (z. B. Bitmaps) werden gemeinschaftlich verwendet.

Der direkte Zugriff auf den MilCore ist nicht möglich. Deshalb werden im .NET-Framework Bibliotheken bereitgestellt, in denen alle Funktionalitäten des MilCore gekapselt vorliegen und angesprochen werden können. Dabei handelt es sich um WindowsBase, PresentationCore und PresentationFramework. ^[2]

3.2 WindowsBase

Bei dieser Bibliothek handelt es sich um die Basislogik für Windows-Anwendungen, welche in .NET verfasst wurde. Unter Anderem ist das in .NET 3.0 eingeführte und erweiterte Eigenschaftssystem implementiert. Dieses besteht aus dem sogenannten DependencyProperties. Die Bibliotheken PresentationCore und PresentationFramework bauen beide auf der WindowsBase-Bibliothek auf.

3.3 PresentationCore

Auf der .NET-Seite ist im PresentationCore die Verbindung von CompositionTree und VisualTree in einer abstrakten Klasse implementiert. Der VisualTree einer WPF-Anwendung besteht aus Objekten von Unterklassen von Visual. Die Klasse Visual enthält private Methoden zur Kommunikation mit dem - auf MilCore-Seite bestehenden - CompositionTree und dient als Basisklasse für all jene Klassen, die in der WPF visuell dargestellt werden sollen.

Zusätzlich enthält der PresentationCore einige weitere interessante Klassen, unter Anderem die Klasse UIElement, die in der WPF ebenfalls von Visual ableitet und eine konkrete Implementierung für visuelle Elemente darstellt.

3.4 PresentationFramework

Die wichtigsten Klassen der WPF, sowohl für die Entwicklung der grafischen Benutzerschnittstelle als auch für die Funktionaliät der Anwendungen, befinden sich in der Bibliothek PresentationFramework. Darunter sind Klassen für Steuerelemente, Dokumente, Layout-Panels, Benutzerführung und Animationen sowie Klassen zur Einbindung von Videos und Bildern. Oft wird diese Bibliothek allein als die WPF bezeichnet, da die anderen Bibliotheken - WindowsBase und PresentationCore - nur das Grundgerüst für ein UI-Framework bieten.

Die WPF ist ein solches UI-Framework, das in der Bibliothek PresentationFramework implementiert ist.

4 XAML

Die eXtensible Application Markup Language (im Folgenden XAML genannt) wurde im .NET-Framework der Version 3.0 eingeführt. Sie wird zur Erstellung von Benutzeroberflächen eingesetzt. Obwohl das Design der Benutzeroberflächen auch allein in C# erstellt werden kann, ist XAML doch meist die bevorzugte Wahl, wofür die bessere Trennung von GUI-Design und Programmlogik den ausschlaggebenden Grund darstellt.

Dabei ist es wichtig zu wissen, dass mit XAML nichts möglich ist, was nicht auch mit C# möglich wäre. XAML stellt lediglich ein Umwandlungsformat dar, aus dem zur Laufzeit Objekte erzeugt werden.

4.1 Syntax

XAML basiert auf XML und besteht somit aus XML-Elementen und XML-Attributen. Wie auch XML-Dokumente müssen XAML-Dokumente wohlgeformt (d. h. frei von Fehlern) sein. Wohlgeformt ist eine XAML-Datei genau dann, wenn sie einige Voraussetzungen erfüllt. Die vier Wichtigsten sind:

• Die Datei hat genau ein Wurzelelement, das alle Elemente umschließt.
• Auf ein öffnendes Element folgt immer auch ein schließendes Element.
• Ein leeres Element kann auch direkt mit einem "/" (Schrägstrich) am Ende des Elements geschlossen werden.
• Elemente müssen korrekt verschachtelt sein. Wird innerhalb des Elementes <Element1> das Element <Element2> geöffnet, muss das schließende Element von </Element2> vor dem schließenden Element </Element1> gesetzt werden.

Beispiel:

Dieser XAML-Code entspricht folgendem Code in C#:

4.2 Namespaces

Damit aus den XAML-Elementen die richtigen .NET-Klassen erstellt werden können, ist es zwingend notwendig, die richtigen XML-Namespaces im Wurzelelement mit Attribut "xmlns" anzugeben, die im Hintergrund auf CLR-Namespaces aus dem .NET-Framework zeigen.

Ein XAML-Dokument besitzt üblicherweise zwei XML-Namespaces, die in den Ziffern 4.2.1 und 4.2.2 wie folgt dargestellt werden:

4.2.1 Der XML-Namespace der WPF

In Abbildung 4 wurden in XAML ein Window-Element und ein Button-Element definiert. Zur Laufzeit werden aus diesen Elementen Objekte der Klassen Window und Button erzeugt. Auf dem Window ist mit dem xmlns-Attribut der XML-Namespace "http://schemas.microsoft.com/winfx/2006/xaml/presentation" definiert. Dies ist der XML-Namespace der WPF. Hinter dieser URL befindet sich keine herkömmliche Webseite. Es handelt sich ausschließlich um einen Namesraum, der XML-Elemente eindeutig qualifiziert. Vergleichbar ist dies mit .NET-Namespaces, welche die Klassen eindeutig qualifizieren. Auf Grund der Eindeutigkeit werden in XML - und damit auch XAML - für Namespaces URLs verwendet.

Das xmlns-Attribut muss im Wurzelelement deklariert sein, damit sich die XAML selbst in Gänze qualifiziert. Durch die Angabe dieses Attributs werden die in der XAML deklarierten Elemente dem Namensraum der WPF zugeordnet.

Die Verbindung der XML-Namespaces innerhalb der WPF mit meheren CLR-Namespaces ist fest in der WPF enthalten und kann nicht geändert werden. Die CLR-Namespaces enthalten unter Anderem die CLR-Namespaces System.Windows und System.Windows.Controls. In ihnen befinden sich die Klassen Window und Button. ^[3]

4.2.2 Der XML-Namespace von XAML

Die Deklaration weiterer XML-Namespaces auf einem XML-Element ist in der Anzahl nicht begrenzt, jedoch muss jeder zusätzliche XML-Namespace einen Alias besitzen. Generell besitzt jedes XAML-Element zusätzlich noch einen zweiten XML-Namespace, den Namespace für XAML. Dieser besitzt als Alias üblicherweise ein "x":

xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml

Der Namespace für XAML ist dem CLR-Namespace System.Windows.Markup zugeordnet. Der XAML-Namespace verfügt weiterhin spezielle Direktiven für den XAML-Compiler und -Parser. Diese Direktiven werden auch XAML-Spracherweiterungen genannt und sind Instruktionen für den XMAL-Compiler und -Parser. ^[4]

4.3 Eigenschaften

Wird ein XML-Attribut auf einem XAML-Element definiert, so wird dies entweder einer Eigenschaft oder einem Ereignis zugeordnet. Zum Setzen der Eigenschaft wird ein Attribut mit dem Namen der Eigenschaft deklariert. In diesem Attribut wird der gewünschte Wert - in Anführungszeichen gesetzt - zugewiesen. Das Codebeispiel im Folgenden zeigt, wie die Content-Eigenschaft auf "ok" gesetzt wird:

<Button Content="ok"/>

Die verwendete Syntax zur Deklaration der Content-Eigenschaft wird als Attribut-Syntax bezeichnet. Es ist zu erkennen, dass der Content-Eigenschaft ein String-Wert zugewiesen wird. Wird ein primitiver Datentyp verlangt (bool, int, double, float, char, etc.) oder ein Aufzählungswert, wird dieser in der Attribut-Syntax angegebene String automatisch in den entsprechenden Typ umgewandelt.

Soll kein primitiver Datentyp oder Aufzählungswert zugewiesen werden sondern ein Objekt, so ist dies über die Property-Element-Syntax möglich.

Wenn anstelle eines primitiven Datentyps oder eines Aufzählungswerts ein Objekt zugewiesen werden soll, ist dies über die Property-Element-Syntax möglich. Hierbei wird kein XML-Attribut sondern ein XML-Element gesetzt. Dieses verweist auf eine Eigenschaft eines Objekts und wird dementsprechend Property-Element genannt.

Im folgenden Codebeispiel wird ein Button erstellt, dessen Content-Eigenschaft mit der Property-Element-Syntax gesetzt wird:

4.4 Konverter

XAML-Dokumente sind oft weitaus kompakter als C#-Code. Ein Grund hierfür ist unter Anderem die Verwendung von Typen-Konvertern. Wird ein XAML-Dokument geparst, werden die mit der Attribut-Syntax angegebenen Strings für Eigenschaften mit primitiven Typen oder Aufzählungen automatisch in den erwarteten Datentypen umgewandelt. Für Objekte anderer Typen ist entweder die Verwendung der Property-Element-Syntax notwendig oder für den Datentyp wird ein eigener Typen-Konverter angelegt. Anstelle der Property-Element-Syntax ist es somit möglich, ein Objekt direkt mit der Attribut-Syntax einer Property zuzuweisen.

Ein Typen-Konverter ist ein Objekt der Klasse TypeConverter bzw. einer Unterklasse. TypeConverter existiert bereits seit dem .NET-Framework 1.0 und enthält unter Anderem die Methode convertFrom(), die sich in weitere Unterklassen überschreiben lässt und gibt den konvertierten Wert zurück.

Typen-Konverter verursachen "[...] insbesondere bei XAML-Einsteigern den Eindruck, dass XAML fast magisch funktioniert." ^[5]

4.5 Erweiterungen

Markup-Erweiterungen bieten die Möglichkeit, Objekte über die Attribut-Syntax und über die Property-Element-Syntax zu erstellen und eine Eigenschaft zuzuweisen. Sie bieten zudem die Möglichkeit, beispielsweise mit einem Data-Binding, existierende Objekte zu referenzieren, anstatt sie neu zu erzeugen. Eine Markup-Erweiterung verweist aus XAML auf eine Klasse, die von der Klasse MarkupExtension abgeleitet ist und deren Methode provideValue() beinhaltet.

Markup-Erweiterungen werden beim Verwenden der Attribut-Syntax in geschweifte Klammern eingeschlossen. Der folgende Code-Ausschnitt zeigt die Benutzung der Markup-Erweiterungen mit der Attribut-Syntax:

Static, Null und Binding verweisen auf Klassen, die von MarkupExtention abgeleitet sind. Die Klassen heißen dabei StaticExtention, NullExtention und Binding. Der XML-Parser sucht automatisch in den entsprechenden .NET-Namespaces nach Klassen, die dem ersten Wort in den geschweiften Klammern entsprechen. Dabei hängt der XAML-Parser automatisch eine Erweiterung an den Klassennamen an, wenn er die entsprechende Klasse nicht findet und der Klassenname noch kein "Extension"-Suffix enthält. Von diesem wird eine Instanz erzeugt. Das in Abbildung 7 erzeugte Binding-Objekt setzt die Eigenschaften ElementName und Path.

Markup-Erweiterungen können jedoch auch als gewöhnliche Objekt-Elemente erstellt werden. Der folgende Code-Ausschnitt zeigt die Benutzung der Markup-Erweiterungen unter Zuhilfenahme von gewöhnlichen Objektelementen:

4.6 Collections

In XAML gibt es zwei Arten von Collections. Zum Einen Collections, die das Interface System.Collections.IList implementieren und zum Anderen Collections, die das Interface System.Collections.IDictionary behinhalten. Letztere speichern Werte unter einem bestimmten Schlüssel ab, die in den Ziffern 4.6.1 und 4.6.2 nachstehend wie folgt dargestellt werden:

4.6.1 System.Collections.IList

ContentControls, wie Button oder Window, können nur ein Kindelement besitzen, welches in der ContentControl definierten Content-Eigenschaft zugewiesen werden kann. Um ein Window mit meheren Elementen auszustatten, wird ein Layout-Panel verwendet, das mehrere Unterelemente enthalten kann.

Ein oft verwendetes Layout-Panel ist das StackPanel. Es stapelt Elemente vertikal (Standard) oder horizontal. Elemente werden zur Children-Eigenschaft des Stack-Panels hinzugefügt. Die Children-Eigenschaft ist vom Typ UIElementCollection. Die Klasse UIElementCollection implementiert das Interface System.Collections.IList. Der folgende Code-Ausschnitt zeigt, wie in XAML zwei Text-Objekte zu einem StackPanel hinzugefügt werden:

Da die Children-Eigenschaft mit dem ContentPropertyAttribute als Content-Eigenschaft definiert ist, ist die Angabe des Eigenschaft-Elements optional.^[6] Der folgende Code-Ausschnitt zeigt, wie in XAML zwei Text-Objekte zu einem Stack-Panel hinzugefügt werden, jedoch ohne die Angabe des Eigenschaft-Elements:

4.6.2 System.Collections.IDictionary

Neben Collections, die IList implementieren, kann der XAML-Parser auch Unterelemente zu Collections hinzufügen, die IDictionary implementieren. Die sogenannten Dictionaries besitzen, im Gegensatz zu den Listen, zu jedem Wert einen Schlüssel. Die Klasse Hashtable implementiert IDictionary.

Um eine Hashtable in XAML mit Unterelementen zu füllen, muss zu jedem Unterelement auch ein Schlüssel angegeben werden. Der folgende Code-Ausschnitt zeigt, wie in XAML eine Hashtable mit drei Kindelementen befüllt wird:

Auf Unterelementen eines Objekt-Elementes von Typ IDictionary muss das x:Key-Attribut zwingend gesetzt werden. Ansonsten kommt es bei der Übersetzung des Codes zu einer XamlParseException.

Die bekannteste IDictionaryCollection der WPF, ist die Klasse System.Windows.ResourceDictionary. Jedes FrameworkElement besitzt eine Eigenschaft Resources, die ein ResourceDictionary enthält. Darin lassen sich, wie der Name vermuten lässt, Resourcen speichern. ^[7] Der folgende Code-Ausschnitt zeigt, wie in XAML ein ResourceDictionary verwendet wird:

5 Steuerelemente

Zu den wichtigsten Controls der WPF gehören:

• Menu
• ToolBar
• StatusBar
• TreeView
• ListBox
• ListView
• Button
• TextBox
• ComboBox.

Diese im .NET-Framework enthaltenen Steuerelemente werden zum Großteil zur Erstellung von Anwendungen mit der WPF verwendet.

Im Gegensatz zu Windows Forms ist alles in der WPF Sichtbare nicht zwingend ein Steuerelement sondern ein beliebiges visuelles Element. Ein solches Element ist bei der WPF ein Objekt einer Unterklasse von Visual. Die zentrale Klasse der WPF, die über UIElement von Visual erbt, ist die Klasse FrameworkElement. Die Klasse Control ist eine Unterklasse von FrameworkElement. Ein Control ist speziell auf die Interaktion mit dem Benutzer fokussiert. Beispielsweise werden Hover-Effekte (Änderung der Darstellung, wenn die Maus über das Steuerelement wandert) oder Fokussierungseffekte dargestellt.

Die folgende Abbildung soll einen vereinfachten Überblick über die Klassenhierarchie rund um FrameworkElement und Control geben:

5.1 ContentControls

Diese Controls erben von der Klasse ContentControl und besitzen die Eigenschaft Content vom Typ Object. Der Content-Eigenschaft kann ein beliebiges Objekt zugewiesen werden, welches als Inhalt des ContentControls dargestellt wird. Dieses Objekt ist nicht typgebunden.

Da die Content-Eigenschaft eines ContentControls nur ein einziges Objekt entgegennimmt, ist es üblich, der Content-Eigenschaft ein Layout-Panel zuzuweisen, das wiederum mehrere Elemente enthält.

Für ein Objekt, das von UIElement erbt, wird die onRender()-Methode aufgerufen und das Objekt entsprechend der Vorgaben aus der Methode gezeichnet. Wird der Content-Eigenschaft ein Objekt zugewiesen, das nicht von UIElement erbt, wird auf diesem Objekt die ToString()-Methode aufgerufen. Das Ergebnis wird anschließend in ein TextBlock-Objekt gesetzt. Dieses TextBlock-Objekt wird als Content gesetzt und angezeigt.

Der folgende Code-Ausschnitt zeigt einen Button, der ein Stack-Panel enthält, in dem sich wiederum weitere Elemente befinden:

Analog dazu zeigt der folgende Code-Ausschnitt einen Button, dessen Content-Eigenschaft lediglich einen String enthält:

Im Folgenden werden typische ContentControls und ihre typischen Einsatzzwecke aufgelistet:

Tabelle 1: ContentControls und ihre Einsatzzwecke

ContentControl	Beschreibung
Button	Ein Button hat üblicherweise ein Klick-Ereignis und drei typische Eigenschaften: IsDefault, IsCancel, IsDefaulted. Wird beispielsweise die Eigenschaft IsDefault eines Buttons auf true gesetzt, wird bei dem Button durch Drücken der Enter-Taste das Klick-Ereignis ausgelöst. Die Eigenschaft IsCancel löst - wenn true - bei Betätigung der ESC-Taste das Klick-Ereignis des Buttons aus.
Label	Ein Label ist ein Text auf der Oberfläche der Anwendung. Die Focusable-Eigenschaft eines Labels ist standardmäßig false, wodurch ein Label selbst nicht auswählbar ist. Jedoch kann dem Label ein fokussierbares UIElement zugewiesen werden, welches beim Klick auf das Label fokussiert wird.
ToolTip	Ein ToolTip ist eine kleine Information, die erscheint, sobald die Maus über ein UIElement bewegt wird.
ScrollViewer	Ein ScrollViewer ist ein Element, das im scrollbaren Bereich zwei eigene ScrollbarControls für das vertikale und horizontale Scrollen enthält. Sowohl die vertikale als auch horizontale Scrollbar kann per Eigenschaft ScrollbarVisibility sichtbar oder unsichtbar gestellt werden.
Frame	Ein Frame zeigt Inhalte isoliert in der WPF-Anwendung an. Beispielsweise werden Eigenschaften, die über den ElementTree vererbt werden, nicht an den Inhalt eines Frames vererbt.

^[8]

5.2 ItemsControls

Diese Controls erben von der Klasse ItemsControl und besitzen somit eine Eigenschaft mit Namen Items vom Typ ItemCollection. Der Items-Eigenschaft können mehrere beliebige Objekte zugewiesen werden, die als Inhalt des ItemsControls dargestellt werden.

Die wichtigsten Eigenschaften der Klasse ItemsControl sind neben der Items-Eigenschaft auch die ItemsSource-Eigenschaft vom Typ IEnumerable.

Standardmäßig ist die ItemsSource-Eigenschaft null. Wird die ItemsSource-Eigenschaft gesetzt, enthält auch die Items-Eigenschaft dieselben Objekte. Allerdings ist die hinter der Items-Eigenschaft liegende Items-Collection bei einer gesetzten ItemsSource nicht schreibbar (read-only). Der Aufruf der Add()-Methode führt in einem solchen Fall zu einer InvalidOperationException.

Für fast jedes ItemsControl gibt es ein passendes Container-Element. Beispielsweise gibt es für die TreeView ein TreeViewItem, für die ComboBox ein ComboBoxItem, etc.

In der folgenden Tabelle werden typische ItemsControls aufgelistet:

Tabelle 2: ItemsControls und ihre Einsatzzwecke

ItemsControl	Beschreibung
ItemsControl mit Header	ItemsControls mit Header besitzen eine Header-Eigenschaft. Typische Komponenten sind MenuItem und TreeViewItem.
TreeView	Die TreeView-Komponente dient zur Darstellung einer Baumstruktur. Die Klasse TreeView erweitert die Klasse ItemsControl um die Eigenschaften SelectedItem und SelectedValue. Diese Eigenschaften dienen im Allgemeinen dazu, den gewählten Baumknoten oder den Wert des Knotens zurückzugeben.
Menüs	Die WPF verfügt über zwei Arten von Menüs. Zum Einen die gewöhnlichen Menüs (Menu-Klasse) und zum Anderen Kontextmenüs (ContextMenu-Klasse). Beide sind von der abstrakten Klasse MenuBase abgeleitet.
Selectors	Diese Komponenten erlauben eine Auswahl aus verschiedenen Datenmengen. Typische Beispiele für Selektoren sind ComboBoxen, ListBoxen und ListViews. Die Klassen erweitern ItemsControl um die Eigenschaften SelectedItem, SelectedValue.
StatusBar	Die StatusBar ist ein Control, welches üblicherweise weitere Controls zur Anzeige eines Status enthält. Es dient beispielsweise zur Anzeige von Fortschrittsbalken.

^[9]

5.3 TextControls

Diese Controls sind typische Hilfsmittel zur Darstellung und Eingabe von Texten. Im Folgenden werden typische TextControls und ihre Einsatzzwecke aufgelistet:

Tabelle 3: TextControls und ihre Einsatzzwecke

TextControl	Beschreibung
TextBox	Die Klasse TextBox erbt von der Klasse TextBoxBase, die wiederum direkt von Control abgeleitet ist. Typische Eigenschaften von TextBoxBase sind AcceptsReturn, AcceptsTab, CanRedo, CanUndo und IsUndoEnabled. Die Eingabe kann mit Hilfe der Eigenschaft MaxLength in ihrer Länge beschränkt werden.
RichTextBox	Die RichTextBox ist wie die Klasse TextBox von der Überklasse TextBoxBase abgeleitet. Allerdings ist die RichTextBox im Vergleich zur herkömmlichen TextBox wesentlich umfangreicher, was ihre Funktionalität betrifft. So lassen sich in der RichTextBox beispielsweise Schriftarten, -größen und -farben frei definieren.
PasswordBox	Diese Klasse ist direkt von Control abgeleitet. Sie dient zu Eingabe von maskierten Texten, z. B. Passwörter. Über die MaxLength-Eigenschaft kann die maximale Eingabelänge festgelegt werden. Über die Eigenschaft PasswordChar wird das Maskierungszeichen definiert.
TextBlock	Die TextBlock-Klasse ist vom FrameworkElement abgeleitet, liegt aber denoch in System.Windows.Controls. Bei TextBlock handelt es sich im Grunde um ein Label, welches jedoch in der Darstellung etwas umfangreicher ist. So lassen sich Texte fett, kursiv und/oder in Blocksatz darstellen.
InkCanvas	Das InkCanvas ist für Eingabe von Inhalten per Stift (Stylus) oder Maus gedacht. Der Benutzer kann direkt auf ein InkCanvas zeichnen. Das Besondere ist, dass InkCanvas eine Children-Eigenschaft vom Typ UIElementCollection besitzt. Somit kann z. B. ein Bild in das InkCanvas gelegt werden. Diese Technik wurde 2006 während der Fussballweltmeisterschaft bekannt, als erstmals Fernseh- und Standbilder mit einem Stift analysiert wurden.

^[10]

5.4 Sonstige Controls

Auf Grund des begrenzten Umfangs dieser Fallstudie, wird auf viele weitere Controls der WPF, wie z. B. DateControls (Calendar, DatePicker), RangeControls (Slider, Seperator), etc., nicht näher eingegangen. Eine detaillierte Auflistung aller WPF-Controls kann unter der MSDN Control Library eingesehen werden.

6 Gestaltung

Zur Gestaltung des Layouts besitzt die WPF einige Panels. Diese sind Unterklassen von System.Windows.Controls.Panel. Panels sind Elemente, die mehrere Kindelemente vom Typ UIElement nach einem bestimmten Algorithmus positionieren und ausrichten. Im Gegensatz zu früheren Programmiermodellen werden bei der WPF die Elemente üblicherweise nicht mehr absolut positioniert. Ihre Position und Größe ergibt sich aus dem verfügbaren Platz.

Um die in Ziffer 5 beschriebenen #Steuerelemente der WPF anzuordnen, kommunizieren die Überelemente mit ihren entsprechenden Unterelementen. Diese Kommunikation wird als Layoutprozess bezeichnet.

6.1 Layoutprozess

Der Layoutprozess wird von der WPF ausgelöst, wenn sich z. B. eine bestimmte Eigenschaft ändert, wie etwa die Größe eines Window-Objekts. Der Layoutprozess besteht dabei aus zwei Schritten: Measure und Arrange.

Beim ersten Anzeigen eines jeden Elements werden die beiden Schritte des Layoutprozesses durchlaufen, in welchem die folgenden - in der Klasse UIElement definierten - Methoden in der Reihenfolge Measure()-Arrange()-OnRender() aufgerufen werden.

Die OnRender()-Methode hat dabei nicht tatsächlich etwas mit dem Layout zutun, sondern stellt lediglich die Zeichnungsinformationen für das jeweilige Element und greift dazu auf die im Arrange-Schritt ermittelte RenderSize-Eigenschaft zu.

Im Folgenden werden die beiden Schritte Measure und Arrange des Layoutprozesses näher erläutert:

"Schritt 1: Measure - Die Größe der Elemente wird gemessen

In ersten Schritt des Layoutprozesses "fragen" die Eltern ihre visuellen Kinder wie groß sie gerne sein würden. Die Frage stellen die Eltern, indem sie auf den Kindelementen die in UIElement definierte Methode Measure aufrufen. Measure hat die folgende Signatur:

void Measure(Size availableSize) {...}

Das an Measure übergebene System.Windows.Size-Objekt, [...] definiert die verfügbare Größe für das Kindelement. Anhand dieser verfügbaren Größe ermittelt das Kindelement seine gewünschte Größe, die auch größer als die verfügbare Größe sein kann, und speichert das Ergebnis in der aus UIElement geerbten Read-only-Property DesiredSize ab.

Nachdem das Elternelement auf dem Kindelement die Measure-Methode aufgerufen hat, greift es anschließend auf die DesiredSize-Property zu, um beispielsweise die eigene Größe zu berechnen.

Schritt 2: Arrange - Die Elemente werden angeordnet

Im zweiten Schritt des Layoutprozesses geben die Eltern ihren Kindern den tatsächlichen verfügbaren Platz und eine Position. Dazu rufen die Eltern auf den Kindern die ebenfalls in UIElement definierte Methode Arrange auf, die die folgende Signatur hat:

void Arrange(Rect finalRect)

Die Methode Arrange nimmt ein System.Windows.Rect-Objekt entgegen, das die Properties X, Y, Width und Height besitzt. Das Rect-Objekt definiert die Position und die finale Größe des Elements. Intern setzt die Methode Arrange die in UIElement definierte RenderSize-Property. [...] Die Property RenderSize beschreibt die finale Größe, wie das Element letztlich gezeichnet bzw. gerendert wird. Diese Property wird üblicherweise in der OnRender-Methode verwendet."^[11]

6.2 Layoutfunktionalität

Um ein Element innerhalb eines Elternelements anzuordnen bzw. zu modifizieren, besitzt die Klasse FrameworkElement verschiedene Eigenschaften.

Die Größe eines Elements kann über die Eigenschaften Width und Height festgelegt werden. Außerdem stehen zur weiteren Steuerung die Eigenschaften MinWidth, MinHeight, MaxWidth und MaxHeight zur Verfügung. Sollten die Eigenschaften Width und Height nicht gesetzt werden, besitzen beide den Wert Double.NaN ("Not a Number"). In XAML können die Eigenschaften Width und Height auch explizit auf Double.NaN gesetzt werden, indem der Wert NaN oder Auto angegeben wird.

Die aktuelle Größe eines FrameworkElements erhält man wider erwartend nicht über die Eigenschaften Width und Height, sondern über die Read-Only-Eigenschaften ActualWidth und ActualHeight. Außerdem werden die Eigenschaften Width und Height nicht wie allgemein üblich in Pixel, sondern in logischen Einheiten (eine Einheit = 1/96 Inch) angegeben.

Der äußere und innere Rand eines Elements lässt sich mit Hilfe der Eigenschaften Margin und Padding setzen. Margin stattet dabei ein FrameworkElement mit einem äußeren Rand aus. Die Margin-Eigenschaft ist vom Typ System.Windows.Thickness. Die Thickness Klasse besitzt die Eigenschaften Left, Top, Right und Bottom, mit denen für jede Seite des Elements ein individueller Rand definiert werden kann.

Wird für die Margin-Eigenschaft nur ein Wert gesetzt, werden alle Seiten des Elements mit dem gleichen Rand ausgestattet. Werden für die Margin-Eigenschaft zwei Werte gesetzt, wird der Erste für Left und Right verwendet und der Zweite für Top und Bottom. Die Abbildung 16 zeigt die Auswirkung einiger Werte für die Margin-Eigenschaft.

Padding stattet einige Subklassen von FrameworkElement, wie z.B. Control, TextBlock und Border mit einem inneren Rand aus. Padding ist, wie auch Margin, vom Typ Thickness.

Die vertikale und horizontale Ausrichtung von Elementen, lässt sich mit Hilfe von Alignments umsetzen. Die Klasse FrameworkElement definiert dafür die Eigenschaften HorinzontalAlignment und VerticalAlignment. Zusätzlich stellt die Klasse Control für die Ausrichtung des eigenen Inhalts die Eigenschaften HorinzontalContentAlignment und VerticalContentAlignment bereit.

Alignments lassen sich auf die Werte Left, Center, Right und Stretch setzen. Die Abbildung 17 soll die jeweiligen Unterschiede in der Ausrichtung veranschaulichen.

Auf Grund des begrenzten Umfangs dieser Fallstudie, wird auf viele weitere Layoutfunktionalitäten der WPF, wie z. B. Visibility, Transformation, RotateTransform, ScaleTransform, etc. nicht näher eingegangen. Eine detaillierte Auflistung aller Layoutfunktionalitäten kann unter der Seite MSDN Anordnen von Windows Forms Steuerelementen in WPF eingesehen werden.

7 Schlussbetrachtung

7.1 Fazit

Microsoft hat der WPF ein leistungsfähiges und innovatives GUI-Framework geschaffen, welches es vermag, den immer weiter steigenden Bedarf an komplexen und modernen Benutzeroberflächen zu stillen.

Die Möglichkeit, eine strenge Trennung von GUI und Programmlogik vorzunehmen, ist sowohl für softwareproduzierende Unternehmen als auch für die jeweiligen Entwickler ein nicht zu vernachlässigender Vorteil. Immer wieder auftretende Missverständnisse - hinsichtlich der Realisierung von Benutzeroberflächen - zwischen Grafik-Designern und .NET-Entwicklern werden somit in ihrer Anzahl minimiert. Die Grafik-Designer erarbeiten nicht mehr nur GUI-Konzepte sondern können diese mit Hilfe der XAML-Implementierung des WPF auch schnell und zeitneutral selbst umsetzen. Ebenfalls vorteilhaft ist der vektorbasierte Ansatz des WPF; die Auflösung des jeweiligen Bildschirms spielt in Zukunft keine Rolle mehr bei der Entwicklung von Windows-Anwendungen, da die genutzten Komponenten automatisch an die Bildschirmauflösung angepasst gezeichnet werden. Auch ist die Anwendung nicht mehr nur auf den Client begrenzt, sondern kann auch als Webanwendung - eine sogenannte Web Browser Application (WBA) - gestartet werden.

Nachteilig ist bei der WPF die Tatsache anzusehen, dass die Anforderungen der Technologie an die Hardware des Zielsystems sehr hoch sind. Als Betriebssystem wird mindestens Windows XP - nur mit Service Pack - verlangt. Die vollständige Darstellung der Animationen, 3D- und Transparenzeffekte setzt eine leistungsstarke Grafikkarte mit DirectX-Unterstützung und genügend Arbeitsspeicher (RAM) voraus. Gerade bei der Entwicklung von Business-Anwendungen werden häufig fehlende Steuerelemente für die Darstellung komplexer Geschäftsdaten (z. B. Tabellen-Steuerelemente) als Kritik an Mircosoft herangetragen. Zwar bieten viele Drittanbieter solche Steuerelement-Lösungen an, jedoch sind diese mit nicht unerheblichen Zusatzkosten verbunden. Ebenso ist die - auch als Vorteil geltende - Funktionalität, die Anwendungen als WBA zu starten, kritisch zu betrachten. So handelt es sich nicht wirklich um eine "reale" Webanwendung im Sinne eines ASP.NET-Programms sondern um eine herkömmliche Client-Anwendung, die mit Hilfe des .NET-Frameworks im Browser angezeigt wird. Dies bedeutet, dass zur Ausführung der Anwendung das .NET-Framework ab Version 3.0 auf dem Zielclient installiert sein muss. ^[12]

7.2 Ausblick

Die zahlreichen Anforderungen, die WPF zur Ausführung seiner Anwendung stellt, führen dazu, dass die veraltete Technologie der Windows Forms noch bis heute im .NET-Framework enthalten ist. Dies berechtigt zu der Annahme, dass eine völlige Ablösung der Windows Forms durch WPF als GUI-Framework in naher Zukunft nicht erfolgen wird. Auch der hohe Lernaufwand beim Umstieg auf WPF führt dazu, dass ein schneller Umstieg von Windows Forms auf WPF nicht ohne Weiteres möglich ist. Die durch den Umstieg kurz- bzw. mittelfristigen Verdienstausfälle - die seitens vieler Unternehmen entstehen würden - wären für diese weder tolerierbar noch finanziell tragbar.

Die Verwendung eines solchen Frameworks, gerade im Hinblick auf portable Systeme wie Netbooks und Tablets, bietet gerade durch seine Losgelöstheit von Auflösungsbeschränkungen vielfältige Möglichkeiten. So bleibt abzuwarten, inwiefern die WPF-Technologie Einzug in die Entwicklung von Smartphone- und Tablet-Betriebssystemen erhält. Als Beispiel sei Mircosofts neues mobiles Betriebssystem "Windows Phone 7" anzuführen, welches nicht auf neue Technologien setzt sondern weiterhin die Microsoft-typische Sprache C# verwendet. ^[13] Ein eigenes WPF-ME (Windows Presentation Foundation - Mobile Edition) wäre somit nicht undenkbar.

8 Anhang

8.1 Abbildungsverzeichnis

Nr.	Abbildung
Abbildung 1	GDI+ Programmbibliothek
Abbildung 2	WPF - Architektur
Abbildung 3	MilCore Kommunikation über DirectX
Abbildung 4	Codebeispiel XAML-Syntax
Abbildung 5	Codebeispiel C#-Syntax
Abbildung 6	Codebeispiel Property-Element-Syntax
Abbildung 7	Codebeispiel Markup-Erweiterungen
Abbildung 8	Codebeispiel Markup-Erweiterungen mit gewöhnlichen Objektelementen
Abbildung 9	Codebeispiel zwei Text-Objekte in einem StackPanel
Abbildung 10	Codebeispiel zwei Text-Objekte in einem StackPanel ohne Angabe eines Eigenschaft-Elements
Abbildung 11	Codebeispiel Hashtable mit drei Kindelementen
Abbildung 12	Codebeispiel ResourceDictionary
Abbildung 13	Klassenhierarchie FrameworkElement
Abbildung 14	Codebeispiel für eine Schaltfläche die ein StackPanel enthält, welche auch mehrere Elemente in sich trägt
Abbildung 15	Codebeispiel für einen button mit einem String als Content-Eigenschaft
Abbildung 16	Margin
Abbildung 17	Alignments

8.2 Tabellenverzeichnis

Nr.	Tabelle
Tabelle 1	ContentControls und ihre Einsatzzwecke
Tabelle 2	ItemsControls und ihre Einsatzzwecke
Tabelle 3	TextControls und ihre Einsatzzwecke

8.3 Abkürzungsverzeichnis

Abkürzung	Beschreibung
.NET	Eine von Microsoft entwickelte Laufzeitumgebung für Anwendungen (Dot-NET gesprochen)
API	Application Programming Interface
C	Programmiersprache C
C#	Programmiersprache C-Sharp
CLI	Common Language Infrastructure
CLR	Common Language Runtime
GDI+	Graphical Device Interface
GUI	Grafical User Interface
WPF	Windows Presentation Foundation

8.4 Glossar

Begriff	Beschreibung
Alignment	Anordnung von Komponenten. Alignment heißt zu deutsch soviel wie "Ausrichtung"
API	Eine Programmierschnittstelle für Entwickler, welche es Ermöglicht auf bestimmte interne Funktionsabläufe fremder Bibliothken zuzugreifen. [14]
Compiler	Übersetzt Quellcode in Maschinensprache.
Control	Ein Steuerelement, welches durch die WPF bereitgestellt wird.
CIL	Eine Zwischensprache, in die alle Programme übersetzt werden. Dieser Programmcode wird auf dem Zielsystem in den systemeigenen Programmcode übersetzt, um die Ausführung zu gewährleisten.
Client-Server	Bei Client-Server handelt es sich um einen Ansatz, bei dem Daten und Applikationen zentral auf einem Server verwaltet und abgelegt werden, wobei der Client (Endanwender) diese Daten von eben jenem Server bezieht. So wird der Speicherbedarf für Daten und Anwendungen gering gehalten.
CLR	Die Common Language Runtime ist die Laufzeitumgebung von .NET und dient als Interpreter für die standardisierten Common Intermediate Language (CIL) dar.
CLR-Namespace	In der WPF definierte Namenräume, auf die vom XAML-Prozessor verwendet wird, um diese einem einzelnen XAML-Namespace zuzuordnen. [15]
Data-Binding	Ein durch WPF bereitgestellte Lösung für Anwendungen Daten zu präsentieren und diese zu verarbeiten. [16]
DirectX	Eine Programmierschnittstelle für interaktive Technologien. Seit Windows Vista/7 wird DirectX auch zu generierung (Rendering) von Benutzeroberflächen genutzt.
Hashtable	Eine - in Tabellenform vorliegende - Datenstruktur für schnellen Zugriff und Verwaltung von Daten. Werden in vielen Programmiersprachen (C#, Java) genutzt.
GDI+	Eine klassenbasierte API für C/C#-Entwickler, welche zur Ausgabe von Grafiken und formatiertem Text unter Windows dient. Sie dient als Schnittstelle zwischen Grafikhardware und Anwendung.
MilCore	Schnittstelle zwischen DirectX und der Applikation.
Parsen	Zerlegung und Umwandlung einer Zeichenkette zur Weiterverarbeitung.
Rendern	Als rendern wird das Zeichnen der Komponenten auf den Bildschirm bezeichnet.
String	Eine Zeichenkette mit beliebigen Buchstaben, Zeichen oder Wörtern. [17]
Suffix	Erweiterung einer Zeichenkette. In Windows ist Suffix bekannt als "Dateiendung".
Templates	Eine Mustervorlage oder Schoblone für alle Arten von Strukturen. Es existieren beispielsweise Templates für Webanwendungen und Applicationen.
Wrapper	Ein Wrapper bildet eine Art Rahmen um verschiedene Arten von Strukturen (z. B. Objekte, Programmen, etc.). Dieser kann aus Zwecken der Zugriffsbeschränkung, Sicherstellung der Kompatibilität oder etwa Erweiterung von Funktionen eingesetzt werden.[18]
XMLNS	Ein XML-Namespace, welche die Methode zur Qualifizierung von Element- und Attributnamen bereitstellt. [19]

8.5 Fußnoten

1. ↑ Thomas Claudius Huber, Windows Presentation Foundation: Das umfassende Handbuch (2010), S. 48
2. ↑ vgl. Thomas Claudius Huber, Windows Presentation Foundation: Das umfassende Handbuch (2010), S. 53 ff.
3. ↑ vgl. Thomas Claudius Huber, Windows Presentation Foundation: Das umfassende Handbuch (2010), S. 146 ff.
4. ↑ vgl. Thomas Claudius Huber, Windows Presentation Foundation: Das umfassende Handbuch (2010), S. 149
5. ↑ vgl. Thomas Claudius Huber, Windows Presentation Foundation: Das umfassende Handbuch (2010), S. 160
6. ↑ vgl. Thomas Claudius Huber, Windows Presentation Foundation: Das umfassende Handbuch (2010), S. 179
7. ↑ vgl. Thomas Claudius Huber, Windows Presentation Foundation: Das umfassende Handbuch (2010), S. 180
8. ↑ vgl. Thomas Claudius Huber, Windows Presentation Foundation: Das umfassende Handbuch (2010), S. 179 ff.
9. ↑ vgl. Thomas Claudius Huber, Windows Presentation Foundation: Das umfassende Handbuch (2010), S. 261 ff.
10. ↑ vgl. Thomas Claudius Huber, Windows Presentation Foundation: Das umfassende Handbuch (2010), S. 286 ff.
11. ↑ Thomas Claudius Huber, Windows Presentation Foundation: Das umfassende Handbuch (2010), S. 310 f.
12. ↑ vgl. www.it-visions.de | Dr. Holger Schwichtenberg: Erklärung des Begriffs: Windows Presentation Foundation (WPF)
13. ↑ vgl. Silverlight, WPF & .NET: Gründe um Windows Phone 7 Applikationen zu entwickeln
14. ↑ vgl. ITWissen.info: API
15. ↑ vgl. MSDN: XAML-Namespaces und Namespacezuordnung für WPF-XAML
16. ↑ vgl. MSDN: Data Binding Overview
17. ↑ vgl. ITWissen.info: String
18. ↑ vgl. www.at-mix.de: Wrapper-Info
19. ↑ vgl. W3C: Namespaces in XML 1.0 (Third Edition)

8.6 Literatur- und Quellenverzeichnis

Thomas Claudius Huber	Windows Presentation Foundation: Das umfassende Handbuch, Galileo Computing; 2. Auflage, Juni 2010
www.it-visions.de | Dr. Holger Schwichtenberg	Erklärung des Begriffs: Windows Presentation Foundation (WPF) Was ist Windows Presentation Foundation (WPF)?, http://www.it-visions.de/glossar/alle/3718/lexikon.aspx (07.01.2011)
Silverlight, WPF & .NET	Gründe um Windows Phone 7 Applikationen zu entwickeln, 05. Dezember 2010, http://www.ebnerj.at/blog/?p=1087 (07.01.2011)
www.at-mix.de | Wilhelm Janssen	Wrapper-Info, 19. Oktober 2004, http://www.at-mix.de/wrapper.htm (08.01.2011)
W3C	Namespaces in XML 1.0 (Third Edition), 08. Dezember 2009, http://www.w3.org/TR/REC-xml-names/ (08.01.2011)
MSDN	Control Library, http://msdn.microsoft.com/en-us/library/ms752324.aspx (09.01.2011)
MSDN	Data Binding Overview, http://msdn.microsoft.com/en-us/library/ms752347.aspx (08.01.2011)
MSDN	XAML-Namespaces und Namespacezuordnung für WPF-XAML, http://msdn.microsoft.com/de-de/library/ms747086.aspx (08.01.2011)
ITWissen.info	String, http://www.itwissen.info/definition/lexikon/String-string.html (08.01.2011)
ITWissen.info	API (application programming interface), http://www.itwissen.info/definition/lexikon/application-programming-interface-API-Programmierschnittstelle.html (08.01.2011)	}