Kapitel 4 - Ereignisbehandlung

4.1 Grundlagen

• Direkt in XAML über x:Code-Abschnitte.
• In XAML wird ein Ereignis einer Komponente mit einer Routine in der Code-Behind-Datei verknüpft.
• Die Ereignisbehandlung erfolgt nur im Code.
• Innerhalb von Stilen werden so genannte EventSetter und EventTrigger verwendet (diese werden im Kapitel zu Styles beschrieben).

nach oben

4.2 Code in der XAML-Datei

Ein Code-Abschnitt innerhalb von XAML muss in ein x:Code-Element eingebettet werden. Da der Code beliebig sein kann, also auch Operatoren wie < und > enthalten kann und er sich in einer XML-Datei befindet (XAML ist ja letzten Endes XML) sollte dieser Code-Abschnitt in einen CDATA-Abschnitt eingeschlossen werden. Dadurch wird der Inhalt durch einen XML-Parser (also auch bei der Interpretation der XAML-Datei) nicht als XML-Daten ausgewertet. Ansonsten ist die Verwendung des CDATA-Abschnitts optional.

Eine Beschränkung dieser Lösung ist beispielsweise, dass nur Code für die partielle Klasse eingefügt werden kann, welche zur XAML-Datei gehört. Separate Klassen können z.B. nicht in einem solchen Abschnitt deklariert werden (ausgenommen innere Klassen).

Abbildung 4.1: Ereignisse in XAML verpackt

<StackPanel Margin="10" HorizontalAlignment="Left">
  <Button Click="ClickMich" Width="100">Klick mich</Button>
  <x:Code>
    <![CDATA[
    void ClickMich(object sender, RoutedEventArgs args)
    {
      TbInfo.Text = "Der Button wurde geklickt";
    }
    ]]>
  </x:Code>
  <TextBox Name="TbInfo" Width="140">Hallo</TextBox>
</StackPanel>

HINWEIS: Die Verwendung von Code innerhalb der XAML-Datei ist zwar eine mögliche Lösung für eine Ereignisbehandlung, allerdings sollte davon eher weniger Gebrauch gemacht werden. Ziel sollte es stattdessen sein, eine saubere Trennung zwischen dem Design der Oberfläche und der dahinter liegenden Programmlogik zu schaffen.

nach oben

4.3 Getrennte Ereignisbehandlung

Der Code wird jetzt aber in der Code-Behind-Datei hinterlegt. Dazu muss die Methode entsprechend der Signatur des Ereignisses erstellt und in der partiellen Klasse der Code-Behind-Datei, welche der XAML-Datei zugeordnet ist, implementiert werden.

<StackPanel Margin="10" HorizontalAlignment="Left">
  <Button Click="ClickMich" Width="100">Klick mich</Button>
  <TextBox Name="TbInfo" Width="140">Hallo</TextBox>
</StackPanel>

Die Methode ClickMich() wird in der Fensterklasse Window1 deklariert. Der Name der TextBox steht ebenfalls im Code zur Verfügung, auch wenn er in der XAML-Datei über das Attribut Name vergeben wurde.

namespace EreignisCodeInCodeBehindProj
{
  public partial class Window1: System.Windows.Window
  {
    public Window1()
    {
      InitializeComponent();
    }
    private void ClickMich(object sender, RoutedEventArgs e)
    {
      TbInfo.Text = "Der Button wurde geklickt";
    }
  }
}

4.3.1 Anwendungsereignisse

Ereignis	Beschreibung
Activated	Die Anwendung gelangt in den Vordergrund.
Deactivated	Die Anwendung ist keine Vordergrundanwendung mehr.
DispatcherUnhandledException	Wird ausgelöst, wenn eine nicht behandelte Exception aufgetreten ist.
Exit	Die Anwendung wird beendet.
SessionEnding	Soll die aktuelle Windowssitzung beendet werden, wird dieses Ereignis ausgelöst. Die Anwendung hat noch die Möglichkeit, das Beenden zu unterbinden. Beachten Sie allerdings dass es Verfahren gibt, auch ohne Rücksicht auf andere Anwendungen Windows zu beenden (z.B. durch einen Blue Screen).
Startup	Die Run()-Methode der Anwendung wurde aufgerufen, d.h. die Anwendung wurde gestartet.

Tabelle 4.1: Einige Ereignisse der Klasse Application

<Application...
<!-- In XAML sind dieser und der folg. Kommentar ungültig! -->
<!-- StartupUri="Window1.xaml" -->
     Startup="OnStartup"
     DispatcherUnhandledException="MainExHandler">
  <Application.Resources>
  </Application.Resources>
</Application>

