Что нибудь слышно о том когда появятся возможности создавать константы, перечисления, регламентные задания, подписки на события?

как то без этого вообще невозможно начать делать расширения. А года идут и мало что происходит.

+(40) правда хелп к ней ещё не написал, ибо пока лень

(39) не вижу отличий запихнуть в расширения или впф, для франча проще пихнуть в расширение.

(40) можно на мою почту (указана в профиле)? У меня есть своя обработка, но она недопилена (функционал делался под себя и конкретные задачи) и стыдно показывать.

(39) одно дело в существующую печ форму добавить пару изменений, другое дело - печ форму вынести из конфигурации в ВПФ.

(42) (44) я о том, что для такой задачи хватило бы внешней ВПФ.


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

(45) я к тому - а если этой ВПФ под рукой нет? Удобного механизма вытаскивания печ.формы в ВПФ нет - только ручками - а там частенько кода много.

(43) Мыло скрыто для меня((((
А у меня допилена и теперь даже с небольшим описанием. Секрет прост - никаких лишних усложнений, рюшечек, свистелок и сверкалок

(42) Любой функционал, запихнутый в расширения, необходимо контролировать на совместимость и применимость после каждого обновления. В идеале так.

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

А вообще что касается внешних печатных форм, то начиная с версии БСП 2.3.4 (или 2.3.5?), 1С рекомендует включать печатные формы, отчеты и обработки в расширения через подсистему ПодключаемыеОтчетыИОбработки. Технология внешних печатных форм, отчетов и обработок оставлена для совместимости.

(45) кстати, расширения дают дополнительные тормоза.

(40) Покажи на картинке пару форм этой обработки, если не сложно

(46) Не поверишь, но ВПФ отлаживаются на раз-два без всяких там супер-пупер механизмов и инструментов. Самое сложное мне попалось, это обработка ТЧ. Просто я верил в то, что 1Сники одумались и потерял лишний час

(47) ildary (dot) gmail.com

(51) Я не про отлаживание (которое у меня с ВПФ никогда не составляло труда), а про механизм вынесения встроенной печ. формы в ВПФ.

(49) > кстати, расширения дают дополнительные тормоза.

Кстати внешние отчеты и обработки дают ещё бОльшие тормоза. 1С где-тона ИТС об этом писала даже. Поэтому рекомендуют вкорячивать все дополнительные отчеты, обработки и печатные формы в расширения. В БСП для этого запилили подсистему ПодключаемыеОтчетыИОбработки

Интересно а ведется какая то некая тайная работа над 1С 9?
Ну типа где вообще все будет по другому.

(53) Обновление расширения при работающих пользователях приводит к неявному динамическому обновлению

(54) учитывая сколько лет без движения висит 8.4 с её новой моделью сервера - я для себя просто перестал надеяться на 1С9, где летают бабочки и пони какают радугой.

(49) // расширения дают дополнительные тормоза.

Спорно, спорно. Если и есть, на глаз незаметно

(55) А постоянное одновременное использование одной и той же ВПФ большим количеством пользователей к утечкам памяти (точнее к нерациональному её использованию т.к. создаётся каждый раз в памяти новая версия обработки при каждом вызове) и накладным расходам (создание временного файла обработки, запись его, удаление).

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

Не понял про тормоза...
Что будет с расширением если там будут созданы регистры с миллионами записей?

(55) да, демонические обновки расширений - зло.
Инфа стопицот процентов, сколько собак на нем съел.
Не дай бог каждому.

(54) > ведется какая то некая тайная работа над 1С 9?
(56) > я для себя просто перестал надеяться на 1С9

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

Так что наслаждайтесь.

А вообще цифра "9" - не модно. Следующая версия будет "10" или "Х".

(55) Спасибо, не знал. А если обновить расширение не выгоняя пользователей несколько раз в день - это приведет к беде?

(57) Никто не бьёт в колокола "расширения съедают наш сервер!!11", но учитывать это надо - особенно на предприятиях, где в роли сервера Xeon 2009 года.

До чего интересная тема получилась! Началось как старый добрый срач Интел vs AMD, но сколько новых интересных вещей всплыло. Спасибо всем!

(60) да нихрена там не тормозит, если расширять грамотно.
если и подтормаживает децел, так это в момент загрузки прикладного

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

(62) // А вообще цифра "9" - не модно. Следующая версия будет "10" или "Х".

Говорят, осенью нам презентуют 9 и 11

(63) > если обновить расширение не выгоняя пользователей несколько раз в день - это приведет к беде?

Как с любым динамическим обновлением. У кого-то оно работает без нареканий, а кто-то жалуется на регулярно возникающие глюки.

Короче не стоит без острой необходимости злоупотреблять.

(52) Держи

(65) Хммммм... Интересно. Я наоборот, считал, недостатком расширений то, что при изменениях и обновлениях основной конфигурации практически невозможно отследить применимость версии расширения. Никаких инструментов фактически нет.
Контроль применимости проверяет только изменения свойств некоторых реквизитов и объектов. А этого недостаточно.
Ну и наконец просто жизненно необходима возможность сравнения/объединения основной расширяемой конфигурации с её расширениями. Если эта возможность не появится в обозримом будущем, то уделом расширений останется незначительно допилка и внешние печатные формы, отчеты и обработки. Ничего серьезного туда не запихнешь т.к. постоянно будет что-то слетать при каждом обновлении основной конфы.

(69) у меня например вообще нет изменений конфигурации. Полностью все свое. Один только реквизит справочника типового добавлен.
Все остальные метаданные вообще никак ничего не меняют.

По факту у меня дополнение которое надо ставить. И это достаточно серъезное решение.

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

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

Вот тенму завел, потому что в очередной раз решил проверить что там да и как.
Открыл конфигуратор - прощелка на таких моментах (контстанты, перечисления, задания, подписки) и понял что стоим на месте.

(70) А у меня всегда много чего добавлено и во многих базах. Специально ищу предприятия с самыми извращёнными бизнес-процессами. Всё делаю на подсистемах, расширениях, книжках и люлях. Обновления конф производится за считанные часы и то только из-за того что пока скачаешь, пока развернёшь и т.д.
Так что кто-то себе ищет проблемы и грустит из-за них, а кому-то фиолетово и на расширения и на всё остальное))))))

