Как ограничить ввод по строке в обычном приложении, сохранив функционал в управляемых формах?

← На главную

При работе в гибридных конфигурациях, где одновременно используются обычные и управляемые формы, часто возникает задача: ограничить или полностью отключить ввод по строке в обычном приложении, сохранив при этом удобный поиск для пользователей управляемого интерфейса. Проблема усложняется, когда объектов (например, справочник «Номенклатура») сотни, и ручная правка каждой формы невозможна. В этой статье мы разберем элегантный способ решения этой задачи через метаданные и программные механизмы платформы 1С.

Анализ стандартного механизма ввода по строке

Стандартно платформа 1С использует список полей, указанных в свойстве метаданных Ввод по строке, для организации быстрого поиска. Если в этом списке указаны «Наименование» и «Код», то при наборе текста в поле ввода система автоматически пытается найти подходящие элементы. Этот механизм работает глобально: и в обычных, и в управляемых формах.

Однако поведение платформы при «пустом» списке полей различается:

В обычных формах: если поля не указаны, ввод по строке просто перестает работать.
В управляемых формах: если поля не указаны, стандартный поиск отключается, но платформа дает нам «крючок» в виде события в модуле менеджера объекта.

Решение 1: Очистка метаданных и программная реализация в модуле менеджера

Этот метод является наиболее правильным с точки зрения архитектуры 1С 8.3. Проанализируем его по шагам.

Шаг 1. Настройка метаданных. Нам необходимо зайти в свойства справочника (например, «Номенклатура») и полностью очистить список полей в свойстве Ввод по строке. С этого момента в обычном приложении ввод текста в поле номенклатуры перестанет приводить к автоматическому подбору. Это именно то, чего мы добивались для старого интерфейса, не внося изменений в сотни форм.

Шаг 2. Реализация логики для управляемых форм. Чтобы пользователи управляемых форм не потеряли возможность подбора, мы воспользуемся обработчиком ОбработкаПолученияДанныхВыбора в модуле менеджера объекта. Рассмотрим пример кода, который возвращает возможность поиска:


Процедура ОбработкаПолученияДанныхВыбора(ДанныеВыбора, Параметры, СтандартнаяОбработка)
    
    // Если нам нужно реализовать свой поиск только для управляемого приложения
    СтандартнаяОбработка = Ложь;
    
    // Формируем запрос для поиска подходящих элементов
    Запрос = Новый Запрос;
    Запрос.Текст = 
        "ВЫБРАТЬ РАЗРЕШЕННЫЕ ПЕРВЫЕ 20
        |	Номенклатура.Ссылка КАК Ссылка,
        |	Номенклатура.Наименование КАК Наименование
        |ИЗ
        |	Справочник.Номенклатура КАК Номенклатура
        |ГДЕ
        |	Номенклатура.Наименование ПОДОБНО &ТекстПоиска
        |	И НЕ Номенклатура.ЭтоГруппа";
    
    Запрос.УстановитьПараметр("ТекстПоиска", "%" + Параметры.СтрокаПоиска + "%");
    
    РезультатЗапроса = Запрос.Выполнить();
    ТаблицаРезультатов = РезультатЗапроса.Выгрузить();
    
    СписокВыбора = Новый СписокЗначений;
    Для Каждого Строка Из ТаблицаРезультатов Цикл
        СписокВыбора.Добавить(Строка.Ссылка, Строка.Наименование);
    КонецЦикла;
    
    ДанныеВыбора = СписокВыбора;

КонецПроцедуры

Важно понимать: обычное приложение не вызывает этот обработчик при вводе текста в поле. Таким образом, мы получаем разделение: в обычном приложении ввод по строке «молчит», а в управляемом — работает по нашему алгоритму.

Решение 2: Использование RLS для глобальных ограничений

Если задача стоит шире — не просто отключить ввод по строке, а жестко ограничить список доступной номенклатуры (например, запретить видеть архивные позиции) во всех списках и полях ввода сразу, — следует рассмотреть механизм RLS (Record Level Security).

Проанализируем преимущества этого подхода:

Глобальность: ограничение накладывается на уровне СУБД. Ни в списках, ни в подборах, ни при вводе по строке лишние данные не появятся.
Независимость от типа форм: RLS одинаково эффективно работает как для обычных, так и для управляемых форм.
Отсутствие дублирования кода: вам не нужно прописывать условия фильтрации в каждом программном модуле.

Однако помните, что RLS может существенно снизить производительность системы при работе с большими справочниками, поэтому используйте его осмотрительно, накладывая условия на индексированные поля.

Решение 3: Массовая модификация форм (для продвинутых пользователей)

Рассмотрим ситуацию, когда вам все же нужно изменить поведение полей ввода в обычных формах, но вы не хотите открывать каждую форму вручную. В 1С существует возможность выгрузки конфигурации в файлы XML.

Алгоритм действий может быть следующим:

Выгружаем конфигурацию в файлы.
Используем скрипт или специализированную обработку для поиска всех элементов типа InputField, связанных с номенклатурой.
Программно добавляем им обработчик события НачалоВыбора или АвтоПодборТекста, указывая общую процедуру из общего модуля.
Загружаем конфигурацию обратно.

Этот путь сложнее, но он позволяет внедрить сложную логику (например, интерактивные вопросы пользователю) непосредственно в момент взаимодействия с полем ввода в обычном приложении.

Важные нюансы и выводы

Выясним причину, по которой простое отключение свойств в метаданных не всегда является панацеей. Стоит учитывать полнотекстовый поиск. Если он включен, то в некоторых интерфейсных решениях (особенно в управляемых формах) поиск может продолжать работать через механизмы глобального индекса платформы.

Подведем итог: наиболее стабильным и рекомендуемым способом разделения логики между типами приложений является комбинация очистки полей «Ввод по строке» в метаданных и реализация метода «ОбработкаПолученияДанныхВыбора» в модуле менеджера. Это дает полный контроль над данными, которые видит пользователь в управляемом интерфейсе, и гарантированно отключает лишний функционал в устаревшем обычном приложении без необходимости перелопачивать сотни старых форм.