Элементы управления Windows Forms и компоненты

Краткий путеводитель

Автор: Илья Рыженков Источник: RSDN Magazine #2-2004

Опубликовано: 16.10.2004 Исправлено: 13.03.2005 Версия текста: 1.0

Введение Disclaimer Проектируйте Сохраняйте гибкость Создание контрола Коллекции элементов Отрисовка Придерживайтесь стандартов Оптимизируйте Обработка действий пользователя Взаимодействие с мышью Взаимодействие с клавиатурой Поддержка дизайнера форм и редактора Поведение в режиме дизайна Использование атрибутов Коллекции Конверторы типов Расширение компонентов Улучшение компонента Локализация Источники данных Доступность Заключение Ссылки Приложения Конвертор типа

Введение

При создании программных продуктов на платформе .NET периодически приходится создавать специализированные версии компонентов и элементов управления, а то и совершенно новые «контролы». По этому поводу я составил для себя небольшой справочник или, если хотите, путеводитель по созданию компонентов, просто чтобы ничего при этом не забывать. Слово «контрол» впредь будет употребляться в данной статье вместо термина «элемент управления» по причине устоявшейся терминологии, а также для краткости изложения.

Disclaimer

Статья не претендует ни на подробное изложение процесса создания контролов, ни на сколько-нибудь серьезное описание компонентной технологии .NET. Это скорее некоторый набор в целом полезных утверждений, к которым, тем не менее, стоит относиться скептически и не забывать о реальных задачах и уместности применения того или иного принципа. Помните, что в тексте автор выражает собственную точку зрения, делится личным опытом и выводами, которые он сделал за время разработки компонентов и контролов. Эта статья не может рассматриваться ни как обощенный опыт RSDN, ни как какой бы то ни было стандарт разработки компонентов и контролов, ни даже как на 100% верный источник информации. Существует множество способов добиться одного и того же результата, и изложенный здесь вариант не обязательно является лучшим. Данная статья также не принимает во внимание тот факт, что зачастую экономически выгоднее приобрести готовый компонент или отыскать в сети бесплатный вариант.

Проектируйте

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

Спроектируйте структуру классов, которые будут использоваться для реализации контрола. Опишите специальные стили в виде перечислений (enum). Подготовьте список основных событий, о которых стоит оповещать пользователей вашего контрола. Создайте соответствующие делегаты и классы данных для них. Помните, что Windows Forms содержит довольно много классов, которые можно использовать повторно.

Составьте список основных вариантов использования (use cases) нового компонента или контрола. Опишите, как он будет реагировать на действия пользователя, какие состояния возможны и каковы переходы между ними. Это не только поможет не забыть реализовать то или иное поведение, но и будет хорошим подспорьем при тестировании функциональности – достаточно будет просто пробежаться по списку.

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

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

Для проверки соблюдения согласованности состояния вы можете создать метод VerifyConsistency(). Вызовы метода можно расставить везде, где изменяется внутреннее состояние компонента. Метод может проверить состояние объекта на согласованность и либо просто вернуть управление, либо сгенерировать исключение с описанием проблемы согласованности. Если снабдить этот метод атрибутом [Conditional(“DEBUG”)], то он будет вызываться только в debug-режиме, а в release-режиме компилятор не сгенерирует его вызов. Таким образом, вы не потеряете производительности при реальном использовании, а в случае проблемы при отладке получите её описание. Вы также можете создать собственную константу условной компиляции (например, “VERIFY”) и использовать её. Для этого откройте свойства проекта (Configuration Properties, Build) и в строке Conditional Compilation Constants добавьте свою константу.