Entweder Sie implementieren eine Ereignisbehandlung wie sie im folgenden Listing gezeigt wird oder Sie entfernen die Verknüpfung zwischen dem Startereignis Startup und der Methode OnStartup(), kommentieren die Methode OnStartup() im folgenden Code-Teil aus und verwenden die überschriebene Methode OnStartup(), die hier denselben Namen besitzt.

public partial class App: System.Windows.Application
{
  void OnStartup(object sender, StartupEventArgs e)
  {
    Window1 mainWindow = new Window1();
    mainWindow.Show();
  }
  // protected override void OnStartup(StartupEventArgs e)
  // {
  //   Window1 mainWindow = new Window1();
  //   mainWindow.Show();
  // }
  private void MainExHandler(object sender, DispatcherUnhandledExceptionEventArgs e)
  {
    MessageBox.Show("Exception aufgetreten: " + e.Exception.Message);
    e.Handled = true;
  }
}

<Window ...>
  <Grid>
    <Button Click="ErzeugeException">Exception auslösen</Button>
  </Grid>
</Window>

private void ErzeugeException(object sender, RoutedEventArgs e)
{
  throw new Exception("Kabumm");
}

4.3.2 Fensterereignisse

Ereignis	Beschreibung
Activated	Das Fenster gelangt in den Vordergrund.
Closed	Das Fenster wird geschlossen.
Closing	Wird aufgerufen wenn das Fenster geschlossen werden soll. Dies kann über die Eigenschaft Cancel des Parameters vom Typ CancelEventArgs aber verhindert werden. Weisen Sie ihm dazu den Wert true zu.
Deactivated	Das Fenster wurde deaktiviert, d.h. ein anderes Fenster wurde ausgewählt.
Initialized	Direkt nach der Erzeugung des Objekts durch den Konstruktor wird dieses Ereignis ausgelöst. Es sollten hier allerdings noch keine Zugriffe auf die Werte der Komponenten durchgeführt werden, da diese zum Teil noch unbestimmt sein können.
Loaded	Bringen Sie hier den Code unter, der direkt nach dem Initialisieren aller Elemente eines Fensters ausgeführt werden soll. Das Ereignis Initialized ist dazu meist ungeeignet, da das Layout der Komponenten noch nicht abgeschlossen ist.
LocationChanged	Die Position des Fensters hat sich geändert.
SizeChanged	Die Größe des Fensters hat sich geändert.
StateChanged	Der Fensterstatus (minimiert, maximiert, normal) hat sich geändert.
Unloaded	Das Fenster ist zerstört. Ein Zugriff auf die Elemente ist nicht mehr möglich.

Tabelle 4.2: Einige Ereignisse der Klasse Window

4.3.3 Ereignishandler dynamisch zuweisen

<StackPanel>
  <Button Click="ErzeugeVerknuepfung">
    Verknüpfung herstellen
  </Button>
  <Button Name="BtnEreignis">Keine Verknüpfung</Button>
</StackPanel>

private void ErzeugeVerknuepfung(object sender, RoutedEventArgs e)
{
  BtnEreignis.Click += new RoutedEventHandler(BtnEreignisClick);
  BtnEreignis.Content = "Jetzt verknüpft";
}
private void BtnEreignisClick(object sender, RoutedEventArgs e)
{
  MessageBox.Show("Klappt");
}

nach oben

4.4 Ereignisweiterleitung

Bei einem RoutedEvent wird ein Klick entweder an das jeweils untergeordnete oder übergeordnete Element weitergereicht oder es wird wie bisher direkt am auftreffenden Element konsumiert. Die WPF verwendet drei verschiedene Mechanismen zum Event Routing, d.h. auf welchem Wege Events durch den Elementbaum durchgereicht werden.

• Auf direktem Wege werden Ereignisse z.B. wie bei Windows Forms verarbeitet, d.h. von genau dem Element, bei dem das Ereignis aufgetreten ist - und nur von diesem Element.
• So genannte Bubbling Events (sprudeln, blubbern) werden vom Erzeuger jeweils an das nächste übergeordnete Elternelement weitergereicht, das nun ebenfalls darauf reagieren kann. Ein typisches Beispiel ist das Ereignis Click.
• Der andere Weg wird durch Tunneling Events (getunnelte Ereignisse) gegangen. Hier wird zuerst das Wurzelelement des gesamten Elementbaums über das Ereignis informiert. Dann wird das Ereignis in entgegen gesetzter Richtung bis zum Auslöser durchgereicht. Die Ereignisnamen werden bei getunnelten Events mit dem Präfix Preview versehen, allerdings ist diese Namensgebung keine Pflicht (z.B. bei der Erstellung eigener Ereignisse). Auf diese Weise kann z.B. ein übergeordnetes Element sämtliche Tastatureingaben überprüfen, bevor sie im konkreten untergeordneten Element verarbeitet werden.

Abbildung 4.2: Ereignisweiterleitung

