Как очистить или полностью отключить выпадающий список истории ввода в 1С?

← На главную

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

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

Способ 1. Отключение истории выбора в свойствах элемента или реквизита

Самый простой и правильный путь, если история выбора мешает бизнес-логике — просто запретить платформе её использовать. Проанализируем, где именно это можно настроить.

Мы можем отключить историю двумя путями:

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

Важный нюанс по стандартам разработки интерфейсов 1С: Если мы просто отключим историю, у поля ввода останется кнопка выпадающего списка (стрелочка вниз). При ее нажатии пользователь увидит пустое меню и лишь кнопку "Показать все", что неудобно. Чтобы сделать интерфейс корректным, настроим элементы поля ввода следующим образом:

КнопкаВыпадающегоСписка = Нет
КнопкаВыбора = Да
ОтображениеКнопкиВыбора = ВПолеВвода

В результате стрелочка исчезнет, появится стандартная кнопка выбора (три точки), и при клике будет сразу открываться форма справочника или списка.

Способ 2. Программная очистка истории в хранилище системных настроек

Если мы хотим оставить механизм истории, но нам нужно ее сбросить (например, после массового обновления номенклатуры), мы воспользуемся объектом ХранилищеСистемныхНастроек. Разберем несколько вариантов очистки.

Чтобы удалить историю для всех пользователей без ограничений (сбросить кэш истории выбора для всей базы), используем следующий код. В этом случае мы обращаемся к ключу МеханизмСохраненияПоследнихВыбранныхЗначений и не передаем третьего параметра (имя пользователя):


// Удаляет у всех пользователей без ограничений
ХранилищеСистемныхНастроек.Удалить(, "МеханизмСохраненияПоследнихВыбранныхЗначений", );

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


&НаСервере
Процедура УдалитьИсториюВыбораПользователей()
    Выборка = Справочники.Пользователи.Выбрать();
    Пока Выборка.Следующий() Цикл
        // Ищем пользователя ИБ по уникальному идентификатору
        ПользовательИБ = ПользователиИнформационнойБазы.НайтиПоУникальномуИдентификатору(Выборка.ИдентификаторПользователяИБ);
        
        Если ПользовательИБ <> Неопределено Тогда
            // Очищаем историю выбора по имени пользователя ИБ
            ХранилищеСистемныхНастроек.Удалить("ИсторияВыбора", , ПользовательИБ.Имя);
        КонецЕсли;
    КонецЦикла;
КонецПроцедуры

Способ 3. Очистка кэшированного списка и программное переопределение при открытии

Иногда отключение истории выбора через конфигуратор или хранилище не дает мгновенного результата из-за жесткого кэширования в управляемых формах на стороне клиента. Рассмотрим альтернативный подход, который разработчики применяют принудительно при открытии формы документа или справочника.

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


&НаСервере
Процедура ОчиститьИсториюВвода()
    // Программно отключаем использование истории
    Элементы.СтрокаПоискаНоменклатуры.ИсторияВыбораПриВводе = ИсторияВыбораПриВводе.НеИспользовать;
    
    // Очищаем сам список, хранящийся в кэше элемента формы
    Элементы.СтрокаПоискаНоменклатуры.СписокВыбора.Очистить();
    
    // При необходимости сохраняем пустой список для текущего ключа настроек
    СпискиВыбораКлиентСервер.Сохранить("ИсторияПоискаНоменклатуры", Элементы.СтрокаПоискаНоменклатуры.СписокВыбора);
КонецПроцедуры

Важные нюансы и подводные камни механизма истории выбора

Рассмотрим несколько скрытых особенностей работы механизма платформы, о которых важно помнить:

1. Игнорирование программных отборов и RLS: Механизм истории выбора использует кэшированные данные. Он абсолютно не учитывает динамические отборы, которые вы могли установить на форме, а также код в процедуре ОбработкаПолученияДанныхВыбора модуля менеджера. То есть, если вы программно ограничили выбор только товарами в наличии, в истории пользователь всё равно увидит ранее выбранный "отсутствующий" товар. Именно поэтому золотое правило: если на поле накладываются сложные фильтры, стандартную историю нужно обязательно отключать.

2. Увеличение количества записей в истории: Штатными средствами 1С (настройками или кодом) увеличить лимит сохраняемых значений (обычно это 5 последних элементов) нельзя. Если требуется выводить 10-15 частых значений, стандартную историю отключают полностью. Вместо неё программируют заполнение свойства СписокВыбора элемента формы при событии НачалоВыбораИзСписка.

3. Перехват события выбора из истории: Платформа не предоставляет отдельного события для клика именно по элементу истории. При выборе элемента из кэша срабатывают стандартные события: сначала ОбработкаВыбора, а затем ПриИзменении. Всю логику проверок (например, на статус документа) необходимо помещать в ОбработкаВыбора, тогда она гарантированно сработает и при подборе из формы, и при клике на элемент из истории.