2. Работа с наборами типизированных данных

Код Windows Forms генерируемый конструктором

но когда вы перешли в

В предыдущем разделе я упомянул, что все ваши интерактивные действия в конструкторе были в действительности автоматической генерацией кода. Но когда вы перешли в вид Code для файла Forml. cs, то не увидели там почти ничего, кроме конструктора формы, вызывающего некоторый метод с именем InitializeComponent, и метода обработчика события, который вы создали при посредстве окна Properties. Так куда же девается весь тот код, который объявляет переменные для элементов управления, устанавливает их свойства, подключает обработчик события и т. д.? Ответ на этот вопрос связан с одной из новых и улучшенных особенностей Visual Studio 2005. В предыдущих версиях Visual Studio код, генерируемый конструктором, встраивался в регион внутри самого файла кода формы. Возникающая при этом проблема носила двоякий характер. Во-первых, этот код часто удаляли по ошибке, уничтожая тем самым форму. Во-вторых, генерируемый конструктором код никогда, вообще говоря, не должен модифицироваться вручную, потому что любые внесенные вами изменения могут быть переписаны конструктором, когда вы будете в следующий раз делать изменения из вида Design. Встраивание этого кода в основной исходный файл вызывало слишком большое искушение залезть в него и сделать какие-то изменения, что приводило к пропаже кода и замешательству новичков. Новой особенностью языка в. NET 2.0 является возможность объявлять неполные классы. Это позволяет вам распределить определение одного класса по нескольким исходным файлам. Visual Studio 2005 применяет эту возможность для выделения кода, генерируемого конструктором, в отдельный исходный файл, который в дереве Solution Explorer располагается в проекте как вложенный в главный исходный файл формы. Если вы хотите посмотреть содержимое этого файла, разверните дерево в окне Solution Explorer, щелкнув на значке плюса рядом с Forml. cs. Под Forml. cs вы увидите файл Forml. Designer. cs. Если вы откроете этот файл, то найдете там генерированный конструктором код во всей его красе.

Интерфейсы lEnumerable и lEnumerator: поддержка итерации по коллекциям

когда вы реализуете i b

Реализуйте интерфейс LEnumerable, Чтобы предоставить потребителям вашей коллекции возможность различными способами проходить по всем ее объектам. Когда вы реализуете LEnumerable, Необходимо также по меньшей мере в одном классе реализовать LEnumerator И возвращать экземпляр этого класса из метода LEnumerable.GetEnumerator. Реализация LEnumerator Предоставляет методы и свойства, позволяющие осуществлять итерацию по объектам коллекции. Можно предусмотреть несколько реализаций LEnumerator, Чтобы обеспечить различные способы итерации по коллекции.

Потребность в итерации по коллекциям объектов далеко выходит за рамки привязки данных. В старых языках и технологиях программирования характер поддержки, предоставляемой для итерации, и действительный способ ее осуществления вовсе не были согласованы. Архитекторы. NET Framework позаботились о таком согласовании, специфицировав для итерации модель и реализацию, которые должны поддерживаться всеми коллекциями в. NET, вне зависимости от языка. Кроме того, в большинство языков. NET введена прямая поддержка для итерации, основанная на этой модели, поэтому вам редко придется непосредственно иметь дело с интерфейсами LEnumerable И LEnumerator, Хотя именно они и приводят в действие скрытые механизмы итерации. Итак, в основе модели итерации лежат два интерфейса: LEnumerable И LEnumerator. В типе коллекции должен быть реализован интерфейс LEnumerable, Показывающий, что коллекция поддерживает итерацию по содержащимся в ней объектам.

Интерфейс LEnumerable Содержит всего один метод, который этот тип должен реализовывать:

Наследование от DataGridView и обработка события CellFormatting

дело в том что соответствующее

Первым шагом является объявление класса, производного от DataGridView: Почти во всех случаях, когда вы переопределяете один из методов Onххх, вы должны вызвать метод базового класса в конце или в начале заменяющего метода, в зависимости от того, что ваш метод делает. Дело в том, что соответствующее событие, которое может быть обработано в коде клиента, запускается именно методом базового класса. Кроме того, метод базового класса может производить какую-то дополнительную работу, которая обычно должна быть выполнена даже том случае, когда вы в методе производного элемента управления предусматриваете свою собственную обработку. Размещаете ли вы свой специальный код до или после вызова метода базового класса, определяется тем, воздействует ли ваш код на другие элементы класса, что может приводить к побочным эффектам в зависимости от действий, производимых с ними методом базового класса. Здесь нужно либо знать, что будет делать базовый метод, для чего можно воспользоваться инструментом, таким, как Reflector, чтобы изучить его реализацию, либо просто поэкспериментировать с вызовом метода, чтобы получилось именно то, что вам нужно. Итак, первым действием этого заменяющего метода OnCellFormatting Является вызов его реализации в базовом классе. Затем он проверяет, не является ли индекс строки нулем, и если является, обработчик просто возвращает управление, ничего больше не делая. Тем самым гарантируется, что значения ячеек первой строки всегда будут форматироваться обычным образом. Для строк после первой обработчик вызывает вспомогательный метод, проверяющий, не совпадает ли значение текущей ячейки со значением предыдущей ячейки в том же столбце. Если это так, обработчик устанавливает в качестве значения ячейки пустую строку, чтобы в ней ничего на отображалось. Как говорилось в главе 6, всякий раз, когда вы изменяете форматированное значение ячейки, следует установить флаг Format — TingApplied, Что и делается в листинге 8.1 после установки свойства Value в аргументе события.

