|
Навороченные формы с огромным количеством визуальных компонентов, помноженные
на количество этих форм, могут вызвать ряд серьезных проблем при разработке и
использовании программы.
- Приложение надолго подвисает при загрузке. Время уходит на инициализацию
большого количества форм, стоящих в AutoCreate.
- Наблюдаются многочисленные глюки при прорисовке, сообщения системы об
ошибках и перерасходе ресурсов без видимых причин, вплоть до убиения приложения
системой или краха системы. Характерно для Windows линии 9X, у которых
максимальное количество графических и оконных ресурсов (GDI и USER) сильно
ограничено.
- Зачастую, чтобы не расставлять и настраивать множество однообразных
контролов на форме вручную, программист пишет код для их программной
инициализации и вставки, не учитывая при этом нюансы, о которых он не подозревал
при визуальной разработке. В результате он может получить утечку памяти и прочих
ресурсов, если форма создается/уничтожается динамически многократно в процессе
работы.
- Пользователь теряется в перегруженном интерфейсе программы, будучи не в
состоянии использовать все его возможности и затрудняясь в выполнении простых
задач.
ТИПОВЫЕ РЕШЕНИЯ.
- Уменьшить количество автоматически создаваемых форм. Создавать тяжелые формы
в тот момент, когда они понадобятся, и уничтожать при закрытии. При этом нужно
следить за своевременной очисткой и проверкой глобальных ссылок на формы.
- У динамически создаваемых компонентов устанавливать владельца и родителя.
Подробности - в статье "Жизнь и смерть
в режиме run-time".
- Большое количество форм не всегда оправдано. Если пользователь не получает
дополнительных удобств от того, что может открыть много форм (часто он не может
их увидеть одновременно или работает постоянно с одной), то это неверное
архитектурное решение.
Интерфейс MDI - хорошая концепция. Но всякое
техническое решение имеет свою область применения. Это удобно, когда
пользователю нужно работать с однотипными объектами в разных окнах и переходить
от одного к другому, причем количество их заранее неизвестно, и допускается
изменение размеров окна. Примеры - работа с документами (Word, Excel, etc.).
- Как правило, многочисленные элементы управления не нужны пользователю
одновременно (вспомните о правиле 7±2 - именно таково среднее количество
объектов, за которыми человек может следить одновременно, не напрягаясь). Их
можно разделить на группы и расположить на страницах компонента TPageControl.
Таким способом можно скрыть видимую сложность очень большого интерфейса по вводу
и редактированию данных.
Если группы компонентов однотипны (меняются только
данные), то решение еще более упрощается, с одновременным снятием нагрузки на
ресурсы системы. Компонент TTabControl, который внешне выглядит также, как и
TPageControl, содержит только одну группу контролов, а программист по событию
смены закладки OnChange имеет возможность сменить данные.
- Большое количество регулярно расположенных контролов TEdit, TLabel успешно
заменяется на TStringGrid, специально для этого предназначенный. Кроме всего
прочего, он имеет удобную прокрутку, размеры таблицы не будут ограничены
размерами формы.
В случае, если нужно много TComboBox, применяют следующую
хитрость. Для визуализации используют TStringGrid, а для редактирования в
текущую ячейку вставляют TComboBox, устанавливая ему размеры и координаты по
ячейке и набивая его программно (если набор элементов меняется). Один и тот же
экземпляр редактирующего контрола используется во всех ячейках, поскольку он не
нужен одновременно везде. Эта же техника используется и в VCL для редактирования
ячеек TStringGrid, TDBGrid.
Есть масса компонентов типа TStringGrid сторонних
разработчиков, которые расширяют возможности стандартного.
- DB-aware визуальные компоненты - такие как TDBGrid - способны обрабатывать
огромный объем данных, не требуя при этом пропорциональное количество ресурсов
GDI/USER. В конце концов, если не хочется связываться с СУБД, можно загнать
информацию в TClientDataSet и кормить из него DB-aware controls на форме.
Одновременно получаешь все прелести сортировки и фильтрации данных.
В случае
сложного набора контролов для каждой записи, при необходимости видеть несколько
таких групп одновременно, хорошо подходит компонент TDBCtrlGrid.
- Следует стремиться уменьшить количество компонентов - потомков TWinControl
(например - TButton), заменяя их на потомки TGraphicControl (пример -
TSpeedButton). Последние не используют объекты USER, поскольку не являются
окнами в понятиях Windows.
- Рекомендуется разрабатывать и эксплуатировать ресурсоемкие приложения в
среде Windows NT и ее наследников (2000, XP).
Ресурсы:
GridComb.zip - пример
манипулирования ComboBox на StringGrid (выловлено в FIDO в незапамятные
времена).
Torry's Delphi pages - сюда
ходят за компонентами.
|
GUI. Перегрузка контролами