Разберем ситуацию, с которой сталкиваются многие разработчики при работе с Управляемыми формами: при активации строки в динамическом списке платформа 1С автоматически прокручивает его так, чтобы выбранная строка оказалась в центре видимой области. Это поведение часто мешает пользователям, особенно если на форме размещено несколько взаимосвязанных списков. Давайте выясним, почему это происходит и как мы можем оптимизировать работу интерфейса.
Основная причина «прыжков» заключается в механизме перерисовки формы. Когда вы активируете строку в списке, в коде часто срабатывает обработчик ПриАктивизацииСтроки. Если внутри этого обработчика происходит изменение свойств элементов управления, которые влияют на геометрию формы (например, обновление отборов других списков, изменение заголовков надписей или видимости элементов), платформа вынуждена выполнить пересчет компоновки всего окна.
В процессе пересчета платформа пытается восстановить контекст пользователя, возвращая фокус и видимость текущей строки в поле зрения. Зачастую алгоритм делает это максимально «надежно», принудительно центрируя активный элемент. Если форма перерисовывается слишком часто (при каждом клике), пользователь видит постоянное подергивание содержимого.
Для минимизации этого эффекта рассмотрим несколько подходов, которые мы можем применить в разработке.
Самая частая ошибка — это выполнение «тяжелых» операций непосредственно в обработчике активации строки. Если при каждом клике вы меняете отбор у пяти других списков на форме, платформа будет перерисовывать каждый из них. Мы рекомендуем:
Оповестить и ОбработкаОповещения для передачи данных между независимыми частями интерфейса, если это возможно.Чтобы избежать мгновенной перерисовки всей формы в момент клика, мы можем использовать механизм отложенного обновления. Это позволит пользователю быстро переключаться между строками, не вызывая немедленной реакции системы. Рассмотрим пример реализации:
&НаКлиенте
Процедура СписокПриАктивизацииСтроки(Элемент)
// Подключаем ожидание с короткой задержкой
ПодключитьОбработчикОжидания("ОбработкаОжидания", 0.2, Истина);
КонецПроцедуры
&НаКлиенте
Процедура ОбработкаОжидания()
Если Элементы.Список.ТекущаяСтрока <> Неопределено Тогда
// Выполняем обновление только после короткой паузы
ОбновитьПараметрыПодчиненныхНаСервере(Элементы.Список.ТекущаяСтрока);
КонецЕсли;
КонецПроцедуры
Данный метод полезен тем, что если пользователь быстро прокручивает список, серверные вызовы не будут накапливаться — сработает только последнее обновление.
Если на одной форме расположено множество связанных списков, они неизбежно влияют на общую производительность и поведение интерфейса. Проанализируем ситуацию: если поведение остается непредсказуемым, оптимальным решением будет вынос зависимых списков в отдельные формы или использование Динамического списка с параметрами, которые обновляются только при явном требовании, а не при простом проходе по списку.
Проверьте, нет ли в вашем коде прямого вызова ЭтаФорма.Обновить() или Элементы.Список.Обновить() внутри обработчиков активации. Этот метод принудительно перестраивает форму, что гарантированно приводит к потере текущей позиции прокрутки. Старайтесь манипулировать только данными через Параметры запроса динамического списка.
Также важно убедиться, что обновление заголовков надписей или других декоративных элементов не происходит избыточно. Как было замечено коллегами, даже изменение текста простой надписи может вызвать перерисовку всей формы, если она жестко привязана к обновлению основного Динамического списка.
Таким образом, мы видим, что «прыгающий» список — это не баг, а реакция системы на изменение геометрии формы. Решая задачу через отложенное выполнение и правильное проектирование связей между элементами, мы сможем добиться плавного и удобного интерфейса для наших пользователей.