Назначение этих событий - уведомлять привязку о том, что свойство изменилось. Выполнив проверку допустимости, привязка обеспечит синхронизацию нового значения свойства с объектом, к которому оно привязано. Еще один шаг должен быть выполнен для поддержки привязки. Изменение в текстовом поле, выполненное пользователем, не установит новое значение свойства непосредственно. Поэтому необходимо также возбудить событие propertynameChanged при изменении значения в текстовом поле. Простейший способ сделать это - отслеживать событие TextChanged элемента управления TextBox. В нашем примере будет только один обработчик событий TextChanged, и все текстовые поля будут использовать его. Имя элемента управления проверяется, чтобы увидеть, в каком именно элементе произошло изменение, и затем возбудить соответствующее событие propertyNameChanged. Ниже представлен код этого обработчика событий.

private void controls TextChanged(object sender, System.EventArgs e)

switch(((TextBox)sender).Name)

case txtAddress1 :

if(AddressLine1Changed != null)

AddressLine1Changed(this, EventArgs.Empty);

break; case txtAddress2 :

if(AddressLine2Changed != null)

AddressLine2Changed(this, EventArgs.Empty);

break; case txtCity :

if(CityChanged != null)

CityChanged(this, EventArgs.Empty); break; case txtState :

if(StateChanged != null)

StateChanged(this, EventArgs.Empty); break; case txtZip :

if(ZipChanged != null)

ZipChanged(this, EventArgs.Empty); break;

Здесь мы применяем простой оператор switch для определения того, какое из текстовых полей вызвало событие TextChanged. После этого выполняется проверка, чтобы убедиться, что событие корректно и не равно null.

Затем возбуждается событие Changed. Обратите внимание, что при этом отправляется пустой EventArgs (EventArgs.Empty). Тот факт, что эти события были добавлены к свойствам для поддержки привязки данных, не значит, что единственный способ использования нашего элемента управления лежит через привязку данных. Они добавлены так, чтобы пользовательский элемент управления мог использовать привязку в случае ее наличия. Это лишь один из способов обеспечения максимальной гибкости пользовательского элемента управления, чтобы его можно было применять в самых разнообразных ситуациях.

Памятуя о том, что пользовательский элемент управления - это, по сути, элемент управления с дополнительными возможностями, все связанное с применением его в среде дизайнера, что мы обсуждали в предыдущем разделе, также применимо и здесь. Инициализация пользовательского элемента управления может привести к тем же

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

Еще одна вещь, подобная созданию элементов управления - это атрибуты, применяемые к пользовательским элементам управления. Общедоступные свойства и методы пользовательского элемента управления отображаются в окне свойств, когда он помещается в дизайнер. В примере с адресом неплохо будет добавить атрибуты Category, Description и DefaultValue к свойствам адреса. Можно создать новую категорию AddressData со значением по умолчанию . Ниже показан пример применения этих атрибутов к свойству AddressLine1.

[Category( AddressData ),

Description( Gets or sets the AddressLine1 value ), DefaultValue( )]

public string AddressLine1

get{return txtAddress1.Text;} set{

if(txtAddress1.Text != value)

txtAddress1.Text = value; if(AddressLine1Changed != null) AddressLine1Changed(this, EventArgs.Empty);

Как видите, все, что нужно сделать для добавления новой категории - это установить текст в атрибуте Category. Это автоматически добавляет новую категорию.

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

Резюме

В этой главе было дано представление о базовых принципах построения клиентских Windows-приложений. Были описаны стандартные элементы управления, образующие иерархию классов пространства имен Windows.Forms, и рассмотрены различные их свойства и методы.

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

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