(70) По такому сценарию вопросов нет. Если всё прикручено сбоку, функционал основной конфигурации не используется и минимально модифицируется, то это вполне рабочий вариант.

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

(71) > остальное отлично работает

До первого значительного обновления.
Расширил процедуру или функцию какого-нибудь модуля, а 1С вдруг решила перефигачить всю подсистему с перекладыванием этих процедур и функций с одних модулей в другие да еще и с частичным переписыванием этих процедур.

Типичный пример - любая стандартная библиотека - РегламентированнаяОтчетность (БРО), БиблиотекаЭлектронныхДокументов (БЭД), БСП. Ну или например НДС, в котором раз в 1-2 года начинают в очередной раз что-то куда-то перетаскивать из одних модулей в другие.

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

(75) Эта проблема (перефигачили всю подсистему) - есть и безо всякого расширения. И решать её так же тяжело как и с расширением.

(76) +1
что так сломается, что так

(76) > И решать её так же тяжело как и с расширением

С расширением эти проблемы не решаются вообще. От слова "никак".
Единственный способ - перетестирование всех доработок. Проверка, что ничего не отвалилось и работает так, как ожидается.

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

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

(78) У расширения же есть "проверка возможности применения". Разве это не оно?

(79) > "проверка возможности применения". Разве это не оно?

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

Логика расширенных модулей, процедур, функций и вообще их существование не контролируется никак. Расширил ты процедурку какую-нибудь. А 1С возьми и переименуй её. Или расширил ты форму и используешь в коде имена реквизитов и элементов этой формы, а 1С эту форму перефигачила всю фому с переименованием половины реквизитов и элементов.

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

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

(66)Модно приставка I
I1C - как звучит.

(80) Да это и понятно, что когда бездумно конфу меняешь, то в это и упираешься. Просто думал может оно...
Ну и ладно

Я правильно понимаю: если хочу внести изменения в модуль менеджера (изменить процедуру), то весь модуль импортируется в расширение и там вношу изменения в нее. При этом если выходит обеовление в котором весь модуль изменен, то перестает работать весь модуль, а не только 1 процедура? И что вы делаете? В чем плюсы?

(85) в расширении создается пустой модуль менеджера и в нем надо создать свои изменения. То есть если надо добавить пару строчек в начало или конец - то в расширении пишется только эта пара строчек.

(86) о чем пишет (45) что за зависимые объекты подтягиваются?

(80) буквально на днях был отвал расширения  в БП3 - конфигу обновили - у заимствованного документа сменился тип номера, расширение при старте не подключилось.Обновлял один человек, а расширение поддерживает другой, в итоге функционал не работал неделю.

(87) Извиняюсь, был неправ. Чтобы добавить модуль - надо добавлять сам объект, а он за собой может утянуть все связанные объекты, которые потом лучше удалить из расширения. Но в самом модуле менеджера - будет пусто (как я и писал). Но - может и не утянуть.

