Как исправить задержку ввода данных и «залипание» клавиши Enter после обновления платформы 1С?

← На главную

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

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

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

Для того чтобы решить проблему, нам необходимо понять физику процесса. Начиная с версии платформы 8.3.11, разработчики фирмы «1С» существенно переработали юзабилити управляемых форм и механизмы взаимодействия клиента с сервером. Изменения коснулись функций автоподбора и получения данных выбора:

Асинхронный автоподбор: В старых версиях платформы отправка запроса на получение данных выбора происходила практически мгновенно при нажатии клавиши подтверждения. В новых версиях этот процесс стал полностью асинхронным. Платформа ожидает окончания ввода (небольшой таймаут), после чего отправляет фоновый запрос на сервер.
Конфликт клавиатурного буфера: Если оператор печатает со скоростью профессиональной машинистки, интервал между вводом символа и нажатием клавиши Enter становится меньше, чем внутренний таймаут ожидания платформы. В момент нажатия Enter асинхронный поиск еще не завершился. Платформа перехватывает нажатие Enter, пытаясь обработать и показать выпадающий список выбора, который еще даже не вернулся с сервера. В итоге стандартное действие перехода к следующему элементу формы блокируется, а фокус ввода остается в текущем поле.
Сетевые задержки (Ping): Ситуация значительно усугубляется при работе в клиент-серверном режиме через тонкий клиент, особенно если пинг до сервера превышает 15–20 мс (например, при работе через VPN или удаленные филиалы). Каждое обращение за данными выбора провоцирует сетевой вызов, увеличивая общую задержку интерфейса.

Рассмотрим подробнее несколько эффективных способов решения этой проблемы: от простой настройки свойств конфигурации до написания кастомных обработчиков ввода.

Решение 1. Отключение стандартного автоподбора и использование события «ОкончаниеВводаТекста»

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

Выполним следующие шаги для реализации этого метода:

Откройте управляемую форму в конфигураторе и выберите проблемное поле ввода.
В палитре свойств элемента формы найдите свойство Автоподбор и установите его в значение Ложь. Это предотвратит отправку асинхронных фоновых запросов во время набора текста.
Создайте обработчик события ОкончаниеВводаТекста для этого поля ввода.

Проанализируем пример кода, который необходимо разместить в модуле формы для быстрой обработки ввода:


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

&НаСервереБезКонтекста
Функция НайтиЭлементПоКодуНаСервере(Знач ВведенныйКод)
    
    // Используем максимально быстрый индексный поиск по коду
    Возврат Справочники.Номенклатура.НайтиПоКоду(ВведенныйКод);
    
КонецФункции

При таком подходе платформа не тратит время на формирование динамического списка выбора и не блокирует фокус. Нажатие клавиши Enter мгновенно вызывает серверную функцию точного поиска, подставляет значение и корректно переводит фокус на следующее поле формы.

Решение 2. Использование составного типа данных реквизита (строка + ссылка)

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

Рассмотрим по шагам программную реализацию этого алгоритма:

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

Посмотрим на пример практической реализации в коде формы:


&НаКлиенте
Процедура ТалоныПриемаПриАктивизацииЯчейки(Элемент)
    
    ТекущиеДанные = Элементы.ТалоныПриема.ТекущиеДанные;
    Если ТекущиеДанные = Неопределено Тогда
        Возврат;
    КонецЕсли;
    
    // В момент ввода принудительно устанавливаем тип "Строка" для быстродействия
    Если Элемент.ТекущийЭлемент = Элементы.ТалоныПриемаПовод Тогда
        Элементы.ТалоныПриемаПовод.ОграничениеТипа = Новый ОписаниеТипов("Строка");
    КонецЕсли;
    
КонецПроцедуры

&НаКлиенте
Процедура ТалоныПриемаПоводПриИзменении(Элемент)
    
    ТекущиеДанные = Элементы.ТалоныПриема.ТекущиеДанные;
    Если ТекущиеДанные = Неопределено Тогда
        Возврат;
    КонецЕсли;
    
    // Если оператор ввел строку, производим постобработку поиска на сервере
    Если ТипЗнч(ТекущиеДанные.Повод) = Тип("Строка") Тогда
        ТекущиеДанные.Повод = ПолучитьПоводПоКоду(ТекущиеДанные.Повод);    
    КонецЕсли;
    
