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