(88) Это очень удачный случай. У тебя изменилось свойство контролируемое механизмом применимости расширений. Наверняка при этом еще и сообщение какое-то выскакивает о невозможности применить расширение.

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

(88) а это как-то диагностируется в ЖР или при запуске выдавалось что-то?

(91) По крайне мере один раз точно должно было выскочить сообщение о невозможности применить расширение.
И в ЖР каждый раз выдается соответствующая запись.

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

никто не знал

(89) т.е. весь текст модуля менеджера никуда не тянется в какое-то скрытое место как связанный объект?

(58) "накладным расходам (создание временного файла обработки, запись его, удаление)" // В БСП уже пару лет как без временных файлов подключаемые отчеты и обработки сделаны

(95) ну там на самом деле 3 модуля, а не 2. У Гилева в видео вроде объясняют. Если мы расширяем форму, то есть основная форма, загруженная форма и форма расширения. Например, если обновление, то основная форма обновляется, а загруженная форма остается старая, необновленная. Пока мы ее не актуализируем.

(97) Называй вещи своими именами, не вноси путаницу. Форма называется "сохраняемая" / "сохраненная".

плохо то нельзя только модуль формы расширить без самой формы.
Тогда проблемы (97) можно было бы избежать

(97) Вот так дела. Значит возвращаюсь к механизму прописывания "хвостиков" при помощи отдельного инструмента и отказываюсь от расширений даже для такой мелочи

(16) За расширениями будущее. В данном случае 1С идет самым, что ни на есть правильным направлением.

собственно расширения были придуманы для фреша прежде всего

(96) ну во внешнее хранилище все равно обработка зачитывается каждый раз

(100) почему отказываешься? Просто хранится какой-то прожуточный вариант формы. Почему из-за этого ты должен отказаться?

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

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

(97) можно ссылку на видео Гилева?

(106) Аналогично. Но тут вопрос про изменения форм. Это тоже делается программно и отдельной подсистемы. Кроме одного-двух вызовов (Перед открытием, Перед закрытием и т.д.). Вот эти вызовы делал при помощи инструмента, который в автомате прописывает после каждого обновления или выдаёт соответствующие ошибки. А тут что-то решил в расширении использовать. Всё прикольно, но теперь воротаю всё в зад, чтобы формы были всегда актуальны

(106) > скажу честно - я стараюсь вносить изменения в форму программно

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

Но когда наконец 1С сделает сравнение/объединение расширения с основной конфигурацией эта проблема уйдёт.

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

(109) смысл - все формы типовые, при обновлении конфигурации с ними никаких проблем. А после обновления достаточно программно пооткрывать формы, в которые внесены изменения - и если форма изменилась радикально - то вылезет ошибка.

Забыл сказать - код изменения формы при этом сидит в общем модуле, весь.

(110) в БСП конфигурациях есть модуль МодификацияКонфигурацииПереопределяемый, в нём процедура ПриСозданииНаСервере() - вот в нём все игры с формой лучше и делать. Точнее в расширении, которое этот модуль переопределит. Модуль формы такой же нетронутый, как сама форма.

(110) Аналогично, пользуюсь обработкой по декомпиляции форм.

(112) Извините, а что делает эта обработка?

(111) Не знал про одну общую точку. Теперь знаю)))))

(112) Это которая фиксирует изменения из 2-х файловых деревьев? Что-то не рискнул такой пользоваться. Наверное испугался

(114) Очень рекомендую эту общую точку. Также очень удобно, что при необходимости что-то поправить или скопировать поведение - не надо бегать туда-сюда по окнам - только по закладкам.

(100)Что за инструмент у тебя?

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

(111) > смысл - все формы типовые, при обновлении конфигурации с ними никаких проблем.

В случае изменения формы в расширении то же самое. Тут вообще никакой разницы.

> А после обновления достаточно программно пооткрывать формы, в которые внесены изменения - и если форма изменилась радикально - то вылезет ошибка.

Опять таки в случае непрограммного изменения формы в расширении метод "пооткрывать ручками" работает точно так же
)))

(110) > Данные не потеряются. Добавленный реквизит не меняет своего товарного вида.

Никакой разницы в сравнении с Непрограммным редактированием формы в расширении.

> При обновлении даже не вспоминаешь про эту форму.

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

То есть в этой части разницы между программным добавлением/изменением элементов формы и прямым (в редакторе форм) нет никакой.

Какие-то неубедительные доводы, если честно....
Надеялся на открытие некое тайного знания или чего-то, чего я не знаю.