XAML прекрасно подходит для декларативной спецификации элементов

кое что все равно потребует

XAML прекрасно подходит для декларативной спецификации элементов, из которых состоит приложение, а также для установки их свойств, допускающих статическое определение. Кое-что все равно потребует написания программного кода, который можно либо ввести в сам XAML-файл в виде блоков сценария, либо разместить в отдельном файле, содержащем определение неполного класса, на который должен указывать атрибут Class Верхнего элемента в соответствующем XAML-файле. Последнее очень похоже на код поддержки в ASP. NET, и для Visual Studio является предпочтительной моделью. Чтобы объявить в XAML класс приложения, можно написать следующее: Если имеется XAML-файл с элементом Application, То во время выполнения будет создан экземпляр класса приложения. В данном случае элемент Application Специфицирует, что его именем класса является DataBindinglOl .МуАрр, Который будет создаваться как неполный класс. Пространства имен определяют схемы, используемые в разметке XAML, а атрибут StartingUp Позволяет подключить обработчик для события, специфицируя имя метода в вашем классе приложения, который будет обрабатывать это событие. Элемент Application.Resources Является контейнером для ресурсов области приложения, которые вы можете определять в своем файле. В этом разделе могут определяться статические данные, установки конфигурации, стили и другие элементы, которые будут доступны для любых дочерних элементов приложения. Код поддержки для приложения помещается в файл с именем Му — App. xaml. cs, хотя его можно назвать и произвольно, и содержит определение неполного класса, код которого присоединяется к классу приложения, определяемого в XAML: Как и в коде XAML класса приложения, здесь объявляется корневой элемент Window И идентифицируется имя класса с помощью атрибутаClass. Далее событие Loaded Связывается с методом WindowLoaded, С помощью атрибута Text Задается текст в строке заголовка, и устанавливаются свойства Width И Height, Задающие размер окна.

Интерфейс IList: привязка данных

это один из важнейших интерфейсов

Интерфейс IList Позволяет вам рассматривать коллекцию как упорядоченное индексируемое множество элементов данных. Это один из важнейших интерфейсов в привязке данных, поскольку сложные элементы управления с привязкой к данным могут быть привязаны только к коллекциям, реализующим IList. Используя ссылку интерфейса IList На коллекцию, вы можете управлять ее данными, добавляя, удаляя, вставляя и обращаясь к ее элементам. Интерфейс IList Является ключевым интерфейсом, обеспечивающим привязку времени выполнения к большинству элементов управления Windows. Он производится от ICollection, Поэтому для поддержки IList Вам нужно реализовать также ICollection И LEnumerable. IList Определяет набор элементов, которые далее определяют коллекцию как упорядоченную индексируемую коллекцию данных, к которым можно обращаться в произвольном порядке. Рад сообщить, что в приложениях. NET 2.0 вам никогда не придется реализовывать интерфейс IList Самостоятельно, поскольку обобщенный тип List<T> Предусматривает его полную реализацию для любого типа, который вы захотите содержать в коллекции. Однако вам, возможно, будет необходимо потреблять этот интерфейс, чтобы использовать коллекцию в своем прикладном коде или в специальном привязанном элементе управления. Элементы интерфейса описываются в таблицах 7.4 и 7.5 и далее в тексте.

Интерфейс IList добавляет к коллекции методы и свойства, которые придают ей все черты развитой, редактируемой и модифицируемой коллекции данных с произвольным доступом. Как говорилось ранее, привязка данных в Windows Forms является двусторонней — многие элементы управления поддерживают не только представление данных для просмотра, но позволяют также пользователю редактировать данные в элементе управления, что приводит к обновлению нижележащего источника данных. Согласно утверждениям модели Windows Forms для элементов управления, можно в любой момент обратиться через привязанный элемент управления к любому элементу в коллекции, поэтому становится важен прямой доступ к содержимому коллекции.