Rainer Stropek Karin Huber XAML. schnell + kompakt

Transkript

1 XAML

2

3 Rainer Stropek Karin Huber XAML

4 Rainer Stropek, Karin Huber XAML ISBN entwickler.press, ein Imprint der Software & Support Verlag GmbH 1. Auflage, Ihr Kontakt zum Verlag und Lektorat: Bibliografische Information Der Deutschen Bibliothek Die Deutsche Bibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar. Korrektorat: Petra Kienle Satz: text & form GbR, Carsten Kienle Umschlaggestaltung: Caroline Butz Belichtung, Druck und Bindung: M.P. Media-Print Informationstechnologie GmbH, Paderborn. Alle Rechte, auch für Übersetzungen, sind vorbehalten. Reproduktion jeglicher Art (Fotokopie, Nachdruck, Mikrofilm, Erfassung auf elektronischen Datenträgern oder andere Verfahren) nur mit schriftlicher Genehmigung des Verlags. Jegliche Haftung für die Richtigkeit des gesamten Werks kann, trotz sorgfältiger Prüfung durch Autor und Verlag, nicht übernommen werden. Die im Buch genannten Produkte, Warenzeichen und Firmennamen sind in der Regel durch deren Inhaber geschützt.

5 Inhaltsverzeichnis Vorwort 7 Kapitel 1: Einleitung 9 Kapitel 2: Hinter den Kulissen Einleitung Voraussetzungen Basiskonzepte von XAML Hello World in XAML Kompilieren von XAML-Dateien 24 XAML und MSBuild 24 Die Build-Ergebnisse Application Definition Files Zusammenfassung 45 Kapitel 3: XAML Namespaces Einleitung 47 CLR Namespace 48 XML Namespace Namespaces in XAML-Dateien Elemente im Namespace x: 55 x:array 55 x:class, x:classmodifier, x:subclass, x:typearguments 57 x:code 59 x:name, x:fieldmodifier 60 x:key, x:shared 61 x:null 62 x:static 63 x:type 64 x:xdata 65 5

6 Inhaltsverzeichnis 3.4 XML-Attribute in XAML 67 xml:space 67 xml:lang 68 mc:ignorable, mc:processcontent Zusammenfassung 69 Kapitel 4: Die Sprache XAML Einleitung 71 XAML als deklarative Programmiersprache 71 Das Beispiel Die Basiselemente von XAML 74 XAML-Elemente 74 XAML-Attribute 77 Attribute mit Typkonvertierung 81 Markup Extensions 86 Attached Properties Zusammenfassung 98 Kapitel 5: XAML und WF Einleitung XAML oder C#? XAML mit WF ein Beispiel Kompilieren von XAML Workflows Zusammenfassung 107 Kapitel 6: XAML Tools Einleitung Systemvoraussetzungen Tools 111 Microsoft Visual Studio 112 Microsoft Expression Blend 114 XAMLPad 115 Stichwortverzeichnis 117 6

7 Vorwort Wir sind mit Leib und Seele Softwareentwickler! Wir hatten das große Glück, unser Hobby, unsere Leidenschaft zum Beruf machen zu können. Da Sie dieses Buch in Händen halten, ist es recht wahrscheinlich, dass Sie in der gleichen Branche arbeiten wie wir. Daher sind Sie ebenfalls mit der rasend schnellen Weiterentwicklung unserer Branche vertraut. In den letzten Jahren hat sich nach unserer Erfahrung das Tempo der Innovation noch deutlich beschleunigt. Der letzte Höhepunkt dieser Entwicklung ist die Veröffentlichung der neuen, in Windows Vista enthaltenen Komponenten Windows Presentation Foundation (WPF) und Workflow Foundation (WF). Die Marketingmaschinerie von Microsoft tut ihr Bestes, um insbesondere WPF und XAML in den schillerndsten Farben mit beeindruckenden Beispielen anzupreisen. Und tatsächlich die neuen Möglichkeiten sind enorm. Für uns Softwareentwickler heißt das aber zurück auf die Schulbank! Wenig von unserem über die Jahre hinweg gesammelten Wissen über Programmierung von Windows-Anwendungen ist noch gültig. Als wäre der überwältigende Umfang der WPF-Klassenbibliotheken nicht schon genug, erscheint auch noch XAML als neue Sprache auf der Bildfläche. Auf den ersten Blick ist XAML nichts Neues, XML zur Definition von Benutzeroberflächen eben. Beschäftigt man sich jedoch genauer damit, wird ein viel mächtigeres und breiter einsetzbares Konzept sichtbar. Wir möchten Sie in diesem Buch mit der neuen Sprache XAML vertraut machen. Unser Ziel ist nicht die vollständige Beschreibung von WPF oder WF, das würde den Rahmen sprengen. Aufgrund ihrer Bedeutung beim Umgang mit XAML werden wir jedoch bei allen Sprachkonzepten immer konkrete Beispiele aus 7

8 Vorwort diesem Bereichen zeigen. Nichtsdestotrotz demonstrieren wir die Sprachelemente auch anhand von WPF- und WF-unabhängigen Beispielen, um vorzuführen, wie in eigenen Anwendungsfällen XAML ganz unabhängig von Benutzerschnittstellen oder Workflows verwendet werden kann. Als.NET-Programmiersprache verwenden wir in diesem Buch ausschließlich C#, auf eine Darstellung der Beispiele in VB.NET wird verzichtet. Das heißt aber auf keinen Fall, dass XAML nur in Verbindung mit C# zu verwenden ist! Falls Sie VB.NET-Entwickler sind, steht Ihnen die Funktionalität der neuen Sprache natürlich ebenfalls vollständig zur Verfügung. In diesem Fall hoffen wir, dass Sie von den in diesem Buch enthaltenen Beispielen ebenfalls profitieren und die Konzepte auf die von Ihnen gewählte Programmiersprache anwenden können. Rainer Stropek, Karin Huber 8

9 KAPITEL 1 Einleitung Windows Vista wird gerne als Meilenstein in der Entwicklung von Betriebssystemen aus dem Hause Microsoft bezeichnet. Es werden Vergleiche mit dem Umstieg von Windows 3.x auf Windows 95 gezogen, mit Superlativen wird nicht gespart. Tatsächlich bringt das Betriebssystem viele nützliche Neuerungen für den täglichen Bedarf von typischen Windows-Benutzern. Hinter den Kulissen fand jedoch eine kleine Revolution statt. Diejenigen, die am meisten die Auswirkungen dieser Revolution zu spüren bekommen, sind die Softwareentwickler. Mit Windows Vista erblickte eine Reihe von Komponenten das Licht der Welt, die bisher von Programmierern mühsam selbst zu entwickeln waren oder die man für teures Geld von Drittanbietern zukaufen musste. Im Speziellen sprechen wir von Modulen wie Windows Presentation Foundation (WPF) oder Windows Workflow Foundation (WF). Mit WPF stellt Windows eine von Grund auf neue Komponente zur Umsetzung grafischer Benutzeroberflächen zur Verfügung. WF ist ein Modul zur Gestaltung und Steuerung von Geschäftsprozessen, die einfach und schnell mit eigener Logik verknüpft werden können. 9

