Основы создания быстрых форм
Единственной серьезной проблемой, значительно влияющей на производительность при использовании форм, является количество и тип элементов управления. Каждый элемент управления поглощает память и ресурсы, одни — больше, другие — меньше. Образно говоря, связанный фрейм объекта "весит" примерно в 40 раз больше, чем линия. Элемент управления ActiveX может быть еще "увесистее" в зависимости от того, из чего он состоит и какие действия выполняет.
При выборе элементов управления для данной формы следует учитывать сведения, представленные в табл. 3. Необходимо помнить о том, что чем большей функциональностью обладает элемент управления, тем больше он поглощает ресурсов. В следующей таблице приведен список элементов управления, содержащихся в панели элементов конструктора форм. Подсчет имеющихся свойств каждого элемента управления и сравнение этого числа со сложностью задачи, решаемой каждым элементом управления, позволяет составить таблицу относительного "веса" элемента. Конечно же значения, приведенные в таблице, можно использовать лишь в качестве опорных. На самом деле использование ресурсов элементами форм зависит от их назначения.
Таблица 3. Относительный "вес" элементов форм.
| Тип элемента управления | Относительный "вес" | ||
| Прямоугольник | 1 | ||
| Линия | 1 | ||
| Разрыв страницы | 1 | ||
| Вкладка (не включая собственные элементы управления) | 4 | ||
| Фрейм изображения (не включая само изображение) | 6 | ||
| Элемент управления вкладки | 6 | ||
| Подчиненная форма (как минимум) | 6 | ||
| Метка | 8 | ||
| Кнопка опции | 8 | ||
| Кнопка команды | 8 | ||
| Флажок | 8 | ||
| Группа опций (не включая собственные элементы управления) | 8 | ||
| Кнопка переключения | 9 | ||
| Текстовое поле | 10 | ||
| Список (как минимум) | 10 | ||
| Поле со списком (как минимум) | 20 | ||
| Элементы управления ActiveX | >= 20 | ||
| Объектный фрейм (не включая само изображение) | 30 | ||
| Связанный объектный фрейм (не включая само изображение) | 40 |
Некоторые элементы управления на несколько порядков "тяжелее", чем другие, поэтому для оптимизации полезно пользоваться подстановкой. Бывает много случаев, когда список может заменяться полем со списком или подчиненной формой. Изображения могут часто использовать элемент изображения вместо фрейма, а элемент вкладки может помочь разделить форму на быстро загружающиеся части, поскольку визуализируются только те элементы управления, которые находятся на текущей отображаемой странице. Учитывая, что в последнее время пользователи привыкли к гипертекстовым ссылкам в Internet, можно попробовать заменить командные кнопки гиперссылками. Если имеется возможность использовать элемент управления с меньшим "весом" без ущерба для функциональности, следует воспользоваться данной возможностью.
Ниже приводятся несколько советов, которые помогут повысить быстродействие элементов управления:
• Рекомендуется ограничивать количество полей, отображаемых в списках и свести к минимуму число полей со списками. Кроме того, необходимо индексировать поля поиска и отображаемые поля. Следует отключить опцию AutoExpand для полей со списками, установив ее в значение No. Если Access реагирует на каждый введенный символ, производительность значительно падает. Данную опцию следует использовать только тогда, когда избежать этого невозможно. Если необходимо использовать опцию AutoExpand,
нужно убедиться, что поле, в котором пользователь вводит символы, является полем текстового типа. Access может использовать функцию AutoExpand только с текстовыми данными. Если данные не являются текстовыми. Access вынужден затратить некоторое время на преобразование данных и записей.
• При необходимости скрыть поле, связанное с полем со списком, следует избегать использования выражений в этом поле или в отображаемых полях. Поле со списком не отображает результаты так быстро, как будто они были подсчитаны заранее и считаны из таблицы.
• Следует избегать использования ограниченных запросов в качестве основы для полей со списками или списков. Можно попытаться взять за основу единственную таблицу. Если разработчику удастся создать таблицу с помощью запроса и воссоздавать ее по мере необходимости, производительность должна быть намного выше.
• При обновлении форм или любых элементов управления, которые отображают изменившиеся данные, рекомендуется применять метод Requery,
работающий гораздо быстрее, чем макрос Rcquery Action. Данный метод можно использовать после выполнения удалений, особенно в многопользовательском приложении.
• Вместо использования одного большого и длинного поля со списком следует проверить, не сможет ли форма вместить несколько полей со списками, которые являются взаимно ограничивающими. Например, одно поле со списком служит для выбора регионов. Данный выбор ограничивает содержание второго поля со списком только городами в выбранном регионе. Такой подход гораздо быстрее и эффективнее, чем прокрутка одного поля со списком со всеми регионами и городами.
• Следует экономно обращаться не только с количеством и типами элементов управления, размещаемых в форме, но и с количеством полей, представленных в наборах записей форм. Хотя из таблицы формы всегда загружают данные быстрее, чем из запроса, здесь есть и обратная сторона. При открытии формы, основанной на таблице, загружаются все поля таблицы, даже если форма их не отображает. Бывают случаи, когда лучше открыть форму с помощью запроса, чтобы исключить ненужные поля из набора записей.
• Сортировку базового набора записей форм следует производить лишь в крайнем случае. Процесс пересортировки записей, по времени совпадающий с конфигурированием формы для отображения, может значительно замедлить открытие формы.
• При создании кода для формы (CBF) используйте ключевое слово Me.
Эта константа всегда ссылается на активную форму и работает быстрее, чем другие ссылки.
• Рекомендуется индексировать поля Link Child и Link Master конструкции главная форма/подчиненная форма. Это позволит значительно ускорить выборку, которая часто производится данными формами.
• Если пользователь не собирается редактировать записи подчиненной формы, необходимо соответствующим образом установить свойства подчиненной формы. Свойства AllowEdits, AllowAppend и AllowDeletes
оказывают значительное влияние на производительность, поскольку они реализуют функциональные свойства формы. Можно получить выигрыш в скорости, если избавиться от ненужных свойств. Точно так же можно получить выигрыш в скорости, если выбрать только нужные свойства. Если форма открывается для записи данных, необходимо установить ее свойства DataEntry в значение
Yes, чтобы избежать ненужного считывания записи.
• Следует строго относиться к установке свойств форм и элементов управления во время выполнения. Данные свойства следует устанавливать только при необходимости и только в том случае, если это не вредит производительности.
• В каждом конкретном случае рекомендуется проверять, что работает быстрее — динамическое множество или простой снимок.
• Так же, как при сокрытии элементов управления с помощью разрывов страниц и вкладок, можно получить выигрыш в скорости за счет сокрытия форм. Неплохой практикой является невидимая загрузка нескольких из наиболее общих форм приложения. Такая возможность может появиться при запуске или при первом обращении к форме. Для невидимой загрузки формы ее необходимо открыть путем установки параметра WindowMode в значение
acHidden:
DoCmd.OpenForm "имя_формы",,,,,acHidden
• Когда понадобится отобразить форму для пользователя, следует воспользоваться такой командой:
Forms("имя_формы").setfocus
• На тот случай, если пользователю снова понадобится форма, вместо того чтобы закрывать, ее сле-'дует скрыть. Метод Hide уберет форму с экрана, но при этом сохранит ее в памяти.
Formobject.Hide
• Избегая загрузки запросов, загрузки форм и этапов визуализации элементов управления, можно значительно повысить производительность интерфейса. Недостатки такого подхода заключаются в том, что скрытые формы требовательны к памяти и это может отрицательным образом сказаться на других модулях приложения. Хотя данную методику нельзя использовать для всех форм в приложении, ее рекомендуется применять для часто используемых форм.
Работая с очень большими наборами записей, не следует пытаться представить пользователю все записи за один раз. В любом случае большинство пользователей не знает, что делать с десятками тысяч записей, отображенными одновременно. Но если пользователи работают с многопользовательским приложением и форма открывает набор записей из больших таблиц или запросов, производительность падает по причине заторов в сети, ограничений кэша, блокировок записей и страниц и других перегрузок. Лучше всего отыскать логический способ, позволяющий разбить данные на логические подмножества с определенными ограничениями. Еще лучше отображать для пользователя только одну запись в определенный момент времени, запрашивая начальное значение записи или индекс поля. В небольших приложениях такой подход может привести к снижению производительности, но в больших многопользовательских системах это единственный выход. Для реализации такого решения необходимо переписать SQL-опсратор в коде, программно меняя свойство формы Record Source и многократно запрашивая форму.
