Nächsten Freitag, also am 14. Mai 2010, um 18:00 Uhr ist es wieder so weit. Das monatliche Wiener .NET Coding Dojo findet wieder statt. Bevor wir mit dem Kata beginnen, wird uns Jörg zeigen, wie man moderne Web-Anwendungen mit ASP.NET MVC baut. Nach einer Pause werden wir uns diesmal dem KataBowling widmen.

Nähere Informationen findet ihr hier: http://dotnetopenspace.ning.com/events/aspnet-mvc-anwendung-1.

Ich freue mich auf euer Kommen.

Beim letzten Mal hatten wir die Statuszeile noch so definiert:

        ...
        <StatusBar DockPanel.Dock="Bottom">
            <TextBlock Text="Col 1, Ln 1" />
        </StatusBar>
        ...

Das sieht so aus:

Ein TextBlock-Element befindet sich in der Statuszeile, das links angezeigt wird. Doch wie bekommen wir den Text an die gewünschte Position?

Die StatusBar stellt ihre Steuerelemente normalerweise mit einem DockPanel dar. Allerdings werden alle Steuerelemente, die nicht vom Typ StatusBarItem sind, in einem StatusBarItem-Element eingehüllt, d.h. wir müssen selbst das StatusBarItem-Element angeben, damit wir die DockPanel-Eigenschaften definieren können.

        ...
        <StatusBar DockPanel.Dock="Bottom">
            <StatusBarItem DockPanel.Dock="Right">
                <TextBlock Text="Col 1, Ln 1" />
            </StatusBarItem>
            <StatusBarItem/>
        </StatusBar>
        ...

Der Text wird jetzt zwar rechts dargestellt, aber noch nicht genau dort, wo wir ihn haben wollen. Außerdem mussten wir ein leeres StatusBarItem-Element hinzufügen, das den Hauptteil der Statuszeile ausfüllen soll. Andernfalls würde das StatusBarItem-Element mit dem TextBlock nicht rechts dargestellt. Würden wir einen zweiten Text darstellen wollen, müssten wir es zum leeren StatusBarItem hinzufügen. Somit käme der linke Teil im XAML-Code vor dem rechten. Viel lieber hätten wir an dieser Stelle ein Grid, weil wir dann die Breite der Spalten selbst bestimmen können. Aber wie erreichen wir das?

Die StatusBar gehört wie ListBox, ListView, ComboBox, Menu und einigen anderen zu den sogenannten Items-Controls. Diese stellen ihre Subelemente in einem Panel dar, das durch die Eigenschaft ItemsPanel definiert wird. Normalerweise wird darin ein StackPanel definiert, aber StatusBar hat diese Eigenschaft überschrieben und durch ein DockPanel ersetzt, wie wir oben gesehen haben. Wir können dieser Eigenschaft ein Grid zuweisen und so zu dem gewünschten Ergebnis kommen. In XAML sieht das so aus:

        <StatusBar DockPanel.Dock="Bottom">
            <StatusBar.ItemsPanel>
                <ItemsPanelTemplate>
                    <Grid>
                        <Grid.RowDefinitions>
                            <RowDefinition Height="*"/>
                        </Grid.RowDefinitions>
                        <Grid.ColumnDefinitions>
                            <ColumnDefinition Width="2*"/>
                            <ColumnDefinition Width="1*"/>
                        </Grid.ColumnDefinitions>
                    </Grid>
                </ItemsPanelTemplate>
            </StatusBar.ItemsPanel>
            <StatusBarItem Grid.Column="1" Grid.Row="0">
                <TextBlock Text="Col 1, Ln 1" />
            </StatusBarItem>
        </StatusBar>

Die Eigenschaft bekommt ein ItemsPanelTemplate, in dem wir mit einem Grid ein Layoutgitter definieren, das aus einer Zeile und zwei Spalten besteht. Die Spalten teilen sich den verfügbaren Platz im Verhältnis 2:1 auf. Die rechte Spalte umfasst also das rechte Drittel der Statuszeile. Den TextBlock geben wir in das StatusBarItem, das wir der rechten Spalte zuweisen. Damit befindet sich der Text immer im rechten Drittel der Statuszeile.

