Ввод, управляемый событиями

Многие консольные программы вообще не взаимодействуют с пользователем. Типичное консольное приложение получает всю нужную информацию из командной строки, выполняет свои функции и завершает работу. Если в консольной программе требуется взаимодействие с пользователем, она получает входные данные с клавиатуры. В .NET Framework консольные программы получают данные с клавиатуры, вызывая методы Read или ReadLine класса Console. После того, как программа перестает получать данные с клавиатуры, программа продолжает работу.

Программы, предназначенные для работы в графических средах, используют другую модель ввода. Одна из причин этого состоит в существовании разных типов устройств ввода. Информация вводится не только с клавиатуры, но и с помощью мыши. Кроме того, программы могут создавать элементы управления, например кнопки, меню, полосы прокрутки, взаимодействующие с пользователем от имени главной программы.

Я полагаю, что теоретически программная среда, поддерживающая разные устройства ввода, могла бы взаимодействовать со всеми этими устройствами используя технологию последовательного опроса (serial polling). При последовательном опросе программа проверяет наличие ввода с клавиатуры, при его отсутствии проверяет мышь, если с помощью мыши ничего не вводили, проверяет ввод через меню, а меню в свою очередь проверяет клавиатуру и мышь и т.д. До эры Windows программы, работающие в символьном режиме и использующие мышь, выполняли последовательный опрос.

Однако гораздо лучшей моделью ввода с различных устройств является модель ввода, управляемая событиями (event-driven). В Windows Forms каждый тип ввода связан с определенным методом класса. Когда происходит определенное событие (скажем, нажимается клавиша, перемещается мышь или выбирается пункт меню программы), то как бы из-за пределов программы вызывается соответствующий метод.

Сначала такая модель ввода кажется хаотичной. Так как пользователь стучит по клавишам, двигает мышь, нажимает кнопки, использует полосы прокрутки и выбирает пункты меню, постоянно вызываются методы программы со всевозможных направлений. Но на практике все оказывается более упорядоченным, так как все вызовы методов выполняются в одном потоке. Только после того как один метод завершит обработку своего события, вызывается другой метод другого события.

После того как программа для Windows Forms выполнила инициализацию формы, все, что она делает, каждый, даже самый небольшой, фрагмент ее кода — это ответ на событие. Большую часть времени программа бездействует, находясь где-то внутри вызова Application.Run и ожидая события. Часто имеет смысл воспринимать программы для Windows Forms как конечные автоматы (state machine) состояние которых целиком определяется изменениями, вносимыми событиями.

События играют настолько важную роль, что их поддержка органично встроена в .NET Framework и С#. События наряду с конструкторами, полями, методами и свойствами являются членами классов. Когда программа определяет метод, выполняющий обработку события, этот метод называется обработчиком события (event handler). Параметры обработчика должны соответствовать функции-прототипу — делегату (delegate). Мы в скором времени рассмотрим, как это все работает.

Как вы узнаете в главе 6, имеется три разных типа событий клавиатуры. Один сообщает о нажатии клавиши, другой — об отпускании клавиши, третий — о том, что при нажатии определенной клавиши или комбинации клавиш сгенерирован код символа.

В главе 8 я вас познакомлю с 7 типами событий мыши, сообщающих о ее перемещении и об одинарных или двойных щелчках ее кнопок.

В главе 10 вы узнаете о событии таймера. Оно периодически оповещает форму об истечении определенного периода времени. Программы, показывающие часы, используют событие таймера, чтобы каждую секунду обновлять время.

В главе 12, когда мы начнем создавать элементы управления (кнопки, текстовые поля, списки) и помещать их на формы, вы узнаете, что эти элементы управления передают информацию форме через события. Именно события сообщают о нажатии кнопки или изменении текста в поле.

В главе 14 вы узнаете, что меню также передают информацию форме через события. Есть события, сообщающие о том, что будет показано выпадающее меню, о выборе пункта меню и о щелчке по пункту меню.

Но одно из самых странных событий — даже не верится, что оно может быть событием, — является в то же время и одним из самых важных. Это Paint. Оно сообщает программе о необходимости отобразить информацию в окне.

Ничто так отчетливо не раскрывает огромную разницу между программами с интерфейсом командной строки и графическими, как событие Paint. Программа с интерфейсом командной строки отображает информацию, когда сочтет нужным. Программа Windows Forms также может отображать информацию, когда захочет, но делает это несколько иначе. Paint информирует программу о том, что вся клиентская область или ее часть недействительна (invalid) и требует перерисовки.

Как клиентская область становится недействительной? Когда форма только что создана, вся клиентская область недействительна, так как программа еще ничего в ней не показывала. В программе происходит первое событие Paint, сообщающее о необходимости показать что-нибудь в клиентской области.

Когда вы перемещаете окна по экрану, так что они перекрывают друг друга, Windows не запоминает вид клиентской области, закрытой другим окном. Потом, когда клиентская область снова открывается, программа должна восстановить ее вид. Поэтому в ней и происходит событие Paint. Когда окно программы после свертывания возвращается в нормальное состояние, в ней также происходит событие Paint.

Windows-программа должна быть способна перерисовать свою кпиентскую область в любой момент времени. Она должна запоминать всю нужную для этого информацию или иметь возможность быстро обратиться к этой информации. Может показаться, что структуризация программ для правильной обработки события Paint накладывает слишком жесткие ограничения, но в противном случае работа программы замедлится.