В данной публикации хочется описать некоторые приемы внесения изменений в типовую конфигурацию для ускорения ее обновления типовыми средствами.
Прием №1: добавление реквизитов на форму программными средствами.
Задача знакома многим разработчикам. Заказчик хочет видеть какой то свой реквизит в форме объекта (документа/справочника).
Для примера возьмем документ «ПоступлениеТоваровУслуг» (конфигурация Бухгалтерия предприятия 2.0) и реквизит СтатьяЗатрат, который надо добавить в шапку. Смысл этого реквизита в том, что если он заполнен, то необходимо автоматически списать эти товары/услуги на счет затрат.
Сначала добавим этот реквизит в метаданные документа:
У нас он будет иметь смешанный тип. Это необходимо для определения счета отнесения затрат в зависимости от выбранного типа статьи затрат.
Как видно на рисунке выше, на форме документа практически отсутствует свободное место для размещения реквизитов. Тем не менее, мы можем программным способом слегка изменить размеры/ место расположение уже размещенных типовых реквизитов. Для удобства создадим некий общий модуль «_Формы» в который будем помещать процедуры, связанные с изменением форм любых объектов метаданных. Для начала, добавим несколько стандартных процедур:
&НаКлиенте
Процедура ДобавитьПолеВвода(Форма,ИмяРекв,Панель,Доступность,Л,В,Ш,Выс,ПривязкаЛев,ПривязкаПрав,Данные,КнВыбора,КнОткрытия) Экспорт
Реквизит = Форма.ЭлементыФормы.Добавить(Тип(«ПолеВВода»),ИмяРекв,Истина,Панель);
Реквизит.Данные = Данные;
Реквизит.Лево = Л;
Реквизит.Верх = В;
Реквизит.Ширина = Ш;
Реквизит.Высота = Выс;
Реквизит.УстановитьПривязку(ГраницаЭлементаУправления.Лево, ПривязкаЛев, ГраницаЭлементаУправления.Право);
Реквизит.УстановитьПривязку(ГраницаЭлементаУправления.Право, ПривязкаПрав, ГраницаЭлементаУправления.Право);
Реквизит.КнопкаВыбора = КнВыбора;
Реквизит.КнопкаОткрытия = КнОткрытия;
Реквизит.Доступность = Доступность;
КонецПроцедуры
&НаКлиенте
Процедура ДобавитьКнопку(Форма,ИмяРекв,Панель,Л,В,Ш,Выс,ПривязкаЛев,ПривязкаПрав,Заголовок,Картинка) Экспорт
Реквизит = Форма.ЭлементыФормы.Добавить(Тип(«Кнопка»),ИмяРекв,Истина,Панель);
Реквизит.Заголовок = Заголовок;
Реквизит.Лево = Л;
Реквизит.Верх = В;
Реквизит.Ширина = Ш;
Реквизит.Высота = Выс;
Реквизит.УстановитьПривязку(ГраницаЭлементаУправления.Лево, ПривязкаЛев, ГраницаЭлементаУправления.Право);
Реквизит.УстановитьПривязку(ГраницаЭлементаУправления.Право, ПривязкаПрав, ГраницаЭлементаУправления.Право);
Если Картинка<>Неопределено Тогда
Реквизит.Картинка = Картинка;
КонецЕсли;
КонецПроцедуры
&НаКлиенте
Процедура ДобавитьНадпись(Форма,ИмяРекв,Панель,Л,В,Ш,Выс,ПривязкаЛев,Данные,Текст)
Реквизит = Форма.ЭлементыФормы.Добавить(Тип(«Надпись»),ИмяРекв,Истина,Панель);
Если ЗначениеЗаполнено(Данные) Тогда
Реквизит.Данные = Данные;
КонецЕсли;
Реквизит.Лево = Л;
Реквизит.Верх = В;
Реквизит.Ширина = Ш;
Реквизит.Высота = Выс;
Реквизит.УстановитьПривязку(ГраницаЭлементаУправления.Лево, ПривязкаЛев, ГраницаЭлементаУправления.Право);
Реквизит.УстановитьПривязку(ГраницаЭлементаУправления.Право, Реквизит, ГраницаЭлементаУправления.Лево);
Реквизит.Значение = Текст;
КонецПроцедуры
Теперь добавим в этот же модуль обработку нашего случая:
&НаКлиенте
Процедура ДорисоватьРеквизитыФорм(Форма,Объект = Неопределено) Экспорт
Если ТипЗНЧ(Объект) = Тип(«ДокументОбъект.ПоступлениеТоваровУслуг») Тогда
// Изменим ширину поля «СпособЗачетаАвансов»
Форма.ЭлементыФормы.СпособЗачетаАвансов.Ширина = 70;
//Добавим надпись, которая будет меняться в зависимости от типа справочника («СтатьиЗатрат» или «ПрочиеДоходыИРасходы»)
НадписьСтатья = ?(ТипЗНЧ(Объект.СтатьяЗатрат)=Тип(«СправочникСсылка.ПрочиеДоходыИРасходы»),«Статья дохода/расхода:»,«Статья затрат:»);
ДобавитьНадпись(Форма,«НадписьСтатья»,Форма.ЭлементыФормы.ПанельКонтрагент,150,48,50,19,Форма.ЭлементыФормы.СпособЗачетаАвансов,Неопределено,НадписьСтатья);
//Добавим поле ввода для выбора статьи
ДобавитьПолеВвода(Форма,«СтатьяЗатрат»,Форма.ЭлементыФормы.ПанельКонтрагент,Истина,200,48,100,19,Форма.ЭлементыФормы.НадписьСтатья,Форма.ЭлементыФормы.ПанельКонтрагент,«СтатьяЗатрат»,Истина,Истина);
//Добавим действие «СтатьяПриИзменении» для изменения надписи
НовоеДействие = Новый Действие(«СтатьяПриИзменении»);
//Закрепим это действие за нашим полем ввода «СтатьяЗатрат»
форма.ЭлементыФормы.СтатьяЗатрат.УстановитьДействие(«ПриИзменении»,НовоеДействие);
КонецЕсли;
КонецПроцедуры
В первую очередь мы поменяем ширину поля «СпособЗачетаАвансов», затем выведем надпись, которая тоже будет изменяться в зависимости от типа выбранного реквизита (в нашем случае это либо «СправочникСсылка.СтатьиЗатрат» либо «СправочникСсылка.ПрочиеДоходыИРасходы»).
После чего добавляем поле ввода «СтатьяЗатрат» и связываем с ним действие «СтатьяЗатратПриИзменении», которое отвечает за то, чтобы изменялась надпись при изменении типа статьи затрат.
Теперь необходимо в модуле формы добавить вызов нашей процедуры а также процедуру «СтатьяПриИзменении», чтобы наш механизм заработал:
Процедура ПриОткрытии()
…
…
//Добавляем вызов нашей процедуры
_Формы.ДорисоватьРеквизитыФорм(ЭтаФорма,ЭтотОбъект);
//КонецДобавления
КонецПроцедуры
Процедура СтатьяПриИзменении(Элемент)
Если ТипЗНЧ(ЭлементыФормы.СтатьяЗатрат.Значение)=Тип(«СправочникСсылка.ПрочиеДоходыИРасходы») Тогда
ЭлементыФормы.НадписьСтатья.Значение = «Статья дохода/расхода:»;
Иначе
ЭлементыФормы.НадписьСтатья.Значение =«Статья затрат:»;
КонецЕсли;
КонецПроцедуры
Вот так будет выглядеть документ после наших доработок:
Теперь останется создать подписку на событие «ОбработкаПроведения», выбрать в качестве источника документ «ПоступлениеТоваровУслуг» и написать процедуру добавления проводки на списание номенклатуры.
После такого внесения изменений в форму при следующем обновлении конфигурации через меню «Поддержка->Обновить конфигурацию» мы на 99% вообще не сталкнемся с проблемами. Т.к. модуль формы «ПриОткрытии» практически никогда не меняется.
Но даже если он поменяется, то не составит особого труда добавить в него одну строку кода:
//Добавляем вызов нашей процедуры
_Формы.ДорисоватьРеквизитыФорм(ЭтаФорма,ЭтотОбъект);
//КонецДобавления
То же самое можно сделать и с формой списка документов и справочников.
Надеюсь, эти нехитрые советы помогут Вам значительно ускорить процесс обновления доработанной типовой конфигурации.
P.S. Все эти приемы будут работать на платформе 8.1. и 8.2 (обычные формы)
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Не совсем понятно. При изменении конфигурации поставщика в этом объекте, он все равно заменится вместе с формой и модулем формы. Т.е. изменять модуль формы придется в любом случае. Вот только затраты на написание динамических элементов куда выше, чем размещение на форме реквизита. Поясните пожалуйста.
Объясню свою критику:
1. Если уж рассматривать правильности изменения в типовые конфигурации, то я бы написал о правильном добавлении ролей, интерфейсов, реквизитов объектов метаданных, модулей, форм. Там много интересных правил.
2. При создании динамических реквизитов формы, вы переводите их в разряд неявных. Особенно если их видимость зависит от других условий. Чем вводите в ступор других разработчиков, которые вместо 1минуты размещения уже своего реквизита, вынуждены разбираться в чужом коде или моделировать ситуации.
3. Вы сами можете врезаться в появление реквизитов типовой конфигурации по условиям. Вызвав безобразие на экране.
4. Некоторые документы очень сложны. Мне приходилось тратить множество времени на размещение реквизитов например в Отчете производства за смену, там несколько вариантов документа и сам реквизит нужно размещать несколько раз и дотошно его настраивать в разных функциях видимости в нескольких местах. В случае динамического размещения реквизита, это заняло бы кучу времени, как мне объяснить заказчику такое?
5. Если уж предлагать решение, то модуль целиком. Готовый, с указанными параметрами для расположения, родителями на форме, сервисом и т.д. Чтобы его можно использовать не только для расположения, а для всего спектра управления динамическими элементами.
(0) Методика переопределения и вызова обработчиков событий формы в 1С 8
(1) Если производить обновление не сравнением CF, а указанным мной способом через меню Поддержка-> Обновить конфигурацию, то обновление происходит не целиком ФОРМЫ, а помодульно. И 1С сама проставит нужные галочки и действия напротив каждого модуля. Если Вы не знакомы с этой технологией, почитайте вот эту статью:
Т.е. если в процедуре «ПриОткрытии» модуля формы нашего документа не будет изменений между старой и новой конфигурацией поставщика, то этот модуль останется в том виде в каком он и был на момент обновления (т.е. со строкой вызова нашей процедуры.)
А модуль «СтатьяПриИзменении» , который мы добавили ВСЕГДА будет находиться в форме этого объекта.
Насчет вашей критики:
1. Насчет добавления метаданных — думаю тема не заслуживает внимания т.к. с ними никогда не возникает проблем если использовать свой стиль наименования реквизитов. Например Наш_Реквизит1, Наш_Реквизит2. Что позволит избежать одинаковых наименований реквизитов в случае появления их со стороны 1С
2. Не соглашусь. Скорее наоборот, если разработчик поймет, что все действия с элементами форм происходят всего лишь в одном общем модуле, то он сделает аналогично.
3. Для устранения возможных проблем всегда можно добавить свою страницу и размещать все свои реквизиты там. Этот способ никогда не вызовет кракозябров.
Даже если не размещать реквизиты на отдельной странице и они вдруг наложатся с новыми реквизитами от 1С, это все равно быстрее исправить в коде, нежели сидеть и заново их вставлять физически в форму (причем это можно сделать только на глаз), устанавливать привязки, порядок обхода и т.д….
4. См. п.3.
5. Не вижу особого смысла выкладывать модуль целиком из-за слишком большого разнообразия задач. Я старался донести сам принцип…
(3) Elgrego,
Ничего, что слова «со строкой вызова нашей процедуры» и «не будет изменений между старой и новой конфигурацией поставщика» взаимосключают друг друга? Или вы отсылаете поставщику все ваши изменения? )
По поводу динамического добавления реквизитов — согласен с автором полностью — затраты на динамическое добавление при соблюдении определенной процедуры (типовые процедурки работы с формой в общих модулях, например) вполне окупают себя, так как не приходится работать с кашей элементов управления на форме, которую генерит сравнение/объединение, в каком бы виде оно не производилось — обновление ли или просто сравнение.
(4) AlX0id, Видимо, вы тоже не знакомы с этой публикацией:
Рекомендую.
Попытайтесь вдуматься в смысл «различия между старой и новой конфигурацией ПОСТАВЩИКА».
Ни в старой ни в новой конфигурации поставщика нет нашей строки
(3) Elgrego, По порядку:
0. Самые ходовые документы постоянно модифицируются, каждые 5 релизов точно. И форма меняется тоже, и летит вся система. Я за свои 12 лет программирования 1С уже перепробовал все подходы.
1. Я вообще не про это писал. Я писал про общие правила модификации типовых конфигураций. При чем тут названия реквизитов?
2. Другой разработчик никогда не будет тратить время на изучение ваших мудрствований, а сделает как быстро. Он деньги зарабатывает, а не оптимизирует вашу разработку.
3. Вот вот, своя закладка, там свои реквизиты. Но тогда уже давным давно есть технология, позволяющая копировать реквизиты, их порядок и настройки, с другой формы, которая спокойно подлежит вертикальному изменению. На ней проще и понятней работать другим разработчикам. Но! Заказчику всегда всё нужно перед глазами, под рукой. И никто Вас не защитит от размещения нового реквизита самой 1С, и понеслось, куча времени, безобразие, и восприятие «вашей квалификации» на самом дне 🙂
4. Бред. Разместите свои реквизиты, а потом заставьте их жить вместе со схемой жизни самой формы. Куча переменных, догадки, домыслы… А как, почему тут так? Кому это всё надо?
5. Сам принцип хоть и удобный, но годится только для поддержки в однорепье несложной конфигурации. Почему пишу, потому что уже много раз встречал такое. Разрушенные формы, неработающие реквизиты.
(5) Elgrego,
Читал.
Если заменять на свои обработчики — да, согласен. Хотя, честно говоря, не вижу особой в том надобности по причинам:
1. Не так сложно отследить свой правильно закомментированный код в чужом обработчике и сделать MRG после сравнения.
2. Необходимость анализировать взаимодействие своего и чужого кода в одном и том же обработчике все равно не отпадает, а вот наличие факта взаимодействия становится не таким явным.
Мне убегать уже пора. Вкратце еще.
Elgrego, нужно не тыкать других собеседников в «незнание».
Если предлагаете систему, то писать о пользе, и недостатках. Где и как можно применять, а где нельзя.
Описывать нюансы технологии, давать людям сервис и учить на конкретных разработках.
Вы же добьетесь только того, что оголтелая школота рванет делать, как «правильно» (по вашему). Но огребать кренделей будут они, а не вы.
А технология создания динамических реквизитов формы описана просто везде, даже тут полно разработок, существует уже давно. Все идеи уже были высказаны ранее многократно.
Ребят, я писал не про замену обработчиков событий на уже имеющихся реквизитах, а о добавлении новых.
(6) видимо мы с вами разговариваем на разных языках. Я говорил сейчас о ситуации, когда конкретной конфигурацией занимается конкретный программист. И именно для него я написал эти приемы дабы сократить время обновления. А не для случая, когда вы 1 раз пришли к какому то заказчику, что то добавили и забыли про него…
Так вот, работая по этой схеме более 3-х лет с конфигурациями Бух и ЗУП, могу сказать следующее — пришлось 1 раз изменить привязку в форме одного объекта. Это все! Надо просто включать мозг и правильно размещать свои реквизиты. Т.к. добавление реквизитов самой 1С как правило происходит либо вниз формы либо в правый край, либо на новую страницу… И крайне редко изменяется общий вид формы.
(9) Elgrego, воооооооооот. Об этом и писать в обязательном порядке. А то, я как представил своих такое делающих во франче, и как я их потом…
(10) Я так и понял 🙂
(9) Elgrego,
Яаааа фиг знает.. может быть, в Бух и ЗУП действительно все прекрасно.. Но по опыту обновления УПП — даже если взять недавний релиз 1.3.27.4, то только навскидку могу вспомнить добавление реквизитов договора и номенклатуры в середину формы.. А уж сколько клиентов просят добавить реквизиты к этим справочникам — не пересчитать. Я, конечно, стараюсь всех отправить к свойствам и категориям, но удается далеко не всегда..
(12) AlX0id, В этом случае только добавление отдельной страницы спасет
(13) Elgrego,
Спору нет — так и делаю обычно )
В принципе приходится подходить к каждому случаю индивидуально: для одного реквизита — так и вовсе кнопку на командной панели выводил ))
(0) при переопределении обработчика динамически добавленного ЭУ все равно нужно писать в модуле формы вызов процедуры обработчика. Либо — строить непростую схему из (2) по «динамическому» переопределению обработчиков.
А вообще весь сыр-бор — из-за того, что 1С неспособна реализовать ООП и обращение к УЭ и их событиям из любого места кода, а также неспособна реализовать механизм программного переопределения событий существующих ЭУ.
(14) AlX0id,
Кнопку для реквизита? сильно.
Посвятили бы ему отдельную форму тогда, что ли, с заголовком и эпитафией :))
(15) AlexO, Не спорю, что нужно писать процедуру в модуле формы. Но при обновлении через Поддержка->Обновить конфигурацию эта процедура всегда останется на месте т.к. этого модуля нет и не будет в конфигурации поставщика. Следовательно, это нисколько не повлияет на обновление конфы
(17) Elgrego,
сейчас очень часто меняют модуль формы документов в 1С, а по-процедурно заменять текст модуля (казалось бы, в чем проблема сравнить два тектстовика по тегам и сделать из двух одно?) 1С за 20 лет так и не научилась.
Поэтому все равно приходится востанавливать изменения.
(16) AlexO,
А чо нет-то? ) Реквизит тот нужен был только для чтения и во многих документах с разнообразными формами, а более универсальной вещи, нежели командная панель формы — еще поискать.. Вот и добавил кнопку командной панели без обработчика ) На универсальность идеи не претендую, но право на существование имеет, имхо.
З.Ы. Программно разумеется.
(18) AlexO,
Поэтому все равно приходится востанавливать изменения.
Слегка не понял Вашу мысль. 1С уже давно умеет сравнивать текст помодульно при обновлении через поддержку, начиная с версии 8.0.
. На картинке, в колонке «Режим объединения» вы видите возможные варианты действий с данной процедурой модуля. Проблемы возникают только тогда, когда в одну и ту же процедуру модуля внесены изменения как 1С так и разработчиком. В этом случае Вам решать что делать. Так как здесь нельзя оставить и то и другое, потому что они могут взаимоисключать друг друга. Поэтому, я, как правило, оцениваю объем своих изменений и изменений 1С. Чьих больше — те и оставляю.
Если Вы имели ввиду вопрос, почему 1С сама не делает эту работу за нас, то я на стороне 1С. Т.к. порой код поставщика меняется настолько радикально, что свои собственные изменения становятся абсолютно неактуальны…
Я раньше тоже страдал всякими заморочками на эту тему. Потом понял, что заказчику на это пофиг, а себе только жизнь усложнять высчитывая пикселы, привязки и т.д. Хотя и есть способы облегчения этого процесса, я знаю. Проще и надежнее всего разместить реквизит на форме и в модуле написать комментарий, что, где, и зачем было изменено в диалоге. При обновлении вряд ли это сильно увеличит трудозатраты. Максимум на один час, в худшем случае на два.
(21) Armando, Позвольте не согласиться.
Если у Вас многолетние наработки по заявкам пользователей, которые касаются практически каждого документа в той или иной степени, то вы засядете на недельку-другую, уж поверьте.
А в случае применения этой технологии все обновление будет заключаться в проверке работоспособности форм уже ПОСЛЕ самого обновления. И, как правило, доработок не потребуется, если форма не была изменена кардинально.
Т.е. это позволяет вообще не анализировать изменения в форме поставщика на этапе обновления. Самое страшное, что может случиться — перекрытие вашим реквизитом какого то реквизита 1С.
Вот представляю ситуацию:
Есть база. Первый раз ее вижу. Надо обновить. Сравниваю. Вижу, что есть изменения в форме между конфигурациями поставщика, и между старой конфигурацией поставщика и текущей конфигурацией базы. Мои действия?
Отчет по сравнению показывает, что поставщик что-то накуралесил в форме. А в клиентской конфигурации вижу
Ладно, лезу в этот модуль, нахожу нужный блок кода. И что дальше? Как понять, что видел в диалоге заказчик, и что он увидит после обновления? Как понять, что нужно изменить, что бы все было на своих местах?
(23) Armando, Вы путаете понятия изменения в форме и изменения в модуле формы. Так вот, изменения на самой форме я не смотрю вообще. А чтобы понять что было на форме, достаточно открыть рабочую базу в режиме предприятияи посмотреть. Тем более, что в нашем общем модуле перечислены все добавленные элементы. Их очень просто найти на форме в режиме предприятия. А понять что надо будет делать можно уже после обновления, открыв эту форму в рабочем режиме. Но как правило делать ничего не приходится.
Например, если перед добавлением реквизита слегка изменить размеры самой формы, и положение панелей, чтобы появилось необходимое пространство для добавления нашего реквизита. Или вынести их на отдельную страницу. И т.д.
Я уже не говорю о добавлении реквизита в форме списка.
Повторюсь, эта публикация адресована тем программистам, которые закреплены за конкретной БД. А не тем, которые работают франчайзи. Согласитесь, у них разные задачи.
В каком месте я перепутал? У Вас проблемы с восприятием информации.
Я пока все комментарии не прочитал, не узнал об этом.
Оказывается, именно так правильно вносить изменения в типовую. А то, как это делают большинство разработчиков — неправильно.
В результате — это просто один из способов внесения изменений в диалог формы типовой конфы, путем программного добавления контролов, для программистов, закрепленными за определенной БД.
Тему эту за несколько лет уже устали обсасывать. Во многих случаях это действительно упрощает жизнь, в остальных вызывает батхерт. И я бы не стал называть эту методику однозначно правильной.
(25) Armando, Откуда такая агрессия?
Во первых, я не утверждал что именно так правильно делать изменения в принципе. Прочитайте название публикации целиком. Смысл как раз в том, чтобы избавить себя от необходимости ковыряться в формах в момент обновления.
Т.к. зачастую требуется быстро обновить конфигурацию, чтобы не потерять функционал. А возня с формами значительно усложняет весь процесс.
Во вторых я не утверждал, что это единственный способ.
И, наконец, прочитайте сами свою фразу:
Код
_Формы.ДорисоватьРеквизитыФорм(ЭтаФорма,ЭтотОбъект);
Лично я эту фразу не понял абсолютно. Как связаны различия в форме и различия в модуле формы?
Может это не у меня проблемы с восприятием?
Погорячился я)
Здесь я хотел написать, что это в модуле формы.
Один хрен каждый делает как ему удобней.
Честно я за 3 года во франче ни разу не сталкивался с такой методой у клиентов.
Потом три года сидел на фикси. Начал использовать такой способ. Лично мне было неудобно. И форма чуть дольше открывается. Вернул как было.
Сейчас работаю над проектом в команде. С трудом представляю, что будет, если начнем это применять.
(27) Armando,
Принято 🙂
На самом деле, тяжело это делать только первый раз для какого то вида реквизита (поле ввода, надпись, кнопка). В дальнейшем, тупо копируется рабочий код, расставляются привязки и все. А если как следует подумать, то можно эти процедуры делать с привязкой к какому то конкретному (уже имеющемуся) реквизиту на форме и передавать его в качестве параметра. А также размер и смещение в пикселях относительно типового.
Но в этом случае будет проблема если 1С его когда нибудь удалит 🙂 Так что если вы уверены в каком то реквизите, то привязываетесь к нему и гарантия почти 100%, что ничего править не придется.
Я своих научил, им понравилось. Теперь эта процедура занимает от силы 5 минут.
(19) AlX0id,
а зачем реквизиту ттолько для чтения еще и кнопка, да еще без обработчика? 🙂
в чем уж её такая универсальность?
Хоть пример свой разверните, а то непонятно совсем, что за задача стояла 🙂
(20) Elgrego,
во-первых, этот режим надо включать через большую «ж».
Во-вторых — если я уверен, что мой код ДОПОЛНЯЕТ типовой и не конфликтует с ним (да даже если и конфликтует — вот и посморим на тестовой, к чему приведет одновременная работа) — почему неможно нормально объединить по тегам (обычно внутри конструкций языка редко меняют, пишут свое рядом — а если и внутри, то тоже нестрашно, пусть отслеживает хотя бы элементарное соответствие синтаксису после объединения) разные конструкции?
ну так вот давайте я и решу, взаимоисключают они там друг друга, дополняют или вообще нужно сделать MERGE с закомменчиванием.
… и потом довносите все ручками. О чем и пишу.
не знаю, что там у вас за изменения, но мои изменения живут годами из-за дурости и тупоупрямства 1С…
Например, еще сделанное мной элементарные операции с выводом макета в УПП 1.1 так и не реализовано до сих пор в 1.3.
(31) artbear,
верно 🙂
но там тоже инструмент с недочетами делает автокод — почему я и не делаю отдельных «универсальных» процедур для создания элементов (привязки там «забывает», нюансы использования Данные в ПолеВвода и прочая казуистика от 1С). У 1С всегда так — все уникально, раз на раз не приходится, уж лучше сделать отдельно и перепроверить (и поправить где нужно), чем положиться на «автомат» и получить 1с-дулю…
(30) AlexO, Что Вы имеете ввиду под большой Ж? 🙂
Для включения этого режима достаточно иметь актуальную конфигурацию поставщика на момент обновления. Не думаю, что это большая проблема.
Так вот и решайте 🙂 1С вставит этот ВАШ код с тегом MRG, если вы не будете ничего трогать.
Если вы уверены что все правильно, просто находите тег и удаляете коммент.
На мой взгляд, самое оптимальное решение.
Не знаю какой опыт у Вас, но мне несколько десятков раз приходилось обновлять конфигурации, которые не обновляли годами. Не говоря уже о ситуации, когда в корне меняется логика программы. Например, перевод конфигурации ЗУП с 2.1 на 2.5 и т.д.
Это были ответы на Ваши вопросы.
Но в описанной мной технологии, к счастью, придется проанализировать всего одну процедуру модуля формы объекта «ПриОткрытии» и убедиться в наличии 1 строки с вызовом необходимой процедуры. Думаю, это легче чем проанализировать изменения на форме.
(33) artbear,
Полностью с Вами согласен 🙂
Но я в своей публикации не преследовал цель сделать все за программиста…
Я преследовал несколько иную цель — научить молодое поколение думать прежде чем что-то делать.
Для того, чтобы добавить реквизит на форму обычными средствами, много ума не надо, хотя некоторые даже с этим не справляются — забывают привязать обработчик, оформить привязки и прочее…
Даже используя инструмент, о котором Вы говорите, все проблемы не решаются. В свое время тоже загонялся этими механизмами. Был несколько разочарован…
В итоге пришел к выводу, что нужно просто включать мозг при добавлении реквизита. Остальное — компромисс.
Никто еще не смог изобрести достойный механизм анализа расхождений в неуправляемых формах.
P.S. Это только мое мнение. На истину в последней инстанции не претендую 🙂 Надоело доказывать что я не верблюд 🙂
Скоро — совсем скоро подобные темы уйдут в небытие, с БСП и их дополнительными реквизитами и свойствами.
Я там где дорабатываю модули ставлю в начале свою фамилию, в завершение три звездочки, потом проще искать.
Пример с изменением типового кода:
//Ткачев
// Если Стр.РазмерДанных > 6 Тогда
Если Стр.РазмерДанных > 10 Тогда
//***
А в чем легче потом… При обновлении?
(38) Воронкин,
Да, изменения могут затереться и потом с копии легко можно будет найти что где менял.
(35) Elgrego, не вижу в предложенном вами варианте никагого упрощения.
Если при обновлении в настройках фильтра поставить флаг «Показывать только дважды измененные свойства», то вы увидите какие из форм изменены (to8_img11.png).
А отчете сравнения объектов можно «Показать различия графически». В 1С 8.2 точно есть, про более ранние версии точно не скажу(Безымянный.png).
(40) kereo, На мой взгляд, я достаточно подробно объяснил, что в случае применения этой технологии сами формы (элементы управления) анализировать вообще не придется. В этом и есть облегчение.
То что вы увидите эти расхождения в отчете о сравнении, не избавляет Вас от необходимости вносить эти изменения повторно.
(0) Проще доп страницу с нужными реквизитами добавить, если есть такая возможность, а не текущие двигать.
Или кнопку типа свойств объектов для редактирования своих доп. реквизитов (типа такого .
А так обычные формы конечно быстрее обновлять.
Сам давно пришел к необходимости программно располагать элементы. Правда, с моей точки зрения,выигрыш получается только в случае небольшого количество добавляемых элементов (до 5-10). Если получается больше, то проще словить и перенести при обновлении
(44) AlexBar, Прежде чем писать, пробовал найти нечто подобное. К сожалению, не нашел 🙂 Идею с комментарием оценил. Спс.
(43) если больше, проще добавить в прикладной объект еще одну форму (она будет сохраняться при объединениях) и переносить из нее программно, один раз написав функцию. Ручной труд — для мартышек.
Когда освоите эту тему, автоматизируйте дальше парсером, чтобы не ручками вставлять обновления в код:
Подход известный и правильный.
Число параметров ваших процедур глаза режет, структурой лучше передать имхо.
(49) all_i_ance, Такие большие комментарии лучше выделять в отдельную статью. А так молодец!
как и обычно при обновлении все свои модификации придется ручками поправлять!
Значит задача следующая — реализовать дополнительную аналитику в некоторых документах.
Как правило в ПриОткрытии() документа — есть вызов стратегии редактирования номера документа. Собственно туда дописываем:
Если В реквизитах шапки есть реквизит _ВидДополнительнойАналитики_ тогда на форме уменьшаем в пополам реквизит комментарий, и в появившееся место вставляем Надпись и реквизит.
Теперь достаточно в нужные документы вставить _ВидДополнительнойАналитики_ в шапку.
Обновляется за секунды. Минимальные изменения. Необходимая аналитика — присутствует.
Как по мне — искать в конфигурациях нужно именно подобные универсальные места.
Или ждать от разработчиков — расширения видов событий для подписки на событие…
Дорогой автор!
Очарована вашей идеей! Обязательно возьму на вооружение.
Подскажите, есть ли у вас стандартная процедура добавления нового поля ввода — колонки в таблицу документа. Или нужно модифицировать процедуру ДобавитьПолеВвода(Форма,ИмяРекв,Панель,Доступность,Л,В,Ш,Выс,ПривязкаЛев,ПривязкаПрав,Данные,КнВыбора,КнОткрытия)
убрав привязки?
(53) Vida, Спасибо за понимание 🙂
Конечно есть. Вот примерный ее текст:
Процедура ДорисоватьПолеВводаТЧ(Форма, Панель, Страница, ИмяТЧ, ИмяРеквизита, Заголовок, НомерКолонки, Флажок, Ширина) Экспорт
Колонка = Форма.ЭлементыФормы[ИмяТЧ].Колонки.Вставить(НомерКолонки, Заголовок);
Колонка.Имя = Заголовок;
Колонка.Ширина = Ширина;
Колонка.Данные = ИмяРеквизита;
Колонка.Доступность = Истина;
Колонка.Видимость = Истина;
Колонка.УстановитьЭлементУправления(Тип(«ПолеВвода»));
Колонка.ИзменениеРазмера = ИзменениеРазмераКолонки.НеИзменять;
Колонка.РежимРедактирования = РежимРедактированияКолонки.Непосредственно;
Колонка.ЭлементУправления.КнопкаВыбора = Истина;
Колонка.ЭлементУправления.КнопкаОчистки = Истина;
КонецПроцедуры
Есть у нас похожая разработка, только один плюс, в ПриОткрытии() ни чего дописывать нет необходимости.
(55) Это которая псевдоподписка ПриОткрытии?
насколько я помню ПриОткрытии нет подписки, у нас все это дело вмонтировано в МеханизмНумерацииОбъектов
(57) я об этом
у Вас как я понял другое
(58) aet, да, Вы правы, так и есть
(40) Полностью согласен, реквизит и так должен отработать.