Как исправить перекрытие окна «Вопрос()» сплэш-заставкой при старте 1С в RDP?

← На главную

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

Причина возникновения проблемы

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

Вариант 1: Использование однократного обработчика ожидания

Наиболее универсальным и надежным способом считается перенос логики вызова диалога из процедуры ПриНачалеРаботыСистемы() в обработчик ожидания. Это позволяет дождаться завершения процесса инициализации системы и полного скрытия заставки.

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

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

Посмотрим на пример кода:


Процедура ПриНачалеРаботыСистемы()
    ПодключитьОбработчикОжидания("ПоказатьВопросПриСтарте", 1, Истина);
КонецПроцедуры

Процедура ПоказатьВопросПриСтарте() Экспорт
    Ответ = Вопрос("Вы хотите выполнить корректировку времени на ККТ?", РежимДиалогаВопрос.ДаНет);
    Если Ответ = КодВозвратаДиалога.Да Тогда
        // Выполнение логики работы с оборудованием
    КонецЕсли;
КонецПроцедуры

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

Вариант 2: Использование модальной формы вместо системного диалога

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

Разберем процесс перехода на модальную форму:

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

Хотя модальность требует аккуратного обращения, использование собственной формы позволяет настроить положение окна на экране, что исключает наложение на служебные области 1С. При вызове через ОткрытьМодально() платформа принудительно блокирует интерфейс владельца, что часто работает стабильнее системного диалога при отрисовке в терминале.

Вариант 3: Реорганизация бизнес-логики

Важно проанализировать, действительно ли необходимо задавать вопрос пользователю в момент старта системы. Если речь идет о технических проверках (например, времени на ККТ), лучше рассмотреть следующие архитектурные подходы:

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

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

Заключение

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

← На главную