Расширение конфигурации: как перехватить событие модуля формы без её заимствования? #811211

Пример: в типовой конфигурации есть документ РеализацияТоваровУслуг. Я хочу с помощью расширения в табличную часть Товары основной формы документа программно добавить колонку с остатками. Создал расширение, добавил (заимствовал) из типовой конфигурации форму документа и в модуль формы прописал такой код: // перехватчики событий формы Расширение работает как нужно, колонка добавляется, остатки заполняются. Теперь, если я правильно понимаю, после обновления типовой конфигурации пользователь по-прежнему продолжит работать с ранее заимствованной версией формы документа, и её визуальная часть (со всеми элементами, которые, возможно, в новой версии типовой формы уже использоваться не будут) останется неизменной. Поэтому чтобы в расширении привести форму документа в актуальное состояние, нужно будет её после обновления конфигурации, скажем так, "перезаимствовать". Но визуальная часть ранее заимствованной формы в расширении мне не нужна, потому что колонка остатков добавляется на форму программно (главное, чтобы после очередного обновления типовой конфигурации табличная часть формы Товары никуда не далась, а это мало вероятно). Тогда можно было бы один раз залить расширение и спокойно обновлять конфигурацию, не заморачиваясь о том, что визуальная часть формы из расширения с каждым обновлением типовой конфигурации устаревает. В общем, после каждого обновления типовой конфигурации я хочу всегда видеть новую форму документа, но с перехватчиками событий из старого расширения. Возможно ли такое реализовать в принципе?

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

да

т.е. в коде и в тексте топика объяснен порядок ее заполнение. Важно, что это заполнение происходит именно в контексте формы, что совершенно не будет доступно без ее заимствования.

ДА. Заимствованная форма обновится вместе с конфигурацией, а вот добавленный код в расширении останется неизменным

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

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

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

Можешь даже "пустышку" сделать без реквизитов. Но тогда при программном формировании формы нужно будет ПОСЛЕ обработчика события "При создании на сервере" переопределить обработчики событий нужных тебе типовых элементов формы, на обработчики из расширения. А уже из обработчиков расширения выполнять вызов типовых. Это более геморойно, и есть вероятность что программсты 1С переопределят вызов типового обработчика, но в этом случае форма будет именно "пустышкой". В таком случае, какие-либо интерфейсные изменения типовой формы не будут влиять на расширение.

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

Это должно быть реализовано штатно и с удобствами, а не такими вот хаками. Блин, хорошую идею не могут нормально реализовать.

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

Смотрите с 11.10 Там главный вывод из всего видео Не вноси изменение в форму расширения в ИЗМЕНЕННУЮ  в конфигурации форму. Т.е. делай изменения в расширении с типовой формой и НИКОГДА не возникнет такой ситуации. Что и подтверждается практикой. Если заимствуешь типовую, то никаких обновлений не требуется, все работает как надо

всё это, конечно, полезная информация. но больше для общего развития, а не для решения поставленной задачи. напомню, задача стояла в том, чтобы не изменяя типовую конфигурацию иметь возможность динамически дополнять типовую форму документа своими реквизитами и элементами. варианты решения: 1. использовать внешнею обработку ВидОбработкиЗаполнениеОбъекта и ТипКомандыЗаполнениеФормы минус - чтобы отобразить изменения на форме документа, пользователю нужно будет нажать на кнопочку "Заполнить"      2. используя механизм расширений, заимствовать типовую форму и в модуле заимствованной формы определить перехватчик события ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка) минус - после обновления типовой конфигурации разработчики, например, могут что-то удалить в типовой форме, и возникнет конфликт между заимствованной форму и типовой из обновленной конфигурации, а значит нужно будет переписывать расширение даже если внесенные разработчиками изменения в расширяемую форму не участвовали в логике расширения      3. использовать механизм переопределения обработчиков событий типовой формы через общий модуль "МодификацияКонфигурацииПереопределяемый" минус - в общем модуле одноименный обработчик события формы полностью подменяет стандартный, то есть таких гибких инструментов как в расширении (позволяющих лишь дополнять стандартные обработчики Перед или После) там не предусмотрено      еще один минус -  нужно снимать с поддержки конфигурацию, хоть и порядок обновления будет в данном случае значительно упрощен (впрочем, можно сначала позаимствовать в расширение "пустой" общий модуль "МодификацияКонфигурацииПереопределяемый" и уже там описать свой обработчик события - тогда снимать с поддержки конфигурацию не придется)