10 1 Einleitung Aus Sicht eines Programmierers von Windows-Anwendungen sind WPF und WF nichts anderes als Klassenbibliotheken, die zwar einen enormen Funktionsumfang mit sich bringen, auf den ersten Blick jedoch im Wesentlichen genauso zu verwenden sind, wie andere Klassenbibliotheken auch. Auf den zweiten Blick entdeckt man, dass eine komplett neue Sprache aufgetaucht ist: XAML (XML Application Markup Language). Sie wird sowohl von WPF als auch von WF genutzt. Keine Angst, liebe C#-Programmierer! XAML ist kein Ersatz für C#, es handelt sich um eine Ergänzung. Die Idee, die hinter der Einführung von XAML steckt, ist klar und nicht neu: Trennung von Layout und Logik. In WPF dient XAML zur Kapselung des Aussehens der Benutzerschnittstelle, in WF wird es verwendet, um die Separierung von Geschäftsprozessen und Programmlogik zu ermöglichen. Webentwickler fühlen sich sofort wie zu Hause, schließlich kennen sie dieses Konzept aus ASP.NET schon seit Jahren. Dort hat sich die Trennung von Layout (HTML) und Logik (C#) ohne Zweifel bewährt. Warum ist das so? Sind Sprachen wie C# weniger gut geeignet, um Steuerelemente in einer Windows Form zu platzieren? Hat sich vielleicht herausgestellt, dass Programmierer effizienter beim Schreiben von XML als beim Entwickeln in VB.NET sind? Nein, der Grund für den Erfolg dieses Programmierparadigmas ist nicht in der Technik zu finden. Er ergibt sich aus der immer stärker werdenden Arbeitsteilung bei Softwareentwicklungsprojekten. Lassen Sie uns einen Moment bei WPF bleiben. Windows bietet mittlerweile einen Funktionsumfang für die Entwicklung von Full-Client-Anwendungen, der enorm ist. Die Tage der altbekannten grauen Windows-Formulare sind spätestens seit Vista endgültig vorbei, die Welt wurde auch für normale Windows- Anwendungen wieder bunt. In WPF hat der Entwickler völlige Freiheit, was das Aussehen von Fenstern und Steuerelementen 10

11 Einleitung betrifft. Er kann selbst die klassischen Elemente wie Buttons, Textboxen, Listboxen oder Menüs in ihre kleinsten Einzelteile zerlegen, grafisch völlig neu gestalten und wieder zusammensetzen. Obwohl das im ersten Moment bestechend klingt, stellt es Softwareentwicklungsteams vor eine völlig neue Herausforderung: Was tun mit dieser neu gewonnenen Freiheit? Teammitglieder mit Design- und Grafikkenntnissen sind gefragt! Die Gestaltung von Benutzeroberflächen wird viel mehr zu einem kreativen Prozess. In der Praxis zeigt sich jedoch, dass nicht in jedem Programmierer ein begnadeter Designer steckt. Umkehrt gilt auch, dass viele GUI-Designer oft nicht die besten Softwareentwickler sind. Es muss also ein Weg zur effizienten Aufgabenteilung gefunden werden. An dieser Stelle kommt das oben erwähnte Konzept der Trennung von Layout und Code ins Spiel. Lassen Sie uns dieses Prinzip der Trennung an einem Beispiel erklären. Zum Anzeigen eines Fensters mit einem Button sind in WPF nur wenige Zeilen C#-Code notwendig: using System; using System.Windows; using System.Windows.Controls; namespace Csharp_Xaml_Vergleich class CsharpWindow : Window private Button button1; public CsharpWindow() Width = 300; Height = 130; Title = "Csharp_Xaml_Vergleich"; 11

12 1 Einleitung button1 = new Button(); button1.margin = new Thickness(5,5,5,5); button1.content = "Say Hello..."; button1.click += OnButton1_Click; Content = button1; public void OnButton1_Click( Object sender, RoutedEventArgs e) MessageBox.Show("Hello!"); Diese C#-Datei ist ein klassisches Beispiel für die Vermischung von Layout und Logik. Durch Nutzung von XAML lassen sich diese beiden Aspekte des Programms gut trennen. Hier erst der Layoutteil unseres Beispiels in XAML: <Window x:class="csharp_xaml_vergleich.xamlwindow" xmlns=" presentation" xmlns:x=" Title="Csharp_Xaml_Vergleich" Height="130" Width="300" > <Button Margin="5,5,5,5" Click="OnButton1_Click">Say Hello... </Button> </Window> Der Logikteil bleibt wie im vorigen Beispiel in der C#-Datei: 12

13 Einleitung using System; using System.Windows; namespace Csharp_Xaml_Vergleich public partial class XamlWindow : Window public XamlWindow() InitializeComponent(); public void OnButton1_Click( Object sender, RoutedEventArgs e) MessageBox.Show("Hello!"); Abbildung 1.1 stellt den Zusammenhang von XAML und C# grafisch dar: Abb. 1.1: Zusammenhang XAML und C# 13

14 1 Einleitung XAML wurde also insbesondere für Designer und die von ihnen verwendeten Werkzeuge entwickelt. Ist dieses Buch also ein Buch für Designer? Nur zum Teil. Technikorientierte Designer werden wie das auch im Web mit HTML der Fall ist sicherlich die Finger nicht von XAML lassen können. Schließlich ist die Sprache einfach zu lesen und da XAML auf XML basiert, ist eine unüberschaubare Vielzahl von Werkzeugen am Markt verfügbar, mit denen XAML-Quellcode bearbeitet werden kann. Der überwiegende Teil der GUI-Designer wird jedoch mit grafischen Werkzeugen arbeiten. Insbesondere für diese Werkzeuge wurde XAML geschaffen. Ein Grafiker entwirft die Benutzeroberfläche in einem Tool, das die Spezifikation der Benutzeroberfläche in Form von XAML-Code serialisiert. Der Programmierer auf der anderen Seite nutzt XAML zur Laufzeit, um den notwendigen Baum von Objekten im Speicher anzulegen (siehe dazu auch Abbildung 1.2), verknüpft ihn mit der von ihm entwickelten Programmlogik und fertig ist die Windows-Anwendung. Beide Benutzergruppen, Designer und Programmierer, können mehr oder weniger unabhängig (das bedeutet nicht unkoordiniert!) an ihrer Aufgabe arbeiten und die Ergebnisse anschließend wieder zusammenführen. Abb. 1.2: Deserialisierung von XAML 14

