Ereignismodell für ASP.NET-Serversteuerelemente

Durch ASP.NET-Serversteuerelemente ausgelöste Ereignisse unterscheiden sich geringfügig von Ereignissen in herkömmlichen Clientformularen oder clientbasierten Webanwendungen. Der Unterschied entsteht hauptsächlich durch die Trennung des Ereignisses selbst von der Stelle, wo das Ereignis behandelt wird.

In clientbasierten Anwendungen werden Ereignisse auf dem Client ausgelöst und behandelt. In Web Forms-Seiten werden den Serversteuerelementen zugeordnete Ereignisse auf dem Client ausgelöst, jedoch vom ASP.NET-Seitengerüst auf dem Webserver behandelt.

Für auf dem Client ausgelöste Ereignisse benötigt das Ereignismodell für Web Forms-Steuerelemente auf dem Client erfasste Ereignisinformationen sowie eine Ereignismeldung, die über eine HTTP-Sendung an den Server übertragen wird. Das Seitengerüst muss das Senden interpretieren, um festzustellen, welches Ereignis aufgetreten ist, und muss dann die entsprechende Methode im Code auf dem Server aufrufen, um das Ereignis zu behandeln. Weitere Informationen finden Sie unter Ereignisse in ASP.NET-Serversteuerelementen.

Das Ereignismodell für Web Forms-Steuerelemente

ASP.NET behandelt praktisch alle Mechanismen für das Erfassen, Senden und Interpretieren des Ereignisses. Beim Erstellen von Ereignishandlern in einer Web Forms-Seite müssen Sie sich nicht darum kümmern, wie die Ereignisinformationen erfasst und dem Code zur Verfügung gestellt werden. Stattdessen können Sie Ereignishandler wie in einem traditionellen Clientformular erstellen. Allerdings gibt es einige Aspekte bei der Ereignisbehandlung in Web Forms-Seiten, die Sie kennen sollten.

Immanenter Ereignissatz

Weil die meisten Web Forms-Ereignisse für die Verarbeitung eine Schleife zum Server benötigen, können sie die Leistung eines Formulars beeinflussen. Daher bieten Serversteuerelemente einen eingeschränkten Satz an immanenten Ereignissen, die normalerweise auf Klickereignisse beschränkt sind. Einige Serversteuerelemente unterstützen eine bestimmte Version des onchange-Ereignisses, das ausgelöst wird, sobald sich die Werte des Steuerelements ändern. Beispielsweise löst das CheckBox-Webserversteuerelement ein Änderungsereignis aus, wenn der Benutzer auf das Feld klickt. Oft stattfindende Ereignisse (die ohne Wissen des Benutzers ausgelöst werden können), wie das onmouseover-Ereignis, werden für Serversteuerelemente nicht unterstützt.

**Hinweis   **Einige Serversteuerelemente unterstützen einen Satz von Ereignissen auf höherer Ebene. Beispielsweise löst das Calendar-Webserversteuerelement ein SelectionChanged-Ereignis aus, das eine abstraktere Version eines Click-Ereignisses ist.

Ereignisargumente

Ereignisse für Web- und HTML-Serversteuerelemente folgen einem .NET Framework-Standardmuster für Ereignishandlermethoden. Alle Ereignisse übergeben zwei Argumente: ein Objekt, das das Ereignis auslösende Objekt darstellt, und ein Ereignisobjekt, das ereignisspezifische Informationen enthält. Das zweite Argument ist normalerweise vom Typ System.EventArgs, allerdings entspricht der Typ bei manchen Steuerelementen einem für das jeweilige Steuerelement spezifischen Typ. Beispielsweise ist bei einem ImageButton-Webserversteuerelement das zweite Argument vom Typ ImageClickEventArgs, das Informationen über die Koordinaten der Position enthält, an der der Benutzer geklickt hat.

Rücksendeereignisse und Nichtrücksendeereignisse in Webserversteuerelementen

In Webserversteuerelementen wird das Formular durch bestimmte Ereignisse, in der Regel Klickereignisse, an den Server zurückgesendet. Änderungsereignisse in HTML- und Webserversteuerelementen, z. B. dem TextBox-Steuerelement, werden erfasst, verursachen jedoch kein sofortiges Senden. Stattdessen werden sie vom Steuerelement im Cachespeicher so lange zwischengespeichert, bis das nächste Senden stattfindet. Wenn anschließend die Seite wieder auf dem Server verarbeitet wird, werden alle anstehenden Ereignisse ausgelöst und verarbeitet.

