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

может это?

ВводДоступен()
Возвращаемое значение:

Тип: Булево.
Истина - ввод данных в форму возможен (форма активна); Ложь - форма не активна.
Описание:

Определяет, возможен ли ввод данных в форму. Может быть использован для того, чтобы определить, активизирована ли текущая форма.

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

(2) а ты уверен, что твой обработчик ожидания при открытой, блокирующей весь интерфейс форме, сработает?

(3) Сам офигел, но он работает(((((

(3) Собственно в этом то и проблема, чтобы разные обработчики не наплодили блокирующих окон сотни

(4) именно "блокировать весь интерфейс"?

(5) открывать окно моветон. сделай форму на рабочий стол и показывай оповещение периодически

ну, на краяняк воспользуйся ключем уникальности, чтобы вторую форму не открывать

в БСП в напоминаниях это реализовано

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

константу поставь Заблокирован

(10)
> Есть различные обработчики ожидания, которые могут
> выкидывать блокирующие окна, чтоб пользователь обязательно
> среагировал.
чё за афтоматизация когда фсёвручную?

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

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

(13) Думалось об этом, но капаться придется долго и много всего всего переписывать. Такие затраты пока неоправданы. Проблема, которую я описал, в жизни почти встречаться не будет, при работе пользователя, но хочется конечно решить.

(15) Просто, если пользователь занят чем-то одним, а в этот момент всплывает окно, то у пользователя одно желание - побыстрее закрыть окно.

(16) Это уже организаторский уровень, есть события на которые нужно реагировать оперативно.

(17) это кривая организация. Если, конечно, не сам юзер задает, какие окна у него должны вылазить и блокировать всю работу в тот момент, когда он реализацию на тыщу строк колбасит.

Кстати, очень жаль, что Оповестить()  - это не функция, результатом которой является (условно) - массив ответов всех открытых форм, способных ответить на данное сообщение.

(18) Возможно. Тут еще подумаем. Но сам вопрос по определению в коде блокирован ли интерфейс всеже инересен

(20) Вообще-то, 1С призывает отказаться от модальности, так что эти вопросы, со временем, станут совсем не актуальными.

(19) Можно по другому завернуть, передавать в параметрах форму котора вызывае события, а из других уже юзать экспортный метод или както еще

(21) Прими это как не модальные окна, а окна блокирующие интерфейс, такие и при отказе о модальности остаются)

(22) без полновесного обмена сообщениями между формами - лучше заюзать контекст сеанса, что угодно - параметр сеанса, разного рода блокировки (от блокировки сеанса до  ЗаблокироватьДанныеДляИзменения()) . Через параметр сеанса (в который в виде ХЗ можно пихать всё, и структуру в т.ч.)- думаю, можно нормально рулить. Но через оповещения было бы красивше.

(23) Так это тоже самое - например - в Windows модальный диалог всего-лишь блокирует интерфейс основного окна, просто убивая сообщения ввода данных из его очереди.

(25) в 1с 77 (проверял в недавней теме) - при открытии модального окна - тупо все остальные окна приложения становятся disabled (смотрел через Windows Scanner). Сомневаюсь, что при этом они не способны ловить сообщения.

(26) Так это и есть "неспособность принимать сообщения ввода".

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

Эх, задача с определением состояния интерфейса, или получением списка открытых форм (без модернизации этих форм) в обычном интерфейсе не решается встроенными процедурами и функциями 1С((((