15 Einleitung Es stellt sich die Frage, warum mit XAML eine neue Sprache geschaffen werden musste. Der Windows Forms Designer von.net 2.0 kam schließlich auch ohne aus, er erzeugte direkt, ohne Umwege C#- oder VB.NET-Code. Der Grund für XAML als Serialisierungs- und Deserialisierungsstandard ist die Einfachheit des Umgangs mit XML-basierenden Sprachen in Tools. Jeder.NET-Entwickler weiß, wie einfach und gut unterstützt das Schreiben und Lesen von XML-Dateien ist. Dazu kommt, dass XML ein plattformunabhängiger Standard ist. Reduziert man XAML auf das absolute Minimum, kann man es als XML-basierendes Serialisierungswerkzeug bezeichnen, das gegenüber den schon früher in.net existierenden, XML-basierten Pendants um einige nützliche Neuerungen ergänzt wurde. Wir haben jetzt viel über die Anwendung von XAML in Verbindung mit Benutzerschnittstellen berichtet und damit den Sinn der neuen Sprache erklärt. Es ist jedoch nicht so, dass XAML ausschließlich für Benutzerschnittstellen verwendet wird. Oben wurde schon erwähnt, dass auch WF XAML einsetzt. Der Grund ist, dass sich auch im Bereich der Geschäftsprozesssteuerung gezeigt hat, dass eine Arbeitsteilung Sinn macht: Geschäftsprozessspezialisten gestalten die Prozesse mit entsprechenden grafischen Werkzeugen, die Prozessdefinition wird mithilfe von XAML als XML-basierte Datei gespeichert und anschließend mit der von Programmierern geschriebenen Programmlogik gemischt. Auch wenn im Moment XAML primär in Verbindung mit den Microsoft-Bibliotheken WPF und WF in Zusammenhang gebracht wird, besteht eine gute Chance, dass sich in der Zukunft noch andere Bereiche in der Softwareentwicklung finden, bei denen Spezialisten mit der Unterstützung spezifischer Tools gewisse Aspekte eines Softwaresystems modellieren. XAML kann in 15

16 1 Einleitung all diesen Fällen als Schnittstelle zwischen diesen Werkzeugen und Programmlogik dienen. Durch die breite Anwendungsmöglichkeit von XAML ergeben sich Fragen, die Sie sich im Lauf des Lesens dieses Buchs auf jeden Fall stellen werden: Wenn XAML ein so allgemeines Konzept ist, warum ist dann der XAML-spezifische Namespace Markup im WPF Namespace System.Windows zu finden? Warum enthält eine Projektdatei einer Konsolenanwendung, die XML benutzt, Verweise auf WPF-spezifische Elemente? Die Gründe für diese Widersprüche liegen in der Vergangenheit von XAML. Die Sprache wurde im Zuge der Entwicklung von WPF erfunden und daher von Microsoft auch in diesem Bereich des.net Framework implementiert. Eine klare Trennlinie zwischen XAML und WPF lässt sich im Augenblick nicht ziehen. Es bleibt abzuwarten ob Microsoft in der Zukunft daran etwas ändern wird. Im Moment muss man sich mit einer gewissen Trennunschärfe abfinden. 16

17 Hinter den Kulissen KAPITEL Einleitung Voraussetzungen Basiskonzepte von XAML Hello World in XAML Kompilieren von XAML-Dateien Application Definition Files Zusammenfassung Einleitung Bevor wir uns ansehen, was uns die Sprache XAML an Möglichkeiten bietet, sollten wir einen Blick hinter die Kulissen werfen. Während der normalen Arbeit findet man viel zu selten die Gelegenheit, hinter die Zauberei von Visual Studio zu sehen. Schließlich werden die meisten Entwickler auf Produktivität getrimmt und nicht dafür bezahlt, die Konzepte hinter ihrer IDE zu erforschen. Spätestens wenn man den standardmäßig von Visual Studio vergebenen Klassennamen Window1 für das Startfenster seiner Applikation ändern möchte, bereut man diese Herangehensweise. Ein tiefergehendes Verständnis der grundlegenden Ideen ist in genau diesen Fällen gefragt. In diesem Kapitel tauchen wir in die dunklen Tiefen von XAML ab. Unser Ziel ist es, anhand des einfachsten möglichen XAML- Programms die Elemente zu verstehen, aus denen es besteht, sowie den Build-Prozess zu analysieren. 17

18 2 Hinter den Kulissen 2.2 Voraussetzungen Ein großer Teil dieses Buchs besteht aus Beispielen. Wenn Sie diese Beispiele nachvollziehen oder selbst zu experimentieren beginnen wollen, brauchen Sie als Erstes die Laufzeitkomponenten des.net Framework 3.0. Falls Sie schon mit Windows Vista arbeiten, braucht Sie diese Voraussetzung nicht zu kümmern, da Vista die neue Version des.net Framework von Haus aus mitbringt. Wie der Name schon sagt, sind die Laufzeitkomponenten zur Laufzeit notwendig. Es reicht also nicht, wenn sie auf den Entwicklungsrechnern installiert sind. Sie müssen auf jedem Computer, auf dem die erstellte Software ausgeführt werden soll, installiert sein. Die zweite Komponente brauchen Sie zum Entwickeln von Software mit XAML: der Microsoft Windows SDK. Er enthält Beispiele, Bibliotheken, Tools u.v.m. Es reicht, ihn auf Entwicklungsarbeitsplätzen zu installieren. Zum Ausführen von Programmen, die auf Basis von.net 3.0 entwickelt wurden, ist er nicht notwendig. Last but not least müssen Sie Ihr Visual Studio um die Erweiterungen für WPF und/oder WF ergänzen. Diese Komponente ist für WPF nicht in einer finalen Version erhältlich. Microsoft stellt ausschließlich CTPs (Community Technology Previews) zur Verfügung. Eine endgültige Unterstützung von WPF in Visual Studio wird erst mit der nächsten Version dieses Produkts verfügbar sein (Codename Orcas). In unseren Beispielen setzen wir die Erweiterungen für WPF voraus. Falls Sie auch die Beispiele aus Kapitel 5 nachvollziehen möchten, sind noch die Erweiterungen für WF erforderlich. Die genannten Komponenten können Sie von der Microsoft- Website kostenlos herunterladen. Alle Details zu Systemvoraussetzungen und Tools rund um XAML, WPF und WF haben wir für Sie in Kapitel 6 zusammengefasst. 18

19 Basiskonzepte von XAML 2.3 Basiskonzepte von XAML Als Entwickler oder Architekt stößt man zwangsläufig auf XAML, wenn man sich mit der Programmierung von Benutzeroberflächen mit Windows Presentation Foundation (WPF) zu beschäftigen beginnt. Wirft man einen Blick auf Artikel und Bücher zu diesem Thema, so fällt auf, dass sich so gut wie alle diese Publikationen unter anderem auch mit XAML befassen. Im Gegensatz zur landläufigen Meinung ist XAML jedoch nicht ein Konzept, das untrennbar mit WPF verknüpft ist. Es ist wahr, dass XAML ursprünglich im Rahmen der Entwicklung von Avalon das war der Codename für WPF entstanden ist. Im Lauf der Zeit wurde jedoch klar, dass XAML ein viel allgemeineres Konzept darstellt: XAML wird genutzt, um einen Graphen von Objekten zu spezifizieren, der dann in einem.net-programm für verschiedenste Zwecke verwendet werden kann. Bei WPF beispielsweise legt der Objektgraph die Benutzerschnittstelle fest, bei Windows Workflow Foundation (WF) wiederum werden Geschäftsprozesse mit XAML definiert. XAML ist im Kern also nichts anderes als ein Serialisierungsmechanismus für Objektbäume. Jedes XAML-Element hat eine Entsprechung im Klassenmodell einer Anwendung. Eine Komponente, die als XamlReader bezeichnet wird, liest XAML-Code und instanziiert anhand von gewissen Regeln, auf die wir etwas später noch im Detail eingehen werden, Objekte der entsprechenden Klassen. Der Code, der hinter diesen Klassen steckt, ist für das Verhalten der Anwendung zur Laufzeit verantwortlich. Lesern, die mit der Entwicklung von ASP.NET-Anwendungen vertraut sind, wird dieses Konzept bekannt vorkommen. Auch dort findet man zumindest in gut geschriebenen ASP.NET- Programmen eine Trennung in Benutzerschnittstellendefinition (= Objektgraph, der beim Laden einer ASP.NET-Seite im Speicher aufgebaut wird) und Logik (= Code-behind-Dateien). Die 19

