Если у одного вида документа есть 2 подписки на одно и тоже событие (скажем, "ПриУстановкеНомера") какая будет срабатывать первой?

Конфигуратор, точка останова, проверить, сообщить результат здесь.

понятно, ну в теории? вдруг на двух разных машинах по разному?

(2)В теории, думается мне, такого быть не должно, как собственно и на практике.

ок

Результаты теста)
Первой срабатывает та, которая в дереве метаданных выше.

Интересные вопросы появляются в понедельник утром) Прям пытливый ум)

(5) Но не факт, что это истинно для любых ситуаций.

(5) Т.к. этио не гарантированно фирмо1 1С - на ваши результаты нельзя опираться, не факт что по обновлении платформы не станет работать по другому.

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

(9) согласно инсайдерской инфе нельзя на это опираться!

Хотя, можно опереться на статью Гения1С) Авторитетного человека)
Книга знаний: v8: 8.1: Подписка на события

Хотя конечно все это смех, просто не верная архитектура у (0) раз 2е подписки вешает на 1 событие, иначе утром понедельника не придумывается зачем это надо.

(11) повторяю: согласно инсайдерской инфе из 1С нельзя на это опираться т.к. это недокументированная фича и в самой 1С ей почему-то не пользуются (не наводит на размышления "c чего-бы это?")!

(12) одна может быть совсем не его

(14)Логично, не подумал про типовую почему-то)

(13)С того, что они не могут придумать нафуя им вешать 2е подписки на 1 событие, или там тоже может быть 1 не их?

В документации на ИТС сказано, что обработчики вызываются в произвольном порядке.

Подтверждаю, у меня пара подписок после обновления стали вызываться в другом порядке.

(18) Просто при ообновлении поменялось х раположение в дереве. Например разработчики добавили свои подписки и они расположени ниже твоих в дереве.

(12) одна подписка типовая, другая добавленная

(12) одна подписка на все документы (например проверка закрытого периода), вторая на конкретный тип...

Ладно, ладно, проснулись, начали закидывать какахами)

Не предсказуемо. Так что если порядок важен, то необходимо предусмотреть вариант вызова в произволном порядке

(21) И все это умножить на количество конфигураций поставщика плюс 1.

(9) Лучше сделай так, чтобы работало в любом случае.

(22) ну с самого-же начала говорю что нельзя на порядок опираться! Кста, это повсеместная практика, у оракула такая-же фигня с тригерами БД.

вроде как рандом...

(0)Завести одну подписку, в ней вызов 2 процедур в нужном тебе порядке.

2(27) да конечно... Вот так себе и представляю разработчики платформы между собой:
-- А давайте сделаем чтобы 1Сники совсем заи.ались, и подписки будем вызывать в случайном порядке.
-- Так ведь это программировать нужно,а у нас тут еще тикет на исправление утечек памяти..
-- Ну так весело же будет.
====

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

Так и хочется воскликнуть "Как страшно жить"(с). Не документирован порядок вызова обработчиков - ну и не надо. Ну и не надо это юзать. В любом языке есть свои ограничения, накладываемые... ммм... а чем, собственно говоря, "накладываемые"? Наверное тараканами на чердаке разработчиков :) Короче: одним ограничением больше или меньше - фиолетово.

(28) С вероятностью 99,9% процента - автор захотел вставить свою подписку перед вызовом типовой :)

(24) если открыть типовую любую, там например на событие ПередЗаписью штук 10 подписок. А конфигурация поставщика одна всего.

(29) поэтому я и написал ВРОДЕ.
Если память мне не изменяет то слышал краем уха на видеокурсах http://www.nasf.ru/