Главная страница

Зачем нужен

Кто придумал

Конструкция шкафа-купе

Двери открываются

Возможности современной мебели

Материалы для изготовления

Шкаф-купе и интерьер

Практические советы

Шкафы-купе KOMANDOR

Контакты

Дополнительная информация

Карта сайта
 

Компьютеры и периферия

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

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

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