20 2 Hinter den Kulissen Grundidee ist bei XAML die gleiche. Die Sprache XAML muss jedoch allgemeiner gesehen werden, sie ist nicht auf die Spezifikation von Benutzerschnittstellen beschränkt. 2.4 Hello World in XAML Wie schon in.net ist die einfachste Form eines Programms, das XAML verwendet, eine Konsolenapplikation. Unser Ziel ist es, die klassische Hello World -Applikation unter Verwendung von XAML zu schreiben. Wie bereits erwähnt, dient XAML zur Erstellung eines Objektgraphen. Jedes XAML-Objekt muss dabei eine Entsprechung in einer.net-klasse haben. Daher ist der erste Schritt unseres Einsteigerbeispiels die Entwicklung der Klasse TextContainer, die den auszugebenden Text Hello World aufnehmen kann: namespace Samples public class TextContainer private string text; public string Text set text = value; get return text; [...] ; Ohne XAML würde die oben dargestellte Klasse verwendet, indem mit new ein Objekt erstellt wird. Mit XAML können wir jedoch diesen Schritt vom C#-Code trennen. Wir erstellen eine 20

21 Hello World in XAML XAML-Datei, die TextContainer verwendet und die Eigenschaft Text auf Hello World setzt: <y:textcontainer xmlns:x= " x:class="samples.helloworldtext" xmlns:y="clr-namespace:samples" Text="Hello World!" /> Zerlegen wir diese XAML-Datei in ihre Bestandteile: <y:textcontainer [...] xmlns:y="clr-namespace:samples" [...] /> Wie Sie im oben dargestellten Codeabschnitt sehen, verwendet die XAML-Datei als Wurzelelement y:textcontainer, also die zuvor entwickelte Klasse. Das y: vor dem Klassennamen verweist auf den zugehörigen XML Namespace. Er enthält einen Verweis auf den CLR-Namensraum, in dem die Klasse zu finden ist. Sie werden in diesem Buch in Kapitel 3 noch mehr Details zum Thema Namespaces in XAML erfahren. <y:textcontainer [...] x:class="samples.helloworldtext" [...]/> Der Eintrag x:class ist für den XAML Compiler von besonderer Bedeutung. Wie wir in wenigen Momenten sehen werden, erzeugt er im Hintergrund C#-Code und der Eintrag x:class legt den Namen der Klasse fest, die der Compiler erzeugen wird. Der 21

22 2 Hinter den Kulissen Typ des Wurzelelements ist die Basisklasse für die generierte Klasse. Abbildung 2.1 stellt diesen Zusammenhang grafisch als UML-Klassendiagramm dar. Abb. 2.1: Zusammenhang der Klassen aus der XAML-Datei Die generierte Klasse ist partiell. Das ermöglicht es dem Entwickler, die Klasse um weitere Methoden und Eigenschaften in eigenen Dateien zu erweitern, ohne dass der Codegenerator des XAML Compiler sie verändert oder überschreibt. Solche Dateien werden als Code-behind-Dateien bezeichnet. Diese Bezeichnung soll verdeutlichen, dass in den eigenen Codedateien die Logik hinter der durch XAML definierten Struktur (z.b. Bildschirmmasken, Workflows etc.) festgelegt wird. <y:textcontainer xmlns:x= " [...] /> Der Namespace x verweist auf den Standard-Namespace von XAML Beachten Sie, dass dieser Namespace weder von WPF noch von WF oder anderen konkreten Implementierungen von XAML abhängt. Er ist Teil der Basis-XAML-Sprachspezifikation. 22

23 Hello World in XAML <y:textcontainer [...] Text="Hello World!" /> Zu guter Letzt wird der gewünschte Ausgabetext der Eigenschaft Text zugewiesen. Sie wurde zuvor in der oben gezeigten C#-Datei definiert. Ergänzen wir den C#-Code unserer Anwendung noch um die für jede Konsolenanwendung verpflichtende Main-Methode, ist unser erstes XAML-Beispiel fertig: namespace Samples public class TextContainer [...] public static class Startup private static HelloWorldText text = new HelloWorldText(); public static void Main() text.initializecomponent(); System.Console.WriteLine(text.Text); ; Bei der Analyse dieses Quellcodes fällt auf, dass hier eine Klasse HelloWorldText verwendet wird, die jedoch nirgends im C#-Code definiert ist. Des Rätsels Lösung werden wir finden, sobald wir 23

24 2 Hinter den Kulissen im nächsten Schritt unser Beispiel übersetzen und uns ansehen, was der XAML-Compiler an Code für uns produziert. 2.5 Kompilieren von XAML-Dateien Viele Entwickler stellen die Frage, ob XAML interpretiert oder ob ähnlich wie beim Windows Forms Designer im Hintergrund Programmcode erzeugt wird. Die Antwort lautet: weder noch. Der XAML-Code selbst wird zur Laufzeit nicht interpretiert (obwohl das auch möglich ist; Details dazu siehe XAML zur Laufzeit behandeln in diesem Kapitel). Es wird jedoch XAML auch nur bedingt in Programmcode umgewandelt. Stattdessen wird XAML in eine schnell zu ladende, binäre Form namens BAML umgewandelt. Der generierte Code ist nur dafür zuständig, die entsprechende Methode zum Laden von BAML aufzurufen. In diesem Kapitel werden wir den Prozess des Kompilierens und Ladens von XAML genauer durchleuchten. Der Prozess des Kompilierens unterscheidet sich je nach Anwendungsgebiet von XAML. Windows Workflow Foundation (WF) kann beispielsweise ebenfalls XAML als Spezifikationssprache für Workflows verwenden. In WF sieht der Kompilierprozess für solche Dateien jedoch grundlegend anders aus als in WPF. In diesem Kapitel beschränken wir uns für den Moment auf die Beschreibung des Übersetzungsvorgangs in der Geburtsstätte von XAML, also in WPF. Auf die Besonderheiten von XAML in Verbindung mit WF gehen wir später ein. XAML und MSBuild Zum Kompilieren von Projekten, die XAML-Dateien enthalten, muss man auf MSBuild zurückgreifen. Es steht kein anderes Kommandozeilen-Werkzeug zur Verfügung, das auf die Übersetzung von XAML spezialisiert wäre. MSBuild nutzt die Klas- 24

