Windows Presentation Foundation - Eine Übersicht
Die Windows Presentation Foundation (WPF) ist ein neues grafische Subsystem im .NET Framework 3.0. Anders als oftmals behauptet, hat WPF nichts mit Windows Vista zu tun und ist auch auf einem Rechner mit Windows XP SP 2 nutzbar. Der einzige Unterschied ist, dass die 3.0-Version des Frameworks direkt mit Windows Vista installiert wird.
Mit Einführung der WPF unternimmt Microsoft erste Schritte, die veralteten Vorgehensweisen für die Darstellung von Bildschirminhalten zu überarbeiten. Alle grafischen Elemente der WPF werden durch Direct3D realisiert, was wiederum eine Auslagerung des Bildaufbaus auf die Grafikkarte zur Folge hat. Obwohl alle neueren Rechner schon leistungsfähige Grafikhardware haben, war es bisher immer die CPU, die alleinig für den Bildaufbau des Windows Desktop verantwortlich war. WPF entlastet die CPU und übergibt den Aufbau von Fenstern und deren Inhalte an die Grafikkarte. Dabei werden überwiegend vektorbasierte Daten verwendet, die eine stufenlose Skalierung von Steuerelemente ohne Qualitätsverlust ermöglicht.
Im Unterschied zu seinen Vorgängertechnologien arbeitet die WPF auch nicht mehr mit Pixeln als Maßeinheit. Alle Angaben werden in logischen Einheiten gemacht, was zur Folge hat, dass Programmfenster bei hochauflösenden Bildschirmen nicht keiner werden, sondern bei gleichbleibender Größe eine höhere Qualität liefern. Bei einer Auflösung von 96dpi entspricht eine logische Einheit aber wieder einem Pixel.
Für einen Entwickler ist einer der Schwerpunkte der WPF eine Sprache mit Namen XAML (Extensible Application Markup Language), eine auf XML basierte Sprache zur Deklaration von Objekten und deren Eigenschaften. Allerdings ist XAML keine vollständige Programmiersprache. Für die Funktionalität im Hintergrund benötigt man immer noch C# oder eine andere Programmiersprache, obwohl sich Dinge wie Data-Binding oder Animationen durchaus schon im XAML-Code realisieren lassen. XAML dient aber überwiegend zur Layout-Definition, ähnlich wie HTML dies für Webseiten tut. So sollten Personen mit HTML Kenntnissen auch sehr schnell XAML-Code schreiben und interpretieren können, denn auch hier werden öffnende und schließende Tags verwendet.
Einer der großen Vorteile, die für die Verwendung von XAML sprechen, ist die strenge Trennung von Design und Funktionalität. So ist es durchaus vorstellbar, dass Grafiker das Aussehen eines Programms bestimmen und Softwareentwickler nur noch die Programmlogik implementieren. Etwas leistungsstärker als der Designer im Visual Studio ist „Expression Blend“, vormals „Expression Interactive Designer“. Dort kann eine Benutzeroberfläche wirklich ‚gezeichnet‘ werden und der Entwickler kann später dieses Design in sein Programm einbinden. Mit Blend ist es sogar möglich, direkt Visual Studio Projekte zu laden.
Nötig ist so ein Programm natürlich nicht. Man kann XAML-Deklarationen auch von Hand schreiben.
Will man zum Beispiel eine Schaltfläche definieren, sähe das im XAML-Code so aus:
<Button
Name="bt1">Hier Klicken</Button>
Nun ist es ein
leichtes im C#-Code ein Ereignis (event) an zu
hängen und auf Eingaben eines Benutzers zu
reagieren. Wichtig ist hierfür nur, dass der
Schaltfläche ein Name zugewiesen wurde. Die
Konstruktor-Methode des Fensters ist in der Regel
ein guter Ort um Ereignisse fest zu legen.
public
Window1()
{
InitializeComponent();
bt1.Click += new RoutedEventHandler(bt1_Click);
}
{
InitializeComponent();
bt1.Click += new RoutedEventHandler(bt1_Click);
}
Die aufzurufende
Methode könnte dann so aussehen:
void
bt1_Click(object sender, RoutedEventArgs e)
{
MessageBox.Show("geklickt");
}
{
MessageBox.Show("geklickt");
}
Es gibt eine
Alternative zu dieser Vorgehensweise, denn auch
schon im XAML-Code können die Methoden zur
Ereignissteuerung bestimmt werden. Wie hier für das
Klick-Ereignis.
<Button
Name="bt1" Click="bt1_Click">Hier
Klicken</Button>
Diese Art der
Ereignissteuerung hat allerdings einen
entscheidenden Nachteil. Zwar kann man einem
Grafiker durchaus zutrauen einen passenden
Methodennamen zu wählen, aber diese Methode muss im
Programmcode dann auch schon vorhanden sein. Ist
dies nicht der Fall, lässt sich das Programm nicht
ausführen. Ein Programm schrittweise aufzubauen ist
so etwas schwierig. Die strikte Trennung zwischen
Layout und Funktion wird auf diese Art also etwas
eingeschränkt.
WPF-Steuerelemente sind eigentlich ‚lookless', das heißt sie haben kein Aussehen. Dass man aber trotzdem etwas zu sehen bekommt, wenn man einen Button deklariert, liegt daran, dass für alle Steuerelemente ein Standarddesign mitgeliefert wird. Aber die optische Erscheinung eines Steuerelements hat mit der eigentlich Funktionalität nichts zu tun und kann beliebig manipuliert werden.
WPF-Steuerelemente sind eigentlich ‚lookless', das heißt sie haben kein Aussehen. Dass man aber trotzdem etwas zu sehen bekommt, wenn man einen Button deklariert, liegt daran, dass für alle Steuerelemente ein Standarddesign mitgeliefert wird. Aber die optische Erscheinung eines Steuerelements hat mit der eigentlich Funktionalität nichts zu tun und kann beliebig manipuliert werden.