Die WPF-Statuszeile kann auch andere Steuerelemente darstellen, z.B. Bilder, Fortschrittsbalken und viele andere mehr. Wenn man dann mehr Kontrolle über das Layout der Statuszeile braucht, kann das DockPanel jederzeit durch etwas anderes ersetzt werden.

Ziel

In diesem Artikel möchte ich zeigen, wie man mit dem WPF-Layoutmechanismus eine GUI für einen Notepad-ähnlichen Texteditor entwerfen kann. Das Ergebnis wird in etwa so aussehen:

Oft gibt es mehr als eine Möglichkeit, ein Ziel zu erreichen. So auch hier: in der ersten Variante verwende ich ein Grid und in der zweiten Variante ein DockPanel.

Variante mit Grid

Visual Studio erstellt ein Window immer mit einem Grid:

<Window x:Class="TextEditor.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <Grid>
 
    </Grid>
</Window>

Zuerst müssen wir die Spalten und Zeilen definieren, die das Layoutgitter haben soll, dann können wir die Steuerelemente hinzufügen und einzelnen Gitterzellen zuweisen.

<Window x:Class="TextEditor.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition/>
            <RowDefinition/>
            <RowDefinition/>
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition/>
        </Grid.ColumnDefinitions>
 
        <Menu Grid.Column="0" Grid.Row="0" />
        <TextBox Grid.Column="0" Grid.Row="1" />
        <StatusBar Grid.Column="0" Grid.Row="2" />
    </Grid>
</Window>

Wir definieren drei Zeilen und eine Spalte. Jedes Steuerelement kommt in eine eigene Zeile. Das Ergebnis sieht dann so aus:

Wie wir sehen, sieht das Ergebnis noch gar nicht nach Texteditor aus. Drei gleich große Layoutgitterzeilen beinhalten das Menü, die TextBox und die Statuszeile.

Per Voreinstellung bekommt jede Zeile die Höhe “1*” zugewiesen, d.h. die Höhe wird im Verhältnis 1:1:1 aufgeteilt. Daher sind die drei Zeilen gleich hoch.

Wenn wir die Zeilendefinitionen so abändern, dass die erste Zeile (Menü) und die dritte Zeile (Statuszeile) eine fixe Höhe bekommen und die zweite Zeile (TextBox) den Rest bekommt, dann kommen wir dem Ziel etwas näher.

...
        <Grid.RowDefinitions>
            <RowDefinition Height="23"/>
            <RowDefinition Height="1*"/>
            <RowDefinition Height="26"/>
        </Grid.RowDefinitions>
...

Die erste Zeile setzen wir auf 23 Pixel und die letzte Zeile auf 26 Pixel. Die zweite Zeile bekommt den Rest. Die Höhenangabe für die zweite Zeile kann weggelassen werden, weil “1*” der voreingestellte Wert ist.

Dem Menü fehlen noch die Hauptmenüpunkte und die Textbox akzeptiert noch nicht die Eingabetaste. Mit folgenden Änderungen sieht unser Fenster beinahe wie ein richtiger Texteditor aus:

<Window x:Class="TextEditor.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="23"/>
            <RowDefinition Height="1*"/>
            <RowDefinition Height="26"/>
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition/>
        </Grid.ColumnDefinitions>
 
        <Menu Grid.Column="0" Grid.Row="0">
            <MenuItem Header="_Datei" />
            <MenuItem Header="_Bearbeiten" />
            <MenuItem Header="_Format"/>
            <MenuItem Header="_Ansicht"/>
            <MenuItem Header="_Hilfe"/>
        </Menu>
        <TextBox Grid.Column="0" Grid.Row="1" AcceptsReturn="True" />
        <StatusBar Grid.Column="0" Grid.Row="2" />
    </Grid>
</Window>

Die WPF-TextBox zeigt mehrzeilige Texte immer mehrzeilig an, aber per Voreinstellung akzeptiert sie die Eingabetaste nicht. Mit der Eigenschaft AcceptsReturn kann dieses Verhalten geändert werden.