25 Kompilieren von XAML-Dateien sen des Assembly presentationbuildtasks.dll (Namespace Microsoft.Build.Tasks.Windows) zum Übersetzen von XAML-Dateien. In der Praxis ist die Beschränkung auf MSBuild jedoch kein Nachteil, da dieses Werkzeug ideal geeignet ist, um mit den komplexen Projektstrukturen, die typischerweise hinter WPF-Projekten stecken, umzugehen. Dazu kommt, dass es nur wenige Entwickler gibt, für die die Notwendigkeit besteht, MSBuild- Projektdateien selbst zu schreiben, da Visual Studio 2005 mit den Erweiterungen für WPF diese Arbeit vollständig übernimmt. Unser Kapitel heißt jedoch Hinter den Kulissen und daher wollen wir wissen, wie die Projektdatei für das Hello World - Beispiel aufgebaut ist. An dieser Stelle gehen wir nicht auf alle Feinheiten von MSBuild ein, sondern erklären nur die Besonderheiten, die MSBuild für den Umgang mit XAML-Dateien bereithält. Beim Anlegen eines Projekts im Visual Studio wird eine Projektdatei mit der Endung.csproj erstellt. In dieser sind alle Informationen enthalten, die wir zum Kompilieren benötigen: <Project xmlns= " msbuild/2003" > <PropertyGroup> <AssemblyName>HelloWorld</AssemblyName> <OutputType>Exe</OutputType> </PropertyGroup> <ItemGroup> <Reference Include="System" /> <Reference Include="WindowsBase" /> <Reference Include="PresentationCore" /> <Reference Include= "PresentationFramework" /> </ItemGroup> 25

26 2 Hinter den Kulissen <ItemGroup> <Page Include="HelloWorld.xaml" /> <Compile Include="HelloWorld.cs" /> </ItemGroup> <Import Project= "$(MSBuildBinPath)\Microsoft.CSharp.targets"/> <Import Project= "$(MSBuildBinPath)\Microsoft.WinFX.targets"/> </Project> Die erste Besonderheit der Projektdatei sind die Verweise auf die Referenzen WindowsBase, PresentationCore und PresentationFramework. Ein paar Seiten zuvor wurde hervorgehoben, dass XAML kein Konzept ist, das untrennbar mit WPF verbunden ist, und jetzt sind schon im einfachsten Beispiel Verweise auf WPF enthalten? Der Grund ist, dass XAML als Konzept zwar eigenständig ist, zur Verwendung jedoch immer eine konkrete Implementierung vorausgesetzt wird. In unserem Fall greifen wir auf die von WPF zurück und daher verlangt MSBuild als Voraussetzung für die konkrete Kompilierung des Programms diese Referenzen. Der zweite Punkt, der hervorgehoben werden soll, sind die WPFspezifischen Build Items. Tabelle 1.1 zeigt eine komplette Übersicht. In unserem Fall wird nur das Item Page verwendet, um die XAML-Datei zu übersetzen. Schlussendlich ist es noch erforderlich, das MSBuild-Projekt "$(MSBuildBinPath)\Microsoft.WinFX.targets zu importieren. Es enthält die Definition der notwendigen Schritte zum Kompilieren von WPF-Anwendungen. 26

27 Kompilieren von XAML-Dateien Tabelle 2.1: WPF-spezifische Build Items Build Item Application- Definition Page Resource Content Beschreibung Dieses Build Item verweist auf die XAML-Datei, in der anwendungsweise Definitionen enthalten sind. In WPF ist das typischerweise die Datei App.xaml. Mit diesem Build Item werden alle XAML- Dateien angegeben, die kompiliert und dem Assembly hinzugefügt werden sollen. Mit Resource können Dateien dem Assembly hinzugefügt werden, auf die aus dem Programm über Pack URIs zugegriffen werden kann. Resource-Dateien lassen sich lokalisieren (UICulture-Eigenschaft). Dieses Build Item dient dazu, zusätzliche Dateien zu spezifizieren, die gemeinsam mit dem Assembly verteilt werden und auf die über Pack URIs zugegriffen werden kann. Die Dateien werden nicht dem Assembly hinzugefügt, lediglich die entsprechenden Metadaten. Die Build-Ergebnisse Beim Kompilieren einer Anwendung werden im obj-verzeichnis je XAML-Datei eine Reihe von Hilfsdateien generiert. Zwei davon sind von besonderem Interesse: die BAML- und die generierte C#-Datei. Beide tragen vor der Dateierweiterung den Namen der XAML-Datei, die BAML-Datei mit der Dateierweiterung.baml, die C#-Datei mit.g.cs. In unserem Fall finden wir also HelloWorld.baml und HelloWorld.g.cs. 27

28 2 Hinter den Kulissen Abbildung 2.2 stellt den Build-Prozess einer XAML-Datei vereinfacht grafisch darf. Auf die einzelnen Ergebnisse werden wir in Folge genauer eingehen. Abb. 2.2: Build-Prozess einer XAML-Datei BAML Binary XML Die Abkürzung BAML steht für Binary XAML bei dieser Datei handelt es sich also um die binäre Repräsentation der XAML- Datei. Der Grund, warum der Compiler nicht die XAML-Datei selbst verwendet, ist schlicht und einfach die Performance. Das Lesen der binären XAML-Datei kann zur Laufzeit um ein Vielfaches schneller erfolgen als das der Ausgangsdatei im XML-Format. Die BAML-Datei wird dem zu erstellenden Assembly als Ressource hinzugefügt. Dementsprechend findet man ihren Inhalt auch in der.g.resources-datei wieder. Der Mechanismus, BAML- Dateien als Ressourcen den Assemblies hinzuzufügen, ermöglicht auch die Verwendung unterschiedlicher XAML-Dateien abhängig von der zu verwendenden Sprache (Lokalisierung). Wir werden an dieser Stelle jedoch nicht näher auf den Prozess der Lokalisierung von WPF-Ressourcen eingehen. 28

29 Kompilieren von XAML-Dateien Abbildung 2.3 (Bildschirmkopie von ILDASM, dem Disassembler von.net) zeigt, wie die BAML-Datei als Ressource dem Assembly HelloWorld.exe hinzugefügt wurde. Abb. 2.3: BAML als Ressource im Assembly Der generierte C#-Code Beachten Sie, dass für jede XAML-Datei im Hintergrund eine Klasse generiert wird. Erinnern Sie sich noch an die XAML-Datei unseres Beispiels? Dort wurde mit x:code angegeben, dass die Klasse den Namen HelloWorldText haben soll: <y:textcontainer [...] x:class="samples.helloworldtext" [...]/> Wir finden HelloWorldText in der von MSBuild generierten.g.cs- Datei. Das Kürzel.g steht dabei für Generated. Werfen wir einen Blick in diese Datei: [...] namespace Samples [...] public partial class HelloWorldText : Samples.TextContainer, System.Windows.Markup.IComponentConnector 29

