4. Привязка объектов контроля к источникам данных

Реализация специальных рабочих объектов и коллекций для привязки данных

одна из них та что

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

Уведомление потребителей об изменениях в коллекции

чтобы об этом сообщить коллекция

Если коллекция поддерживает изменения, она также должна поддерживать запуск события ListChanged При изменении коллекции. Чтобы об этом сообщить, коллекция должна возвращать True В свойстве Sup — PortsChangeNotification. Сама коллекция должна возбуждать события ListChanged, Когда элементы добавляются или удаляются из коллекции. В идеале она должна была бы посылать уведомления ListChanged При изменении существующих элементов в коллекции из-за модификации их свойств. Однако способность коллекции делать это будет диктоваться тем, как изменяются свойства и какую поддержку предусматривают для этого содержащиеся объектные типы. Как уже упоминалось, если изменения производятся посредством метода SetValue Дескриптора свойства, контейнер может вызвать метод AddVa — LueChanged Дескриптора и передать возвратно-вызываемый делегат, чтобы контейнер получал уведомления при изменении свойства. В ответ на уведомление от дескриптора об изменении свойства он может затем возбудить событие ListChanged. Это в точности то, что должна делать реализация интерфейса IRaiseltemChangedEvents, Обсуждаемого в одном из последующих разделов. Однако если свойство было изменено непосредственно его установщиком, вызванным через ссылку на объект, у коллекции нет способа узнать об изменении, если только сам объект не уведомит коллекцию. Последняя возможность обеспечивается интерфейсом INotifyProper — TyChanged. Другой формой изменения, которую может поддерживать коллекция, является динамическое изменение схемы, когда к элементам коллекции во время исполнения или проектирования добавляются новые свойства. Событие ListChanged Через свои аргументы события поддерживает уведомления и о таких изменениях. Событие ListChanged имеет тип ListChangedEventHandler, который сопровождается аргументом события типа ListChangedEventArgs. Его свойства, перечисленные в таблице 7.11, сообщают более подробную информацию об изменениях в списке. Запуск программы дает следующий результат: Из вывода программы вы можете видеть, что удаление элементов передает индекс удаленного элемента в свойстве Newlndex Аргументов события; для нового столбца возвращается дескриптор свойства, описывающий этот столбец; а когда изменяется элемент коллекции, наряду с его индексом возвращается дескриптор свойства, описывающий изменившееся свойство.

Резюме виртуального режима

если нужна поддержка редактирования значений

Вот и все, что нужно знать о виртуальном режиме: вы устанавливаете свойство VirtualMode В True, Создаете необходимые вам столбцы и строки, а затем предоставляете обработчик для события CellValueNeeded, Который устанавливает соответствующее значение для отображаемой ячейки. Если нужна поддержка редактирования значений непосредственно в сетке, то дополнительно обрабатываете событие CellValuePushed И производите все необходимые действия с модифицированными значениями по мере того, как пользователь вносит свои изменения. Надеюсь, вам не придется в своих приложениях часто прибегать к виртуальному режиму, но возможность получать «на ходу» значения для отображения очень больших коллекций данных или вычисляемых столбцов весьма привлекательна. Не существует строгих и твердых правил относительно того, когда нужен виртуальный режим. Если в вашем приложении возникают проблемы с прокруткой, или вы хотите избежать затрат памяти на хранение вычисленных значений для большого числа строк, следует посмотреть, не решит ли эти проблемы виртуальный режим. Однако вам еще придется подумать о стратегии извлечения и кэширования данных, чтобы избежать серьезного затормаживания приложения на машине клиента. Если не установлено истинным свойство сетки Readonly, А тип ячеек допускает редактирование, то пользователь может щелкнуть на ячейке, подумать, а затем щелкнуть на ней еще раз, чтобы перевести ячейку в режим редактирования. После того как пользователь изменит значение, и фокус ввода, в результате действий с мышью или клавиатурой, перейдет на другую ячейку или другой элемент управления, для этой ячейки будет запущено событие CellValuePushed. В обработчике для этого события вы можете забрать из ячейки новое значение и сделать с ним все, что нужно, например, записать его обратно в свой кэш или в хранилище данных.

Data Grid View Text Box Column

b данные привязанные столбцу этого

Это тип столбца по умолчанию, и он отображает текст в содержащихся ячейках, которые имеют тип DataGridViewTextBoxCell. Данные, привязанные столбцу этого типа, и устанавливаемые в ячейках значения должны принадлежать к типу, допускающему преобразование в строку. Базовым классом, от которого производятся встроенные типы столбцов, является DataGridViewColumn . В этом классе также имеется ряд полезных свойств, которые наследуются специфическими встроенными классами столбцов и посредством которых вы можете управлять поведением сетки. Эти свойства описываются в Имеется несколько встроенных типов столбцов, которые можно использовать для элемента управления DataGridView И которые соответствуют распространенным элементам управления, наиболее часто включаемым разработчиками В Сетку. Следующие подразделы описывают каждый из встроенных типов столбцов и то, что нужно знать при работе с ними. Этот тип столбца поддерживает редактирование, если свойство Readonly Равно False и фокус ввода направлен на ячейку столбца. Для входа в режим редактирования нажмите F2, введите символы и нажмите Enter. При этом в ячейку встраивается отдельный элемент управления типа DataGridViewTextBoxEditingControl, Являющегося производным от DataGridViewTextBoxCell. Этот тип допускает редактирование значения в сетке «по месту», как в хорошо знакомых вам текстовых полях. Значение в текстовом поле создается как временное значение, существующее, пока фокус не покинет ячейку; тогда запускается событие Cell Parsing, И значение сбрасывается в нижележащее хранилище данных, если имеет место привязка, или запускается событие CellValueChanged, Если установлен виртуальный режим.

Расширенные верифицирующие элементы управления

плохо же в них то

В модели событий верификации и элементе управления ErrorProvider Хорошо то, что они просты и используются очевидным образом. Плохо же в них то, что для охвата всех элементов управления на сложной форме требуется масса отдельных обработчиков событий, и каждый из них должен содержать специальный код, который рассматривает верифицируемое значение и принимает решение о том, действительно ли оно и что с ним делать. Код верификации может делать что угодно, но в большинстве случаев он следует определенным моделям. Ниже перечислены четыре распространенных типа верификации, которые будут нужны вам чаще всего. Верификация требуемого ввода. Проверяет, что в специфический элемент управления было введено некоторое значение, не вынося на уровне UI никакого суждения о том, корректно ли это значение. Верификация диапазона ввода. Проверяет, попадает ли введенное значение в диапазон приемлемых значений. Верификация сравнения ввода. Сравнивает значения в двух или нескольких входных элементах управления и убеждается, что все они имеют одинаковое значение. Верификация шаблона ввода. Проверяет, что ввод соответствует некоторому текстовому шаблону, например, что номер социального страхования или номер телефона имеет дефисы в нужных местах, что строка набрана в соответствующем регистре или имеет нужную длину и т. д. Вы можете легко выполнить подобную проверку, воспользовавшись возможностями регулярных выражений.