Wenn der Benutzer jetzt einen längeren Text in die TextBox eingibt oder einfügt, sollten Schiebeleisten erscheinen. Unser Fenster verhält sich leider noch nicht so. Wenn wir die TextBox in ein ScrollViewer-Element einbetten, erhalten wir das gewünschte Verhalten:

<Window x:Class="TextEditor.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <Grid>
        <Grid.RowDefinitions>
            <RowDefinition Height="23"/>
            <RowDefinition Height="1*"/>
            <RowDefinition Height="26"/>
        </Grid.RowDefinitions>
        <Grid.ColumnDefinitions>
            <ColumnDefinition/>
        </Grid.ColumnDefinitions>
 
        <Menu Grid.Column="0" Grid.Row="0">
            <MenuItem Header="_Datei" />
            <MenuItem Header="_Bearbeiten" />
            <MenuItem Header="_Format"/>
            <MenuItem Header="_Ansicht"/>
            <MenuItem Header="_Hilfe"/>
        </Menu>
        <ScrollViewer Grid.Column="0" Grid.Row="1"
                      HorizontalScrollBarVisibility="Auto"
                      VerticalScrollBarVisibility="Auto">
            <TextBox AcceptsReturn="True" />
        </ScrollViewer>
        <StatusBar Grid.Column="0" Grid.Row="2" />
    </Grid>
</Window>

Da jetzt ScrollViewer das Kindelement des Grids ist, muss die Zuweisung zu einer Layoutgitterzelle für das ScrollViewer-Element erfolgen. Die TextBox braucht dann keine Zuweisung mehr.

Mit den Eigenschaften HorizontalScrollBarVisibility und VerticalScrollBarVisibility können wir steuern, wann die Schiebeleisten erscheinen.

Variante mit DockPanel

Das Ziel kann auch mit einem DockPanel erreicht werden. Tauschen wir mal das Grid durch ein DockPanel aus und entfernen die Zeilen- und Spaltendefinitionen und die Zuordnung zu den Layoutgitterzellen:

<Window x:Class="TextEditor.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <DockPanel>
        <Menu DockPanel.Dock="Top">
            <MenuItem Header="_Datei" />
            <MenuItem Header="_Bearbeiten" />
            <MenuItem Header="_Format"/>
            <MenuItem Header="_Ansicht"/>
            <MenuItem Header="_Hilfe"/>
        </Menu>
        <ScrollViewer HorizontalScrollBarVisibility="Auto"
                      VerticalScrollBarVisibility="Auto">
            <TextBox AcceptsReturn="True" />
        </ScrollViewer>
        <StatusBar DockPanel.Dock="Bottom" />
    </DockPanel>
</Window>

Das Ergebnis sieht noch nicht so aus, wie wir wollen.

Das Problem ist, dass bei einem DockPanel jenes Steuerelement, das den Rest der Fläche ausfüllen soll, als letztes angegeben werden muss. Das ist bei uns der ScrollViewer mit der TextBox. Außerdem gibt das DockPanel jedem Element gerade soviel Platz, wie es braucht, um den Inhalt darzustellen. Daher sollten wir etwas in der Statuszeile anzeigen, damit das DockPanel die Statuszeile überhaupt darstellt:

<Window x:Class="TextEditor.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525">
    <DockPanel>
        <Menu DockPanel.Dock="Top">
            <MenuItem Header="_Datei" />
            <MenuItem Header="_Bearbeiten" />
            <MenuItem Header="_Format"/>
            <MenuItem Header="_Ansicht"/>
            <MenuItem Header="_Hilfe"/>
        </Menu>
        <StatusBar DockPanel.Dock="Bottom">
            <TextBlock Text="Col 1, Ln 1" />
        </StatusBar>
        <ScrollViewer HorizontalScrollBarVisibility="Auto"
                      VerticalScrollBarVisibility="Auto">
            <TextBox AcceptsReturn="True" />
        </ScrollViewer>
    </DockPanel>