30 2 Hinter den Kulissen [...] public void InitializeComponent() [...] [...] An dieser Stelle soll nicht auf alle Feinheiten des generierten Codes eingegangen werden. Einige Besonderheiten sind jedoch für das Verständnis von XAML wesentlich: Die generierte Klasse ist mit dem Schlüsselwort partial versehen. Das bedeutet, dass sie in anderen Dateien noch erweitert werden kann. Diese Tatsache ist wichtig, da bei der konkreten Anwendung von XAML in WPF ähnlich wie bei ASP.NET das Konzept der Code-behind-Dateien verwendet wird. Der Anwender erweitert dabei die vom XAML-Compiler generierte Klasse in eigenen Dateien, indem er dort den gleichen Klassennamen wiederum mit dem Schlüsselwort partial versehen verwendet. Die erzeugte Klasse leitet von Samples.TextContainer ab. Wenn XAML in Verbindung mit WPF zum Einsatz kommt, führt beispielsweise die Verwendung des XAML-Elements Window dazu, dass eine Nachfahrenklasse der Klasse System.Windows.Window erzeugt wird. Die Implementierung des Interface System.Windows.Markup.IComponentConnector ist notwendig, damit Objekte der Klasse Event-Handler hinzugefügt werden können. Die Methode InitializeComponent schließlich wird verwendet, um den Objektgraphen aus dem BAML zu laden. XAML bietet grundsätzlich auch die Möglichkeit, Code einzubetten. Für diesen Zweck steht das Element x:code zur Verfügung. In diesem Element kann Programmcode innerhalb eines 30

31 Kompilieren von XAML-Dateien CDATA-Bereichs geschrieben werden, der vom XAML Compiler in die generierte partielle Klasse in der.g.cs-datei eingebunden wird. In unserem HelloWorld-Beispiel kann in der XAML-Datei zum Beispiel die zusätzliche Eigenschaft TextUpper definiert werden: <y:textcontainer xmlns:x= " x:class="samples.helloworldtext" xmlns:y="clr-namespace:samples" Text="Hello World!"> <x:code><![cdata[ public string UpperText get return Text.ToUpper(); ]]></x:code> </y:textcontainer> Von der Vorgehensweise, den Programmcode in XAML einzubetten, ist unbedingt abzuraten. Wie oben erwähnt, ist der einzige Sinn der partiellen Klasse, dass der aus XAML kommende Objektgraph über eigene Programmdateien um Logik erweitert werden kann. Dadurch soll eine Trennung zwischen Strukturen (d. h. Benutzeroberflächenelemente in WPF, Workflow-Definitionen in WF) und Logik geschaffen werden. Durch Vermischung von Struktur und Code in der XAML-Datei wird diese Trennung zunichte gemacht. Insofern sollte vom x:code-element nur Gebrauch gemacht werden, wenn keine andere Möglichkeit in Frage kommt! Eine Besonderheit stellt das x:name-attribut dar. Es wird später in diesem Buch noch im Detail erklärt. An dieser Stelle wollen wir 31

32 2 Hinter den Kulissen es jedoch vorab erwähnen, da es eine besondere Rolle in Bezug auf den generierten C#-Code einnimmt. Mit x:name können Elemente mit einem innerhalb der XAML-Datei eindeutigen Namen versehen werden. Hier ein Code-Beispiel einer WPF-Maske mit drei Eingabefeldern und einer Schaltfläche. Abb. 2.4: WPF-Maske Die in den ersten beiden Eingabefeldern eingegebenen Zahlen sollen bei Klick auf die Schaltfläche miteinander multipliziert werden. Das Ergebnis wird im dritten Eingabefeld dargestellt. Die Eingabefelder wurden mit x:name benannt: <Window x:class="elementnaming.elementnamingform" xmlns=" presentation" xmlns:x=" Title="ElementNaming" Height="125" Width="225" > <StackPanel Orientation="Vertical" Margin="10,10,10,10"> <StackPanel Orientation="Horizontal" Margin="10,10,10,10"> <TextBox x:name="variable_x" Width="50"/> <TextBlock>*</TextBlock> <TextBox x:name="variable_y" Width="50"/> 32

33 Kompilieren von XAML-Dateien <TextBlock>=</TextBlock> <TextBox x:name="result" IsEnabled="False" Width="50"/> </StackPanel> <Button x:name="calculate" Click="OnCalculate_Click"> Calculate</Button> </StackPanel> </Window> Der XAML-Compiler generiert pro Element, das mit x:name benannt wurde, ein Attribut in die erzeugte, partielle Klasse. Außerdem wird die Methode Connect von IComponentConnector implementiert. Sie wird im Zuge des Ladeprozesses pro benanntem Element aufgerufen und ist dafür zuständig, dass die Attribute mit den entsprechenden, durch das Laden der XAML-Datei im Speicher erzeugten Objekten verdrahtet werden. Ihre zweite Aufgabe ist die Zuweisung der entsprechenden Methoden zu den Event-Handlern, die in der XAML-Datei definiert wurden. In unserem Fall soll die Methode OnCalculate_Click aufgerufen werden, wenn ein Benutzer auf die Schaltfläche Calculate klickt. Der folgende Codeausschnitt zeigt den vom XAML-Compiler generierten Code aus der.g.cs-datei. Die oben beschriebenen Besonderheiten sind hervorgehoben: [...] public partial class ElementNamingForm : System.Windows.Window, System.Windows.Markup.IComponentConnector internal System.Windows.Controls.TextBox Variable_X; 33

34 2 Hinter den Kulissen internal System.Windows.Controls.TextBox Variable_Y; internal System.Windows.Controls.TextBox Result; internal System.Windows.Controls.Button Calculate; [...] void IComponentConnector.Connect( int connectionid, object target) switch (connectionid) case 1: this.variable_x = ((System.Windows.Controls.TextBox) (target)); return; case 2: this.variable_y = ((System.Windows.Controls.TextBox) (target)); return; case 3: this.result = ((System.Windows.Controls.TextBox) (target)); return; case 4: this.calculate = ((System.Windows.Controls.Button) (target)); this.calculate.click += new System.Windows.RoutedEventHandler( this.oncalculate_click); 34

35 Kompilieren von XAML-Dateien [...] return; this._contentloaded = true; In der Code-behind-Datei kann durch diesen generierten Code bequem auf die einzelnen benannten Steuerelemente zugegriffen werden: [...] public partial class ElementNamingForm : System.Windows.Window public ElementNamingForm() InitializeComponent(); private void OnCalculate_Click( Object sender, EventArgs e) Result.Text = ( Convert.ToInt32(Variable_X.Text) * Convert.ToInt32(Variable_Y.Text) ).ToString(); 35

36 2 Hinter den Kulissen XAML zur Laufzeit behandeln Die Alternative zum Einbinden der XAML-Datei zur Kompilierzeit wäre das Laden zur Laufzeit. Dieses Vorgehen sollte jedoch nur gewählt werden, wenn es triftige Gründe dafür gibt, da die Zeit zum Laden der XAML-Datei wegen der fehlenden binären Version deutlich länger ist. Nichtsdestotrotz gibt es Situationen, in denen das XAML zur Kompilierzeit nicht vorliegt. Für diese Fälle gibt es die Klasse System.Windows.Markup.XamlReader. Unser zuvor gezeigtes HelloWorld-Beispiel lässt sich mit ganz wenigen Änderungen so umstellen, dass die XAML-Datei erst zur Laufzeit geladen wird: <y:textcontainer xmlns:x= " xmlns:y="clrnamespace:samples;assembly=helloworldruntime" Text="Hello World!" /> Die erste Änderung betrifft die XAML-Datei selbst. Das x:class-attribut entfällt, da keine Klasse mehr erzeugt werden soll. Generell dürfen alle XAML-Strukturen, die eine Kompilierung voraussetzen, beim Laden zur Laufzeit nicht in der XAML-Datei vorkommen (d.h. auch zum Beispiel eingebetteter Programmcode), da kein Compiler mehr involviert ist. Als Zweites ist darauf zu achten, dass beim Verweis auf den Namespace das Assembly mit angegeben werden muss. Im Programmcode ist die Main-Methode so umzustellen, dass mithilfe der erwähnten XamlReader-Klasse die XAML-Datei gelesen wird: 36

