Навороченные формы с огромным количеством визуальных компонентов, помноженные - Мои статьи - Каталог статей

Понедельник, 30.06.2025, 08:58

Приветствую Вас Гость | RSS

ПРЕКРАСНЫЙ И ЧАРУЮЩИЙ МИР МОДЫ

Навороченные формы с огромным количеством визуальных компонентов, помноженные

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

Приложение надолго подвисает при загрузке. Время уходит на большого инициализацию количества форм, стоящих в 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).