</Window>

Das sieht doch gleich besser aus.

Zusammenfassung

Wir kamen sowohl mit dem Grid als auch mit dem DockPanel an unser Ziel. Beide Varianten haben Vor- und Nachteile.

Beim Grid mussten wir die Definitionen für die Zeilen und Spalten und an den Steuerelementen sowohl die Spalte als auch die Zeile angeben, obwohl unser Layout nur eine Spalte hatte.

Das DockPanel hatte den Nachteil, dass die Reihenfolge geändert und daher die Statuszeile im XAML-Code vor der TextBox angegeben werden musste. Außerdem mussten alle Steuerelemente einen Inhalt haben, damit sie überhaupt angezeigt wurden.

Mehr Informationen über die verschiedenen Panel-Elemente gibt es im Artikel Panel Overview.

Nicht nur die richtige Auswahl des Panel-Elements beeinflusst das Layout, einige Steuerelement-Eigenschaften haben ebenfalls Auswirkungen auf die Anordnung der Steuerelemente. Die wichtigsten Eigenschaften mit Einfluss auf das Layout sind:

Detailliertere Informationen über den Bedeutung dieser Eigenschaften gibt es in der MSDN-Library.

Nicht jede Eigenschaft ist in jedem Panel sinnvoll. Folgende Tabelle zeigt die Wirkung bestimmter Kombinationen von Eigenschaften und Panel-Elementen:

Welche Vorteile hat der WPF-Layoutmechanismus, der im Vergleich zu Windows Forms viel komplexer ist?

1. Der Entwickler kann besser kontrollieren, wie sich die Anordnung der Steuerelemente verhalten soll, wenn der Benutzer die Größe des Fensters ändert. Das konnte aber bereits in Windows Forms mit dem Anchoring oder dem Docking erreicht werden.
2. Die Steuerelemente können ihre Größe und Position automatisch anpassen, wenn bei einer lokalisierten Anwendung die Texte der Übersetzungen länger sind. Darüber gibt es wieder einen Artikel in der MSDN-Library.

Es gibt weitere Panel-Elemente, die ich in diesem Artikel nicht berücksichtigt habe. Diese sind zum größten Teil nur für die Entwicklung eigener Steuerelemente relevant. Außerdem können eigene Panel-Elemente entwickelt werden, wenn die Vorgefertigten nicht ausreichen.

Anmeldung und Information auf Ning.

Anmeldung und Information auf Ning.

Das Thema wird wieder “Test-Driven Development” (TDD) sein.

Anmeldung und Information auf Ning.

Die Themen des ersten .NET-Coding-Dojos Wien sind “Test-Driven Development” (TDD) und “Behavior-Driven Development” (BDD).

Im ersten Artikel mit dem Titel “Using Agile Techniques to Pay Back Technical Debt” beschreibt er, was technische Schulden sind und wie ein Team damit umgehen soll. Außerdem gibt David Laribee ein paar Tipps, wie man Manager und Product Owner davon überzeugt, dass etwas gegen technische Schulden unternommen werden soll.

Der zweite Artikel, “9 Useful Tactics for Paying Back Technical Debt“, beschreibt Vorgehensweisen im Umgang mit technischen Schulden.

Wer ihn dabei unterstützen will, macht Folgendes:

1. Auf die Seite mit den vorgeschlagenen MIX2010-Beiträgen gehen: http://visitmix.com/opencallvote/
2. Nach “Mario Meir-Huber” suchen
3. Auf der Seite mit Marios Vorschlag auf “Add This Entry to Ballot” klicken
4. Dann auf “Submit Your Ballot” im rechten Feld klicken.

Vielen Dank für die Unterstützung. Es würde mich sehr freuen, wenn Mario seinen Vortrag präsentieren kann.

Anmeldung und weitere Informationen im Wiki.

Natürlich kann und soll man auch teilnehmen, wenn man nicht beim .NET Open Space war und man das Thema interessant findet.

Geplant ist außerdem, die Planung und Organisation der weiteren Treffen zu besprechen.