Hinweis   Sofern der Browser dies unterstützt, können Überprüfungssteuerelemente mit Hilfe des Clientskripts Benutzereingaben prüfen, ohne dass eine Schleife zum Server ausgeführt wird. Ausführliche Informationen finden Sie unter Einführung in die Überprüfung der Benutzereingabe in Web Forms.

Während der Serverseitenverarbeitung werden zuerst Ereignisse ohne bestimmte Reihenfolge verarbeitet. Nachdem alle Änderungsereignisse verarbeitet wurden, wird das Klickereignis verarbeitet, aufgrund dessen das Formular gesendet wurde.

**Hinweis   **Sie sollten keine Anwendungslogik erstellen, die von in einer bestimmten Reihenfolge ausgelösten Änderungsereignissen abhängt, es sei denn, Sie verfügen über fundierte Kenntnisse der Seitenereignisverarbeitung. Weitere Informationen finden Sie unter Beispiel für ein Postback-Ereignis.

Sie können angeben, dass ein Änderungsereignis eine Formularsendung auslöst. Webserversteuerelemente, die ein Änderungsereignis unterstützen, enthalten eine AutoPostBack-Eigenschaft. Wenn diese Eigenschaft auf true festgelegt wurde, löst das Änderungsereignis des Steuerelements das Senden des Formulars sofort aus, ohne auf ein Klickereignis zu warten. So löst das CheckedChange-Ereignis eines CheckBox-Steuerelements z. B. keine Übermittlung der Seite aus. Wenn Sie die AutoPostBack-Eigenschaft des Steuerelements auf true festlegen, geben Sie an, dass die Seite zur Verarbeitung an den Server gesendet wird, sobald ein Benutzer auf das Kontrollkästchen klickt.

Hinweis   Damit die AutoPostBack-Eigenschaft ordnungsgemäß funktioniert, muss der Browser des Benutzers Skripts zulassen. Meistens ist das die Standardeinstellung. Allerdings deaktivieren manche Benutzer Skripts aus Sicherheitsgründen. Weitere Informationen finden Sie unter ASP.NET-Serversteuerelemente und Browserfunktionen.

Weitergeleitete Ereignisse

Webserversteuerelemente wie Repeater, DataList und DataGrid können Schaltflächensteuerelemente enthalten, die Ereignisse auslösen. Beispielsweise kann jede Zeile in einem DataGrid-Steuerelement eine oder mehrere Schaltflächen enthalten, die dynamisch von Vorlagen erstellt wurden.

Ereignisse werden nicht von den einzelnen Schaltflächen individuell ausgelöst, sondern von geschachtelten Steuerelementen weitergeleitet, d. h., sie werden an den Container gesendet. Der Container wiederum löst ein generisches Ereignis, ItemCommand, mit Parametern aus, mit dem Sie feststellen können, welches individuelle Steuerelement das ursprüngliche Ereignis ausgelöst hat. Sie brauchen keine individuellen Ereignishandler für untergeordnete Steuerelemente mehr zu schreiben, wenn Sie auf dieses einzelne Ereignis reagieren.

Das ItemCommand-Ereignis enthält die beiden Standardereignisargumente, ein Objekt, das auf die Quelle des Ereignisses verweist, sowie ein Ereignisobjekt, das ereignisspezifische Informationen enthält.

Hinweis   Die DataGrid- und DataList-Webserversteuerelemente unterstützen zusätzliche Ereignisse wie EditCommand, DeleteCommand und UpdateCommand, bei denen es sich um Sonderfälle von weitergeleiteten Ereignissen handelt.

Mit Schaltflächen können Sie die CommandArgument-Eigenschaft verwenden, um eine benutzerdefinierte Zeichenfolge an den Ereignishandler zu übergeben, damit Sie wissen, welche Schaltfläche das Ereignis ausgelöst hat. In einem DataList-Steuerelement lösen Schaltflächen beispielsweise das ItemCommand-Ereignis aus. Sie können die CommandArgument-Eigenschaft jeder Schaltfläche auf einen anderen Wert festlegen. So könnten Sie z. B. den Wert einer Schaltfläche auf "ShowDetails" und den Wert einer anderen Schaltfläche auf "AddToShoppingCart" festlegen und diese Werte später im Ereignishandler erfassen.

Ereignisdelegaten in Web Forms-Seiten

Ein Ereignis ist eine Meldung, ungefähr wie "es wurde auf eine Schaltfläche geklickt". In der Anwendung soll die Meldung in Ihrem Code in einen Methodenaufruf umgesetzt werden, wie z. B. "Button1_Click". Die Bindung zwischen der Ereignismeldung und eine spezifischen Methode – d. h. einem Ereignishandler – erfolgt mit einem Ereignisdelegaten. Weitere Informationen finden Sie unter Ereignisse und Delegaten.