КонецПроцедуры

&НаСервереБезКонтекста
Функция ПолучитьПоводПоКоду(Знач КодПовода)
    
    // Формируем параметры для получения данных выбора
    ПараметрыОтбора = Новый Структура("Отбор,СтрокаПоиска,ВыборГруппИЭлементов");
    ПараметрыОтбора.Отбор = Новый Структура;
    ПараметрыОтбора.СтрокаПоиска = КодПовода;
    ПараметрыОтбора.ВыборГруппИЭлементов = ИспользованиеГруппИЭлементов.Элементы;
    
    СписокВыбора = Справочники.НСИ_ПоводыПосещения.ПолучитьДанныеВыбора(ПараметрыОтбора);
    
    Если СписокВыбора.Количество() > 0 Тогда
        // Возвращаем первую точную ссылку
        Возврат СписокВыбора[0].Значение;
    Иначе
        // Если ничего не найдено, оставляем введенную строку для визуализации ошибки
        Возврат КодПовода;
    КонецЕсли;
    
КонецФункции

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

Решение 3. Оптимизация свойств метаданных «Ввод по строке»

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

Выполните следующие оптимизационные действия:

Откройте конфигуратор, найдите нужный справочник и перейдите на вкладку Данные.
Найдите кнопку Ввод по строке.
Убедитесь, что в списке выбранных полей поиска оставлено минимальное количество реквизитов (в идеале — только Код). Если там одновременно включены Наименование, Артикул, ПолнотекстовыйПоиск и другие реквизиты, СУБД выполняет сложный и долгий SQL-запрос при вводе каждой цифры. Оставьте для скоростного ввода только индексируемые поля.
Обратите внимание на свойство поля ввода на форме Быстрый выбор. Если оно включено, попробуйте отключить его, так как оно заставляет платформу предварительно кэшировать список выбора, что снижает отзывчивость интерфейса при быстром переходе по полям.

Решение 4. Настройка свойства формы «Поведение клавиши Enter»

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

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

Решение 5. Диагностика полнотекстового поиска и аппаратных задержек

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

Полнотекстовый поиск (ПП): Платформа 1С при автоподборе в управляемых формах может обращаться к индексу полнотекстового поиска. Если индекс поврежден или давно не обновлялся, это вызывает колоссальные задержки (до нескольких секунд на один запрос). Зайдите в базу в режиме «1С:Предприятие» под правами администратора, откройте обработку «Управление полнотекстовым поиском», выполните очистку и полное обновление индекса. Если полнотекстовый поиск в вашей базе не используется, рекомендуется полностью отключить его для повышения общей производительности СУБД.
Аппаратное ускорение графики: Начиная с интерфейса «Такси», отрисовка элементов управляемых форм сильно зависит от графической подсистемы клиентского компьютера. Попробуйте запустить тонкого клиента с параметром командной строки /ForceRurender, чтобы переключить режим рендеринга интерфейса, или протестируйте скорость работы операторов в веб-клиенте через современный браузер.

Подведем итоги

Проблема с «пропаданием» нажатия клавиши Enter на новых платформах 1С — это прямое следствие внедрения асинхронной архитектуры клиент-серверного взаимодействия. Чтобы вернуть операторам привычную скорость работы и уберечь их от увольнения, мы рекомендуем использовать комплексный подход:

Для полей с жестко регламентированным вводом по коду (артикулу, ID) — используйте Решение 1 с отключением автоподбора и обработкой в событии ОкончаниеВводаТекста.
В сложных табличных частях с большим объемом быстро вводимой информации — задействуйте Решение 2 с составным типом данных.
В качестве превентивной меры обязательно проведите оптимизацию свойств метаданных справочников по Решению 3 и обновите индексы полнотекстового поиска.