Как отключить историю подбора в полях ввода номенклатуры в 1С?

Программист 1С v8.3 (Управляемые формы) 1С:Управление торговлей IT и автоматизация бизнеса
← На главную

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

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

Почему стандартная настройка «ИсторияВыбораПриВводе» часто не работает?

Казалось бы, платформа предоставляет штатный механизм управления историей. У каждого поля ввода на форме есть свойство ИсторияВыбораПриВводе. Однако установка этого свойства в значение «Не использовать» очень часто игнорируется системой. Выясним основные причины такого поведения:

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

Рассмотрим подробнее все возможные методы исправления этой ситуации.

Способ 1. Полное подавление истории через комбинацию свойств элемента в конфигураторе

Если перед нами стоит задача полностью исключить появление выпадающего списка истории и кнопки «Показать все» при активации поля ввода без написания кода, нам необходимо настроить строгую комбинацию свойств этого элемента управления. Откроем палитру свойств целевого поля ввода и установим следующие параметры:

  1. Найдем свойство ИсторияВыбораПриВводе и жестко укажем для него значение Не использовать.
  2. Переведем свойство КнопкаВыпадающегоСписка в положение Нет. Это уберет графическую стрелочку справа от поля, которая провоцирует открытие истории.
  3. Установим для свойства КнопкаВыбора значение Да.
  4. Для свойства ОтображениеКнопкиВыбора выберем вариант В поле ввода.
  5. Параметр БыстрыйВыбор переведем в значение Нет.

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

Способ 2. Программный обход через событие «ИзменениеТекстаРедактирования»

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

Для этого откроем форму подбора номенклатуры, выберем наше текстовое поле поиска и создадим для него обработчик события ИзменениеТекстаРедактирования на клиенте. Код будет выглядеть следующим образом:


&НаКлиенте
Процедура СтрокаПоискаНоменклатураИзменениеТекстаРедактирования(Элемент, Текст, СтандартнаяОбработка)
    
    // Отключаем стандартный алгоритм вывода истории платформой
    СтандартнаяОбработка = Ложь; 
    
КонецПроцедуры

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

Способ 3. Динамическое управление свойством в событии «АвтоПодбор»

Более элегантный и мягкий способ программного вмешательства заключается в динамическом переопределении настроек элемента управления непосредственно в момент активации автоподбора. Это позволяет сохранить стандартное поведение поиска, но гарантированно отключает вывод истории.

Создадим для элемента поиска обработчик события АвтоПодбор и пропишем в нем следующую логику:


&НаКлиенте
Процедура НоменклатураАвтоПодбор(Элемент, Текст, ДанныеВыбора, Параметры, Ожидание, СтандартнаяОбработка)
    
    // Принудительно отключаем использование истории в момент ввода текста
    Элемент.ИсторияВыбораПриВводе = ИсторияВыбораПриВводе.НеИспользовать;
    
КонецПроцедуры

Такое решение работает бесперебойно, так как свойство элемента переписывается динамически на клиенте непосредственно в момент обращения к механизмам автотекста платформы.

Способ 4. Программная очистка сохраненных настроек истории в базе данных

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

Мы можем написать простую обработку или добавить код при начале работы системы для полной очистки этих записей.

Вариант очистки истории для текущего сеанса пользователя:


ТекущийПользователь = ПользователиИнформационнойБазы.ТекущийПользователь();
ХранилищеСистемныхНастроек.Удалить("ИсторияВыбора", , ТекущийПользователь.Имя);

Вариант массовой очистки истории для абсолютно всех пользователей информационной базы:


ПользователиИБ = ПользователиИнформационнойБазы.ПолучитьПользователей();
Для Каждого ПользовательИБ Из ПользователиИБ Цикл
    Попытка
        ХранилищеСистемныхНастроек.Удалить("ИсторияВыбора", , ПользовательИБ.Имя);
    Исключение
        // Исключаем падение системы при обработке заблокированных или служебных учетных записей
        ЗаписьЖурналаРегистрации("ОчисткаИстории", УровеньЖурналаРегистрации.Предупреждение, , , 
            "Не удалось очистить историю для пользователя: " + ПользовательИБ.Имя);
    КонецПопытки;
КонецЦикла;

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

Способ 5. Пользовательские методы очистки истории без программирования

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

  1. Очистка через настройки пользователей (для администраторов): В типовых конфигурациях перейдите по пути: Администрирование — Настройки пользователей и прав — Персональные настройки пользователей. Выберите карточку проблемного сотрудника, перейдите в раздел его индивидуальных настроек и воспользуйтесь кнопкой очистки всех сохраненных настроек интерфейса и истории поиска.
  2. Интерактивное удаление строк пользователем: Если ложные подсказки возникают локально у одного человека, он может самостоятельно удалить ненужные строки. Для этого в выпадающем списке истории необходимо с помощью стрелок на клавиатуре «Вверх»/«Вниз» выделить конкретный ошибочный элемент и нажать сочетание клавиш Shift + Delete (в современном интерфейсе «Такси» также доступна иконка крестика напротив элемента). Это навсегда удалит запись из его персонального кэша.
  3. Сброс локального кэша платформы 1С: Если история продолжает всплывать вопреки всем настройкам, это свидетельствует о застревании кэша в локальных папках Windows. Закройте программу, удалите базу из списка запуска 1С, а затем добавьте её повторно под тем же именем — это создаст чистые каталоги кэша на диске и полностью обнулит локальные временные файлы истории.

Резюме

Мы подробно проанализировали проблему сохранения истории поиска в подборе номенклатуры 1С и изучили ключевые особенности работы платформы с текстовыми полями. Для достижения гарантированного результата рекомендуется комбинировать подходы: использовать динамическое отключение истории в событии АвтоПодбор и периодически производить программную или интерактивную очистку устаревших системных настроек в информационной базе.

← На главную