In Web Forms-Seiten müssen Sie Delegaten in der Regel nicht explizit codieren. Wenn Sie den Web Forms-Designer in Visual Studio verwenden, wird Code generiert, der Ereignisse automatisch an Methoden bindet. In Visual Basic erfolgt dies wie im folgenden Beispiel gezeigt mit Hilfe des Handles-Schlüsselworts in der Deklaration des Ereignishandlers:

Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

In Visual C# generiert der Designer einen expliziten Ereignishandlerdelegaten ähnlich dem Folgenden in der Seite:

private void InitializeComponent()
{   
   this.Load += new System.EventHandler(this.Page_Load);
}

Alternativ unterstützt das ASP.NET-Seitengerüst auch eine Möglichkeit, Seitenereignisse und -methoden automatisch zuzuordnen. Wenn das AutoEventWireup-Attribut der Page-Direktive auf true festgelegt ist (oder fehlt, weil es standardmäßig true lautet), ruft das Seitengerüst automatisch Seitenereignisse auf, insbesondere die Methoden Page_Init und Page_Load. In diesem Fall ist keine explizite Handles-Klausel oder kein Delegat erforderlich.

Der Nachteil des AutoEventWireup-Attributs ist der, dass die Handler für Seitenereignisse spezifische, vorhersagbare Namen haben müssen. Sie sind bei der Benennung Ihrer Ereignishandler eingeschränkt. Daher ist das AutoEventWireup-Attribut in Visual Studio standardmäßig auf false festgelegt, und der Designer generiert expliziten Code zum Binden von Seitenereignissen an Methoden.

Wenn Sie das AutoEventWireup-Attribut auf true setzen, generiert Visual Studio Code zum Binden der Ereignisse. Darüber hinaus ruft das Seitengerüst automatisch Ereignisse auf der Grundlage ihrer Namen auf. Dies kann zur Folge haben, dass der Ereigniscode beim Ausführen der Seite zweimal ausgeführt wird. Folglich müssen Sie das AutoEventWireup-Attribut bei der Arbeit in Visual Studio immer auf false gesetzt lassen.

Reagieren auf Client- und Serverereignisse in ASP.NET-Serversteuerelementen

Im Großen und Ganzen sind Sie hauptsächlich an Ereignissen interessiert, die im Servercode ausgelöst werden. Sie können allerdings auch clientseitige Ereignisse für ASP.NET-Serversteuerelemente mit Hilfe von Clientskripts verarbeiten, wenn Ihre Anwendung dies unterstützt.

Hinweis   Sie können keine HTML-Syntax zum Binden an clientseitige Ereignisse für Webserversteuerelemente verwenden. Stattdessen müssen Sie Attribute für Ereignisbindungen im Code hinzufügen. Ein Beispiel finden Sie in der Tabelle unten.

Beispiel: Sie haben ein HTML-Bildschaltflächenelement in ein HTML-Serversteuerelement konvertiert. In einer Web Forms-Seite würden Sie das Klickereignis dieser Bildschaltfläche im Servercode behandeln. Sie können jedoch auch im Clientcode festlegen, dass sich das Bild ändert, sobald der Benutzer die Maus darüber bewegt. Erstellen Sie hierfür ein Clientskript für das onmouseover-Ereignis der Bildschaltfläche. (Nehmen Sie in diesem Beispiel an, dass Sie mit einem Browser arbeiten, der HTML 4.0 unterstützt, wie Microsoft Internet Explorer 4.0 oder höher.)

**Hinweis   **Falls die Namen des clientseitigen und des serverseitigen Ereignishandlers gleich sind, wird zuerst der clientseitige und dann der serverseitige Ereignishandler ausgeführt. Dieses Szenario ist allerdings etwas verwirrend. Aus diesem Grund sollte die Namenskonvention vorher geplant werden.

Behandeln eines Klickereignisses in Client- und in Servercode

Bei einem Ereignis – dem onclick-Ereignis des Clients – kommt es zu Schwierigkeiten, wenn Sie es auf dem Client und dem Server behandeln möchten. Das Problem tritt auf, weil alle Schaltflächen-Serversteuerelemente (und andere Steuerelemente, deren AutoPostBack-Eigenschaft auf true gesetzt ist) die Seite an den Server übermitteln. Bei HTML übermitteln naturgemäß nur wenige Steuerelemente ein Formular:

