Как в ПередЗаписью установить отказ после вопроса? Модальность запрещена #791092

В конфигурации запрещена модальность. Но перед записью нужно спросить пользователя и в зависимости от ответа или разрешить запись или запретить. Как выкручиваться?

Своя кнопка записать

А если закрыл и записал

также своя кнопка "записать и закрыть"

не записал и закрыл. а закрыл, а тебя система спрашивает - записать изменения или нет

Добавляем реквизит на форму РежимЗакрытия. По умолчанию пусть будет Ложь ПередЗакрытием смотрим, если Не РежимЗакрытия, тогда Отказ = Истина и спрашиваем. А если РежимЗакрытия = Истина, тогда закрываемся.

без своей кнопки никак

потому что в перед записью никак не определить, нажал юзер на записать или на записать и закрыть

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

тут целая поэма на этот счет казалось бы простая задача , да? меня прям умиляют защитники УФ, когда им говоришь, что в УФ куча головняков (на пустом месте). а они только и знают, что про прямые руки.

1. проверить наличие Параметра записи, напр, "Программно" Если параметр есть обходить задавание вопроса. 2. Если параметра нет, то задавать вопрос и уходить в отказ. 3. в процедуре обработки ответа если надо записать, то записать программно с установлением параметра записи "Программно"

этот головняк имеет отношение не к УФ, а к браузеру Хром и подобным

уф и то, что 1с называет "отказом от модальности" (который по факту не является отказом от модальности) и "асинхронностью" (которая не является асинхронностью) - разные вещи. к сожалению., за ту неделю, которую 1с пилила поддержку хрома, когда он запретил блокирование основного потока, они не смогли сделать по нормальному, а потом уже было "нельзя нарушать обратную совместимость", и, что еще хуже - признавать то, что можно было выпустить через две недели, но с автоматическим async/await тем самым признав ошибку

если бы разработчики озаботились проблемами программистов, то добавили еще какой-нить обработчики. ПослеПослеЗаписи :)

Чтобы 1с озаботилось проблемами программистов? не в этой жизни

да ладно. чо уж поныть нельзя :)