37 Kompilieren von XAML-Dateien public static void Main() FileStream fs = new \HelloWorldRuntime.xaml", FileMode.Open ); TextContainer text = (TextContainer)XamlReader.Load( fs ); System.Console.WriteLine( text.text ); fs.close(); Die MSBuild-Projektdatei wird beim Laden von XAML zur Laufzeit natürlich einfacher, weil weniger Referenzen notwendig sind: <Project xmlns= " > <PropertyGroup> <AssemblyName>HelloWorldRuntime </AssemblyName> <OutputType>Exe</OutputType> </PropertyGroup> <ItemGroup> <Reference Include="System" /> <Reference Include="System.Xml" /> <Reference Include= "PresentationFramework" /> </ItemGroup> <ItemGroup> <Compile Include="HelloWorldRuntime.cs" /> </ItemGroup> <Import Project= "$(MSBuildBinPath)\Microsoft.CSharp.targets"/> </Project> 37

38 2 Hinter den Kulissen Etwas komplizierter ist das Laden von XAML-Dateien zur Laufzeit, bei denen man auf einzelne, mit x:name benannte Elemente zugreifen will. Im Kapitel Der generierte C#-Code wurde bereits erklärt, welche Auswirkungen x:name auf den generierten C#-Code hat. Der XAML-Compiler macht in diesem Fall die ganze Arbeit, indem er pro benanntem Element ein Attribut in die partielle Klasse einfügt. Im eigenen Code kann man damit bequem auf die mit x:name versehenen Objekte zugreifen. Lädt man die XAML-Dateien jedoch zur Laufzeit, gibt es keinen generierten C#-Code. Man muss die Arbeit, die in der kompilierten Version der XAML-Compiler übernimmt, selbst erledigen. Ein typisches Szenario, wo diese Vorgangsweise sinnvoll wäre, ist eine Anwendung, in der die Gestaltung der WPF-Masken zur Kompilierzeit noch nicht fixiert ist. Es wäre denkbar, dass Anwender das Front-End an ihre Bedürfnisse anpassen können, indem die XAML-Dateien verändert werden. Das Programm müsste somit die WPF-Masken zur Laufzeit laden und die Eingabeelemente mit den programminternen Variablen verbinden. Wir möchten dieses Prinzip demonstrieren, indem wir das letzte Beispiel des Kapitels Der generierte C#-Code so umbauen, dass die WPF-Maske nicht mehr kompiliert, sondern zur Laufzeit geladen wird. Die XAML-Datei unterscheidet sich zwischen der kompilierten Version und der Version zum Laden zur Laufzeit nur wenig: Wie schon im HelloWorld-Beispiel muss das x:class-attribut entfernt werden, da kein Compiler mehr im Spiel ist, der eine Klasse generieren könnte. Die zweite Änderung betrifft die Definition des Buttons. Dort war in der kompilierten Version ein Event-Handler dem Event Click zugeordnet. Das hatte zur Folge, dass der Compiler Code erzeugte, um den Event-Handler dem entsprechenden Objekt zuzuweisen. Beim Laden zur Laufzeit wird kein Code 38

39 Kompilieren von XAML-Dateien erzeugt, insofern müssen solche Zuweisungen eines Event- Handler aus dem XAML-Code entfernt werden. <Window xmlns=" presentation" xmlns:x=" Title="ElementNaming" Height="125" Width="225" > <StackPanel Orientation="Vertical" Margin="10,10,10,10"> <StackPanel Orientation="Horizontal" Margin="10,10,10,10"> <TextBox x:name="variable_x" Width="50"/> <TextBlock>*</TextBlock> <TextBox x:name="variable_y" Width="50"/> <TextBlock>=</TextBlock> <TextBox x:name="result" IsEnabled="False" Width="50"/> </StackPanel> <Button x:name="calculate"> Calculate</Button> </StackPanel> </Window> Das Laden der XAML-Datei ElementNamingForm.xaml zur Laufzeit erfolgt wie im HelloWorld-Beispiel mithilfe der Klasse System.Windows.Markup.XamlReader. Was hinzukommt, ist jedoch der Code zum Verdrahten der Attribute mit den entsprechenden durch das Laden der XAML-Datei erzeugten Objekten. Dafür steht die Klasse System.Windows.LogicalTreeHelper zur Verfügung. Sie enthält die Methode FindLogicalNode, die einen Baum 39

40 2 Hinter den Kulissen von FrameworkElement- oder FrameworkContentElement-Objekten nach einem Objekt mit einem angegebenen Namen durchsucht. using System; using System.IO; using System.Windows; using System.Windows.Controls; using System.Windows.Markup; namespace ElementNaming class ElementNaming : Application [STAThread] private static void Main() ElementNaming app = new ElementNaming(); app.mainform.show(); app.run(); private Window mainform; private TextBox Variable_X; private TextBox Variable_Y; private TextBox Result; private Button Calculate; public ElementNaming() FileStream fs = new FileMode.Open); mainform = (Window)XamlReader.Load(fs); fs.close(); DoWiring(mainForm); 40

41 Kompilieren von XAML-Dateien private void DoWiring( DependencyObject formcontent ) Variable_X = (TextBox) LogicalTreeHelper.FindLogicalNode( formcontent, "Variable_X"); Variable_Y = (TextBox) LogicalTreeHelper.FindLogicalNode( formcontent, "Variable_Y"); Result = (TextBox) LogicalTreeHelper.FindLogicalNode( formcontent, "Result"); Calculate = (Button) LogicalTreeHelper.FindLogicalNode( formcontent, "Calculate"); Calculate.Click += new RoutedEventHandler(OnCalculate_Click); private void OnCalculate_Click( Object sender, EventArgs e) Result.Text = ( Convert.ToInt32(Variable_X.Text) * Convert.ToInt32(Variable_Y.Text) ).ToString(); 41

42 2 Hinter den Kulissen 2.6 Application Definition Files Unsere bisherigen Beispiele enthielten alle die für Konsolenanwendungen typische Main-Methode. Die WPF-Implementierung von XAML bietet als Ersatz dafür Application Definition Files an. Im Wesentlichen sind diese Dateien ganz normale XAML-Dateien. Das Besondere an ihnen ist, dass als Wurzelelement Application verwendet wird. Diesem XAML-Element entspricht die Klasse System.Windows.Application im.net Framework. Den Application Definition Files bzw. der Klasse Application kommen folgende Aufgaben zu: Implementierung des Einsprungpunkts für den Programmstart (Main-Methode) Management der Anwendungsausführung (z.b. Starten, Beenden) Management applikationsweit verwendeter, globaler Objekte (z.b. Stile, Ressourcen) Verarbeiten von Kommandozeilenparametern Anbieten von Funktionen und Events für die Navigation zwischen den Fenstern und Seiten einer WPF-Applikation Application implementiert das Singleton-Pattern. Es ist also sichergestellt, dass pro AppDomain genau eine Instanz dieser Klasse existiert. Das hat den Vorteil, dass auf die von ihr zur Verfügung gestellten Eigenschaften und Methoden von überall innerhalb einer Applikation zugegriffen werden kann. Dafür steht die statische Eigenschaft Current zur Verfügung, die das Application-Objekt der aktuellen AppDomain zurückgibt. Der folgende XAML-Ausschnitt zeigt, wie das schon bekannte Hello-World-Beispiel mit einem Application Definition File umgesetzt werden könnte: 42

