Есть форма (касается и обычных и управляемых), при определенных параметрах выполняющая длительное действие на клиенте при открытии. Хочется предоставить пользователю удобство в виде возможности прерывания этого необязательного действия, но чтобы форма при этом осталась открытой. Я полагал, что однократный обработчик ожидания в модуле формы здесь прекрасно решит задачу. Но в текущей позиции производителя такая возможность не предоставляется, т.е. прервать такой код невозможно и это причислили к особенностями http://its.1c.ru/db/v83doc/bookmark/dev/TI000001301. Причем для обработчика ожидания в модуле приложения такого ограничения нет.

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

Возможно есть какой то другой, более красивый, способ?

> более красивый, способ?

Не выполнять длительных действий при открытии формы. Выполнять их до или после открытия.

ОбработкаПрерыванияПользователя (UserInterruptProcessing)
Синтаксис:

ОбработкаПрерыванияПользователя()
Описание:

Предназначен для прерывания работы встроенного языка при нажатии пользователем клавиши Ctrl+Break.

(1) Что значит "после открытия"? Пользователю приходится каждый раз после открытия формы жать кнопку этого действия. Логичный вопрос он задает "зачем я ее жму каждый раз, когда итак понятно, что я ее буду нажимать?"

(2) В точку, бро. Именно об этом речь и идет. Этот метод не работает как обещано в обработчике ожидания формы.

Проблема в том , что пользователь будет прерывать это действие почти в 100 процентах случаев. Смысла нет.

(5) Ошибаешься. Пользователю показывается индикатор завершенности действия. Если он видит что ему ждать 30 сек, а результат этого действия ему в данный момент не очень нужен, то он прервет. А в подавляющем большинстве случаев 1-3 секунды он готов подождать, чтобы увидеть сразу всю подготовленную информацию.

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

(7) Фоновое задание - в рамках описанной цели еще больше "огород", чем обработчик ожидания в модуле приложения, тем более с добавлением регистра сведений да еще в файловой версии с таким вариантом будут сложности.

(7)+1 механизм фоновых заданий во многом под это и заточен

(0) а ОбновлениеОтображения() не устроит с дополнительным флагом (для однократного выполнения)?

(10) а не, тоже не работает...

(10) В управляемой форме такого события нет. Для обычной формы такая же беда как и с обработчиком ожидания - не срабатывает ОбработкаПрерыванияПользователя.

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

(13) Огород потому что необоснованно сужает диапазон применимости решения. Мне нужна работа в т.ч. в файловом режиме на 8.2

(14) А способ с глобальной переменной и обработчиком ожидания в модуле приложения не сужает применимости решения.

(15) Точнее сужает =), но заметно меньше чем способ с фоновым заданием.

(15) Ну сделай в файловом так, а в клиент-серверном эдак.