(116) Выгрузка текстов конфы в старом формате, нажатие на кнопку в конфе, в которой фиксируются алгоритмы поиска места вставки кода и сама вставка кода. Загрузка текстов обратно.
Писал давно, работает потихоньку.
Всегда вставляю только вызов в "При создании" и в "Перед закрытием". Эти процедуры с большей вероятностью никуда не денутся

(118) >> Неправда. Если форма изменена поставщиком в обновлении значительно, то с высокой долей вероятности, будут абсолютно те же самые проблемы что при добавлении/изменении элементов формы напрямую в расширении.

Нет. Максимум что может случить, так это "убежать" на границу. Но не исчезнет и данные точно не потеряются.
"Убежит" реквизит только в случае, если группа, в которую его кидал, переименована или удалена.

(118) >> То есть в этой части разницы между программным добавлением/изменением элементов формы и прямым (в редакторе форм) нет никакой.

Расширение: изменили форму в обновлении, значит при обновлении эти изменения надо все учесть.
Программное добавление: пофиг на изменения от слова совсем

С ОФ сложнее. Там с привязками просто трындец какой-то

(120) Извините, а к ОФ работа расширения применима в части работы с формами?

(121) Честно? Не знаю. Просто вопрос обновления конф стоит давно и поэтому редкие реквизиты "кидал" и на ОФ

Расширять можно только управляемые формы, ОФ в пролете.

https://its.1c.ru/db/v8310doc#bookmark:dev:TI000001516

(119) > Нет. Максимум что может случиться.....

Ну и что дальше?.... Всё то же самое произойдёт и в случае если форму редактировать НЕ программно.

Вы хоть вопрос читаете? Я спрашиваю - в чём конкретно смысл программного редактирования формы?
Всё что я читаю в ответ - это какие-то невнятные примеры того, как поведёт себя обновление. Причем все примеры поведения АБСОЛЮТНО аналогичны тому что будет происходить в случае если формы допиливать не программно.

(120) > Программное добавление: пофиг на изменения от слова совсем

Да вы что?... Программно отредактировали элемент формы (например, изменили обработчик события "ПриИзменении"). Поставщик этот элемент изменил (было поле ввода, а стала надпись или декорация с новыми обработчиками).
А вам таки пофиг от слова "совсем"?...
Причем заметьте: никаких синтаксических ошибок в этой ситуации не возникнет. О проблеме вы узнаете от пользователя (и то если пользователь её сам заметит).

Ахинея какая-то...
Извините.

чтоб проблем не было нужно тесты писать всетаки

(126) Это понятно.... Времени жалко. Точнее его никогда не хватает. Даже если тестами охватить только основной ключевой функционал, на написание этих тестов уйдет уйма времени.

(127) это окупается сторицей

(125)>>Да вы что?... Программно отредактировали элемент формы (например, изменили обработчик события "ПриИзменении"). Поставщик этот элемент изменил (было поле ввода, а стала надпись или декорация с новыми обработчиками).

Этот крайне редкий случай  надо отлавливать при обновлении. Объединить с приоритетом новой конфигурации никто не отменял.

С программным все  много проще.

(129) > С программным все  много проще

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

(130) А что сравнивать формы по реквизитам уже можно?

(103) А что в этом плохого?

(107) https://xn----1-bedvffifm4g.xn--p1ai/news/2017-11-24-forms-customization-by-using-extensions/

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

(125) >> Да вы что?... Программно отредактировали элемент формы (например, изменили обработчик события "ПриИзменении"). Поставщик этот элемент изменил (было поле ввода, а стала надпись или декорация с новыми обработчиками).

Это относится только к случаю, когда работяга кодер. 1С-ник хорошо знает методологию и глупо и слепо не будет следовать приказам бухгалтера тёти Маши.
Во-первых, изменять обработчик у реквизита, который, пусть даже в теории, могут поменять, это либо глупо, либо надувание щёк. Надо программно скрыть ненужный реквизит и программно же создать новый. Вариантов много, но не надо выбирать наихудший.
Во-вторых, как показывает практика, нет ситуаций, в которых бы надо было что-то менять в конфе так, чтобы потом нельзя было обновляться незадумываясь.
Ну я пойду дальше переделывать необновляемую конфу на вариант, когда её сможет обновить любой 1Сник по короткой инструкции)))))

(8) Константы, перечисления
Можно же справчоник с предопределнными значениями сделать. вообще не особо понимаю смысла в этих объектах

(136) Наследие царского режима (7.7).

(88) У семи нянек дитя без глазу.

(135) Извини, но это уже увиливания начинаются.

> Надо программно скрыть ненужный реквизит и программно же создать новый

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

> нет ситуаций, в которых бы надо было что-то менять в конфе так, чтобы потом нельзя было обновляться не задумываясь.

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

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