Die meisten RoutedEvents haben auch ein korrespondierendes Preview-Event. So hat z.B. ein gebubbeltes MouseLeftButtonDown-Ereignis ein korrespondierendes getunneltes Ereignis PreviewMouseLeftButtonDown. Beide basieren auf demselben Ereignistyp MouseButtonEventHandler. Einige spezielle Ereignisse sind vom Typ Direct wie z.B. die Ereignisse MouseEnter und MouseLeave. Direkte Ereignisse werden direkt an der auftretenden Komponente verarbeitet (oder auch nicht). Sie werden weder gebubbelt noch getunnelt. Bei den beiden hier erwähnten Ereignissen wäre das auch nicht sonderlich sinnvoll, denn das Ereignis MouseEnter soll ja gerade dann eintreten, wenn die Maus eine ganz bestimmte Komponente beginnt zu überfahren.

Erwähnenswert ist auch das Ereignis Click. Dieses Ereignis wird in der Klasse ButtonBase bereitgestellt und basiert auf den Ereignissen MouseLeftButtonDown und MouseLeftButtonUp bzw. wird es in diesem Ereignissen ausgelöst. Es ist ein Bubbled Event und besitzt kein äquivalentes getunneltes Event. Da es in den Ereignissen MouseLeftButtonDown und MouseLeftButtonUp ausgelöst wird und diese eigentlich ersetzen soll, wird es als behandelt markiert. Das heißt, die beiden Ereignisse MouseLeftButtonDown und MouseLeftButtonUp werden nicht bis zur Wurzel "durchgebubbelt".

Um Festzustellen, von welchem Typ ein Ereignis ist, verwenden Sie die MSDN-Hilfe. Im Abschnitt Routed Event Information wird der Ereignistyp, die Routing Strategie sowie der Typ des Delegates angegeben. Gibt es ein korrespondierendes Ereignis, wird dies unter den Standardinformationen ebenfalls angegeben. Kann außerdem eine Methode überschrieben werden, die beim Auftreten des Ereignisses aufgerufen wird, steht diese ebenfalls hier.

Abbildung 4.3: Informationen zum Ereignistyp ermitteln

Abbildung 4.4: Protokollierter Ereignisfluss

<Window ... MouseDown="RoutedClick" PreviewMouseDown="TunnelClick"
            ButtonBase.Click="RoutedClick">
  <StackPanel Name="StackPanelAussen" MouseDown="RoutedClick"
              PreviewMouseDown="TunnelClick" ButtonBase.Click="RoutedClick">
    <Button Click="RoutedClick" MouseDown="RoutedClick"
            PreviewMouseDown="TunnelClick" Name="ButtonAussen">
      <StackPanel Orientation="Horizontal"
                  Name="StackPanelMitte" MouseDown="RoutedClick"
                  PreviewMouseDown="TunnelClick">
        <Border Background="LightBlue" BorderBrush="Black"
                BorderThickness="2" Name="Border" MouseDown="RoutedClick"
                PreviewMouseDown="TunnelClick">
          <StackPanel Orientation="Horizontal" Name="StackPanelInnen"
                      MouseDown="RoutedClick" PreviewMouseDown="TunnelClick">
            <Label Name="Label" MouseDown="RoutedClick"
                   PreviewMouseDown="TunnelClick">Hallo</Label>
          </StackPanel>
        </Border>
      </StackPanel>
    </Button>
    <TextBox>Hallo</TextBox>
    <ListBox Name="EventLB" Height="250"/>
  </StackPanel>
</Window>

private void RoutedClick(object sender, RoutedEventArgs e)
{
  EventLB.Items.Add(e.RoutedEvent.ToString() + "> " + sender.GetType().ToString() +
                    ", " + (sender as FrameworkElement).Name);
  e.Handled = false;
}
private void TunnelClick(object sender, MouseButtonEventArgs e)
{
  EventLB.Items.Add(e.RoutedEvent.ToString() + "> " + sender.GetType().ToString() +
                    ", " + (sender as FrameworkElement).Name);
  e.Handled = false;
}

nach oben

4.5 Ereignismethoden

Beim Überschreiben der Methoden muss darauf geachtet werden, dass sie mit protected override gekennzeichnet werden. Für das Ereignis Click müsste z.B. die Methode OnClick() überschrieben werden.

<Window ...
        xmlns:frischa="clr-namespace:EreignisMethodenProj"
        Title="EreignisMethodenProj" Height="300" Width="300">
  <StackPanel>
    <frischa:NewButton>Klick mich</frischa:NewButton>
  </StackPanel>
</Window>

using System;
using System.Windows.Controls;
using System.Windows;
namespace EreignisMethodenProj
{
  class NewButton: Button
  {
    protected override void OnClick()
    {
      base.OnClick();
      MessageBox.Show("Klick");
    }
  }
}

nach oben