Воскресенье, 05.05.2024, 07:45 | RSS |
Главная
Улыбайтесь господа, улыбайтесь... (О. Янковский)
Главная
Меню сайта
Категории раздела
Мои статьи [633]
Обзоры [3]
Пишем все [92]
Статистика

Онлайн всего: 1
Гостей: 1
Пользователей: 0
Сегодня нет новостей
Комментарии: 2
Блог: 32
Новостей: 7
Статей: 728
Тесты без SMS: 55
Форма входа
Поиск по сайту
MainLink.RU

недвижимость в Черногории

Главная » Статьи » Мои статьи [ Добавить статью ]

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

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

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


  • Приложение надолго подвисает при Время загрузке. уходит на инициализацию
    большого количества форм, стоящих в 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).
  • Категория: Мои статьи | Добавил: master_rubaxa_Liex (03.09.2009)
    Просмотров: 932 | Рейтинг: 0.0/0
    Всего комментариев: 0
    Добавлять комментарии могут только зарегистрированные пользователи.
    [ Регистрация | Вход ]

    Copyright MyCorp © 2024
    Конструктор сайтов - uCoz