Часто разработчики сталкиваются с ситуацией, когда ДинамическийСписок с произвольным запросом работает в консоли запросов или толстом клиенте корректно, но в тонком клиенте часть записей, удовлетворяющих условиям, загадочным образом исчезает. Обычно это проявляется как «пропадание» строк, содержащих определенные значения (например, ИСТИНА в булевом поле).
Давайте разберем, почему так происходит и как эффективно устранить эту проблему, не прибегая к радикальным методам вроде полной очистки кэша на всех клиентских машинах.
Основная причина такого поведения кроется в механизме сохранения настроек динамического списка. Платформа 1С:Предприятие 8 автоматически сохраняет настройки формы (отборы, сортировки, порядок колонок) в системных хранилищах. Если форма динамического списка уже была открыта пользователем ранее, платформа запоминает его предпочтения.
Когда вы вносите изменения в запрос, добавляете новые поля или меняете логику отображения, старые настройки (которые могут содержать «скрытый» отбор или специфическую сортировку) могут вступить в конфликт с новой структурой списка. В тонком клиенте этот механизм работает особенно агрессивно, так как он активно использует кэширование метаданных и настроек на стороне клиента.
Прежде чем приступать к коду, давайте выясним, действительно ли в списке «сидят» старые настройки. Вы можете использовать отладчик, чтобы посмотреть состояние КомпоновщикНастроек вашего списка.
При открытии формы обратите внимание на свойство:
Список.КомпоновщикНастроек.Настройки.Отбор
Если вы обнаружите там элементы, которые вы не добавляли программно, значит, платформа подгрузила их из хранилища. Это самый верный признак того, что проблема именно в сохраненных параметрах.
Если вы хотите гарантировать, что форма всегда открывается «чистой», без учета прошлых манипуляций пользователя, самым надежным способом является программный сброс ИдентификаторПользовательскойНастройки. Это заставляет компоновщик настроек игнорировать старые записи в хранилище.
Реализуйте сброс в обработчике ПриСозданииНаСервере формы:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Сбрасываем идентификатор, чтобы не подтягивались старые настройки отбора
Список.КомпоновщикНастроек.Настройки.Отбор.ИдентификаторПользовательскойНастройки = "";
КонецПроцедуры
После этого действия платформа создаст новый «чистый» контекст настроек для данного списка, и все строки, которые до этого не отображались из-за скрытых отборов, должны появиться.
Если сброс настроек не помог или проблема носит специфический характер, рассмотрим дополнительные инструменты диагностики:
УсловноеОформление в настройках списка — не задано ли там скрытие строк по условию, например, для поля Открыт.Открыт является вычисляемым (например, через ВЫБОР КОГДА ... ИНАЧЕ ... КОНЕЦ), убедитесь, что результат выражения явно приводится к типу БУЛЕВО с помощью функции ВЫРАЗИТЬ. Некорректная типизация может приводить к тому, что SQL-сервер неверно интерпретирует условие отбора.ЛЕВОЕ СОЕДИНЕНИЕ).ХранилищеОбщихНастроек.Удалить(...).Ситуация, когда динамический список ведет себя по-разному в разных клиентах, почти всегда указывает на то, что один из них использует «закешированные» настройки, а другой — нет. Использование ИдентификаторПользовательскойНастройки = "" — это «золотой стандарт» решения данной проблемы, позволяющий избежать конфликтов версий конфигурации и неожиданного поведения интерфейса.
В будущем, при проектировании сложных форм с динамическими списками, всегда учитывайте, что пользователь может случайно настроить отбор в интерфейсе, и этот отбор сохранится навсегда. Если логика вашего списка критически важна, принудительный сброс настроек при открытии формы — это правильная практика разработки.