• Die HTML-Sendeschaltfläche (<INPUT type=submit>), bei der es sich um das HtmlInputButton-Steuerelement handelt, dessen Typ auf Submit oder Image festgelegt ist. Sie können dieses Steuerelement über die Registerkarte HTML der Toolbox hinzufügen.
• Das Button-Webserversteuerelement (<asp:button>).

Für alle anderen Steuerelemente, die zum Absenden der Seite angegeben wurden, wird ein kleines Clientskript in die Seite gestellt und zum Absenden des Formulars aufgerufen, wenn auf das Steuerelement geklickt wird. Diese Steuerelemente verwenden daher bereits das clientseitige OnClick-Ereignis zum Aufrufen dieses Sendeskripts.

Sie können zwar für alle Steuerelemente clientseitige OnClick-Handler erstellen, müssen aber die Methode wählen, die mit den einzelnen Steuerelementtypen verwendet werden kann. Die folgende Tabelle enthält eine Zusammenfassung der Strategien für verschiedene Steuerelementtypen.

Steuerelement	Strategie
HtmlInputButton mit HTML-Serversteuerelement-Schaltflächen, deren Typ auf Submit, Reset oder Image festgelegt ist	Fügen Sie ein onclick-Attribut in die HTML-Syntax für das Steuerelement ein: <INPUT Type="Submit" Runat="Server" Value="caption" onclick="clientfunction()" ...> Auf der Serverseite lösen diese Schaltflächentypen ein ServerClick-Ereignis anstelle eines einfachen Click-Ereignisses aus. Das Clientereignis wird zuerst ausgelöst; anschließend wird das Formular gesendet, und das Serverereignis wird behandelt.
Alle anderen HTML-Steuerelemente (die, die standardmäßig kein Formular absenden)	Fügen Sie ein onclick-Attribut, gefolgt von einem Strichpunkt (;), in die HTML-Syntax für das Steuerelement ein: <INPUT Type="Button" Runat="Server" Value="caption" onclick="clientfunction();" ...> Dadurch wird Ihre Funktion vor dem clientseitigen Sendeskript aufgerufen.
Webserversteuerelemente, einschließlich Schaltflächen (<asp:button>) und andere Steuerelemente (z. B. <asp:checkbox>)	Sie können in der HTML-Syntax für ein Webserversteuerelement kein clientseitiges Ereignis angeben. Fügen Sie dem Steuerelement zur Laufzeit stattdessen ein Ereignisattribut im Servercode hinzu. Verwenden Sie dabei Code ähnlich dem Folgenden: Button1.Attributes.Add("onclick", "clientfunction();") Hinweis   Für das Button-Webserversteuerelement brauchen Sie keinen Strichpunkt, weil das Steuerelement die Seite automatisch absendet.

Anwendungs- und Sitzungsereignisse

Zusätzlich zu Seiten- und Steuerelementereignissen bietet das ASP.NET-Seitengerüst Möglichkeiten zur Arbeit mit Ereignissen, die ausgelöst werden können, wenn die Anwendung gestartet oder gestoppt oder die Sitzung eines einzelnen Benutzers gestartet oder gestoppt wird:

• Anwendungsereignisse werden für alle Anforderungen einer Anwendung ausgelöst. Beispielsweise wird Application_BeginRequest ausgelöst, wenn eine beliebige Web Forms-Seite oder ein beliebiger XML-Webdienst in der Anwendung angefordert wird. Mit diesem Ereignis können Sie Ressourcen initialisieren, die für die Anforderungen an die Anwendung verwendet werden. Ein entsprechendes Ereignis, Application_EndRequest, gibt Ihnen die Möglichkeit, für die Anforderung verwendete Ressourcen zu schließen oder freizugeben.
• Sitzungsereignisse sind Anwendungsereignissen ähnlich (es gibt ein Session_Start-Ereignis und ein Session_End-Ereignis), sie werden jedoch mit jeder einzelnen Sitzung innerhalb der Anwendung ausgelöst. Eine Sitzung beginnt, wenn ein Benutzer eine Seite zum ersten Mal von der Anwendung anfordert, und endet, wenn die Anwendung die Sitzung explizit schließt oder wenn die Sitzung das Zeitlimit überschreitet.

Sie können in der Datei Global.asax Handler für diese Ereignistypen erstellen. Weitere Informationen finden Sie unter Die Datei "Global.asax" und Syntax von "Global.asax".

Siehe auch

Serverereignisbehandlung in Web Forms-Seiten | Datei "Global.asax" | Einführung in die Web Forms-Statusverwaltung | Arbeiten mit HttpApplication-Instanzen