В последнем методе можно сделать так: определяем свой обработчик, например КонтрагентПриИзмененииДобавленный в котором в начале или концу делаем вызовКонтрагентПриИзменении - вот вам и Перед или После

в общем, я попробовал такой вариант. заимствовал в расширение из основной конфигурации общий модуль "МодификацияКонфигурацииПереопределяемый", и прописал там следующий код: в основной конфигурации общий модуль "МодификацияКонфигурацииПереопределяемый" не трогал (не редактировал). всё и так работает.

именно это я и предлагал. Вообще процедура ПриСозданииНаСервере модуля МодификацияКонфигурацииПереопределяемый позволяет сделать многое, но меня удивляет, что до сих пор эта процедура вызывается не во всех формах...

Оно постепенно внедряется. И зачем при наличии подобных модулей городить огород с расширениями? )

Не понимаю, что не так с расширением?! Добавил форму, удалил все ненужные элементы, таблица формы - контролируемое свойство. Все. Что за демагогия?!

в данном случае я вынес общий модуль "МодификацияКонфигурацииПереопределяемый" в расширение только лишь для того, чтобы вообще не трогать типовую конфигурацию. тогда при обновлении не будет никаких сравнений и объединений с конфигурацией поставщика, что позволит немного сэкономить времени

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

"2. используя механизм расширений, заимствовать типовую форму и в модуле заимствованной формы определить перехватчик события ПриСозданииНаСервереПосле(Отказ, СтандартнаяОбработка) минус - после обновления типовой конфигурации разработчики, например, могут что-то удалить в типовой форме, и возникнет конфликт между заимствованной форму и типовой из обновленной конфигурации, а значит нужно будет переписывать расширение даже если внесенные разработчиками изменения в расширяемую форму не участвовали в логике расширения " Абсолютно, на все 100%, неверный, вывод.С точностью наоборот. Прекрасно отработает все внесенное новое разработчиками и после ваше изменение. НИКАКОГО конфликта, да и откуда им взяться, если у вас ПОСЛЕ? Спокойно отрабатывает код типовой и добавка - ваши изменения

конфликт будет, если ты тупо добавил в расширение всю форму и за ней подтянулись десятки объектов, а также все элементы формы - контролируемые свойства. Но так делает только невежда.

И даже в этом случае - не могу представить конфликтной ситуации. Конфликт в формах (еще раз, для скептиков, - В ФОРМАХ) может возникнуть, по практике, только, если что-то добавляешь в интерфейс одной и той же формы в РАЗНЫХ расширениях. Даже не в модуль, а, именно, в интерфейс. PS И вообще, складывается устойчивое впечатление, что про расширения здесь, в основном пишут теоретики, ни разу или крайне мало использовавшие расширения и знающие о них только из литературы (в лучшем случае), в худшем - руководствующиеся своим представлением как это работает, без реальной практики.

согласен. на счет этого момента заблуждался

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

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

Добавляете форму, делаете необходимые изменения и можете смело удалять лишние реквизиты, а следом за ними и подтягивающиеся с ними справочники. все что нельзя удалять, подскажет программа, остальное - смело в топку. Форма в расширении из конфигуратора может выглядеть необычно куцей, но в пользовательском режиме все будет ОК. И само расширение станет выглядеть понятней без кучи мусора подтянутого заимствованной формой

>> Там главный вывод из всего видео Не вноси изменение в форму расширения в ИЗМЕНЕННУЮ  в конфигурации форму. нет, главный вывод  - если после обновления конфы поставщик тронул расширяемую форму то необходимо зачастую обновить сохраненную форму чтобы именно изменения из расширения применялись 100% - тогда и будет все тип-топ...

Нет и еще раз нет. Если изначально была взята типовая, НЕизмененная форма, то после обновления добавляй в форму в расширении все что угодно, будут и изменения из обновления и внесенные изменения. Вот если изначально что-то делалось с типовой в конфигураторе и эту измененную заимствовали в расширение, тогда надо обновлять. И видео это подтверждает. Посмотрите вначале в заимствованной форме доступность поля ОТЛИЧАЕТСЯ от того же свойства в основной и в конце автор объясняет прямым текстом, что бралась уже измененная форма в расширение. И практика показывает, что ничего не надо обновлять если берешь изначально типовую форму

да не причем тут измененная конфа или нет. Сохраненная форма важна и именно с ней идет анализ -основная с сохраненной и расширения с сохраненной и потом идет обьединение результа в резултформу. А сохраненная фиксируется в момент помещения формы в расширение. Так вот НУжно обновить СОХРаненную форму ручками.

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