43 Application Definition Files <Application xmlns=" 2006/xaml/presentation" xmlns:x=" x:class="samples.sampleapp" xmlns:y="clr-namespace:samples"> <Application.Resources> <y:textcontainer x:key="outputtext" Text="Hello World!" /> </Application.Resources> </Application> In diesem Codebeispiel wird das Application Definition File zum Ablegen einer globalen Ressource, also eines globalen Objekts der bereits bekannten Klasse TextContainer, verwendet (Details zum Verwenden der Resources-Collection finden sich später in Kapitel 4). Für die C#-Code-behind-Klasse bleibt nur die Aufgabe, den Text auszugeben. Sie kann dabei mithilfe der Methode FindResource auf die Ressource aus dem Application Definition File zugreifen: using System.Windows; namespace Samples public class TextContainer private string text; public string Text set text = value; get return text; 43

44 2 Hinter den Kulissen public override string ToString() return Text; public partial class SampleApp : Application override protected void OnStartup( StartupEventArgs e) System.Console.WriteLine( FindResource("OutputText")); Shutdown(); ; Da unser Beispiel eine Konsolenanwendung ist, wird nach dem Ausgeben des Textes Hello World! die Anwendung sofort wieder geschlossen. Bei der Umsetzung von WPF-Applikationen ist das natürlich anders. Dort ist es zumindest bei einfacheren Programmen oft der Fall, dass die Code-behind-Datei der Application-Klasse leer ist. Es ist nicht einmal notwendig, Code zu schreiben, der das Hauptfenster einer Anwendung anzeigt. Dafür bietet Application die Eigenschaft StartupUri an, die bereits in der XAML-Datei entsprechend gesetzt werden kann. Beim Programmmstart kümmert sich das Applikationsobjekt automatisch darum, die Maske, auf die StartupUri verweist, anzuzeigen. Generiert man eine WPF-Anwendung mit Visual Studio, wird genau dieser Weg gewählt: 44

45 Zusammenfassung <Application x:class="windowsapplication.app" xmlns=" presentation" xmlns:x=" StartupUri="Window1.xaml"> <Application.Resources> </Application.Resources> </Application> Weder WPF- noch Konsolenanwendungen verlangen zwingend die Nutzung von Application Definition Files oder der Klasse Application im Code. In der Praxis raten wir jedoch unbedingt, sie zu verwenden. In Application Definition Files sollten insbesondere zentral definierte Layoutvorschriften in Form von Stilen abgelegt werden, die im Rest der Anwendung durchgängig verwendet werden. Nur dadurch kann man in Programmen, die eine gewisse Größe haben, ein einheitliches Aussehen sicherstellen und den Wartungsaufwand bei Layoutänderungen in Grenzen halten. 2.7 Zusammenfassung Obwohl XAML im Zuge der Entwicklung von WPF entstanden ist, handelt es sich um eine allgemein verwendbare Sprache zum Spezifizieren von Objektgraphen. XAML-Dateien werden mit MSBuild in ihre binäre Repräsentation BAML übersetzt und als Ressourcen dem Assembly hinzugefügt. Pro XAML-Datei wird eine partielle Klasse generiert. Sie enthält unter anderem den Code zum Erzeugen des Objektgraphen aus BAML. XAML kann auch zur Laufzeit interpretiert werden. Davon ist jedoch aus Laufzeitgründen abzuraten! Dieser Weg sollte nur 45

46 2 Hinter den Kulissen beschritten werden, wenn es gute Gründe dafür gibt, dass das XAML nicht zur Kompilierzeit in das Assembly eingebunden werden kann. In Application Definition Files sollten zentrale Ressourcen wie Stile abgelegt werden. Auf sie kann von überall in der Anwendung zugegriffen werden. 46

47 XAML Namespaces KAPITEL Einleitung Namespaces in XAML-Dateien Elemente im Namespace x: XML-Attribute in XAML Zusammenfassung Einleitung Was ist der Kern von XAML? Rein technisch gesehen handelt es sich um ein Werkzeug zur Serialisierung und Deserialisierung von Objektstrukturen. Vom Standpunkt der Anwendungsbereiche gesehen dient die Sprache zum Definieren von Benutzerschnittstellen oder Workflows. Da es dabei im Endeffekt aber ebenfalls nur um das Anlegen von Objekten im Speicher geht, widerspricht sich das nicht. Die Sprache XAML hat keine spezifische Klassenbibliothek eingebaut. Sie kann ihre Aufgabe mit jeder beliebigen.net-klasse erfüllen und beherrscht nicht nur den Umgang mit gewissen Klassen. Aus diesem Grund ist ein Mechanismus notwendig, der XAML mitteilt, wo die Klassen zu finden sind, auf die in einer XAML-Datei verwiesen wird. Konsequenterweise hat Microsoft dafür nicht ein neues Konzept erfunden, sondern auf Altbekanntes und Bewährtes aus XML zurückgegriffen: Namespaces und Namespace Mappings. Namespace Mappings stehen nicht nur sprichwörtlich am Anfang von XAML, sie sind auch ganz am Beginn der XAML-Datei, 47

48 3 XAML Namespaces also im Wurzelelement, anzugeben. Zwei Typen von Namespace Mappings sind zu unterscheiden: CLR (Common Language Runtime) Namespace Mappings XML Namespace Mappings CLR und XML Namespace Mappings stellen die erwähnte Verbindung zwischen XAML und den.net-klassen dar. Ein CLR Mapping ist ein Verweis auf einen CLR Namespace, der alle Klassen dieses Namespace in der XAML-Datei verfügbar macht. XML Namespaces sind eine Zusammenfassung mehrerer CLR Namespaces. Der erste Teil dieses Kapitels widmet sich der Erklärung dieser beiden Strukturen. Im zweiten Teil des Kapitels gehen wir auf den XAML Standard Namespace ein. Für ihn wird typischerweise die Abkürzung x: verwendet. Er beinhaltet alle Klassen und Compiler-Anweisungen, die XAML ausmachen. Bevor wir darauf eingehen, wie wir CLR und XML Namespaces in XAML-Dateien verwenden können, sehen wir uns zuerst an, wie diese in.net überhaupt zu definieren sind. CLR Namespace CLR (Common Language Runtime) Namespaces sind Ihnen wahrscheinlich bekannt. Sie werden in.net verwendet, um mehrere Klassen zu größeren Einheiten zusammenzufassen. CLR Namespaces werden im C#-Quellcode mit dem Schlüsselwort namespace definiert und mithilfe von using verwendet: using System; using System.Text; namespace Samples class MyClass1 48