Замечание. Все события типа Page работают с делегатом System.EventHandler.
Чтобы обработать события для страницы, нужно добавить в блок ‹script› или файл с внешним кодом поддержки подходящий обработчик события. В отличие от ASP.NET 1.x. теперь не требуется вводить всю программную логику события вручную. Нужна только определить соответствующий метод, используя следующий шаблон.
protected Page_nameOfTheEvent(object sender, EventArgs e)
Например, cобытие Unload можно обработать так.
public partial class _Default: System.Web.UI.Page {
protected void Page_Load(object sender, EventArgs e) {
}
protected void Page_Unload(object sender, EventArgs e) {
}
}
Этот метод, как по волшебству, вызывается при выгрузке страницы (несмотря на то, что вы не применяли синтаксис событий C#), поскольку атрибут AutoEventWireUp устанавливается равным true (истина) по умолчанию в директиве ‹%@Page%› вашего файла *.aspx.
‹%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %›
Как подсказывает имя этого атрибута, при его активизации будет создана необходимая оснастка событий в рамках автоматически генерируемого парциального класса, описанного в этой главе выше. Если установить этот атрибут равным false, не будут вызваны обработчики событий ни для Load, ни для Unload страницы Default (вы можете проверить это непосредственно, установив контрольные точки в пределах обработчиков событий Page_Load() и Page_Unload()).
Однако, если вы используете стандартный синтаксис событий C# для обработки событий Load и Unload, как показано ниже:
public partial class _Default: System.Web.UI.Page {
public _Default() {
// Явный перехват событий Load и Unload.
this.Load += new EventHandler(Page_Load);
this.Unload += new EventHandler(Page_Unload);
}
protected void Page_Load(object sender, EventArgs e) {
Response.Write("Сработало событие Load!");
}
protected void Page_Unload(object sender, EventArgs e) {
// Направить данные в HTTP-ответ здесь невозможно,
// поэтому выполняется запись в локальный файл.
System.IO.File.WriteAllText(@"C:\MyLog.txt", "Выгрузка страницы.");
}
protected void btnPostback_Click(object sender, EventArgs e) {
// Здесь ничего не происходит, но это гарантирует
// вторичный запрос к странице.
}
}
то эти события будут перехвачены вашей страницей независимо от значения, заданного для AutoEventWireup.
В качестве заключительного замечания напомним, что с момента вызова события Unload вы не сможете взаимодействовать с подлежащим отправке HTTP-ответом (если вы попытаетесь вызвать члены объекта HttpResponse, среда выполнения сгенерирует соответствующее исключение). Поэтому здесь обработчик события Unload просто отправляет строку текста в файл на локальном диске C.
Еще одним событием, которое может происходить в цикле существования страницы, является событие Error, которое также работает в паре с делегатом System.EventHandler. Это событие возникает в том случае, когда метод производного от Page типа генерирует исключение, оставшееся без явной обработки. Предположим, что вы обработали событие Click для типа Button на странице, и в пределах обработчика события (здесь он называется btnGetFile_Click) вы пытаетесь записать, содержимое локального файла в HTTP-ответ.
Также предположим, что вам
public partial class _Default: System.Web.UI.Page {
public _Default() {
…
// Создание объекта для события Error.
this.Error += new EventHandler(_Default_Error);
