gifts2017

Как правильно вносить изменения в типовую конфигурацию для легкого ее обновления в дальнейшем

Опубликовал Игорь Маркин (Elgrego) в раздел Администрирование - Системное

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

Прием №1: добавление реквизитов на форму программными средствами.

Задача знакома многим разработчикам. Заказчик хочет видеть какой то свой реквизит в форме объекта (документа/справочника).

Для примера возьмем документ "ПоступлениеТоваровУслуг" (конфигурация Бухгалтерия предприятия 2.0) и реквизит СтатьяЗатрат, который надо добавить в шапку. Смысл этого реквизита в том, что если он заполнен, то необходимо автоматически списать эти товары/услуги на счет затрат.

Сначала добавим этот реквизит в метаданные документа:

Добавление метаданных

 

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

 Форма документа

Как видно на рисунке выше, на форме документа практически отсутствует свободное место для размещения реквизитов. Тем не менее, мы можем программным способом слегка изменить размеры/ место расположение уже размещенных типовых реквизитов. Для удобства создадим некий общий модуль "_Формы" в который будем помещать процедуры, связанные с изменением форм любых объектов метаданных. Для начала, добавим несколько стандартных процедур:


&НаКлиенте

Процедура ДобавитьПолеВвода(Форма,ИмяРекв,Панель,Доступность,Л,В,Ш,Выс,ПривязкаЛев,ПривязкаПрав,Данные,КнВыбора,КнОткрытия) Экспорт

   
Реквизит = Форма.ЭлементыФормы.Добавить(Тип("ПолеВВода"),ИмяРекв,Истина,Панель);

   
Реквизит.Данные = Данные;

   
Реквизит.Лево = Л;

   
Реквизит.Верх = В;

   
Реквизит.Ширина = Ш;

   
Реквизит.Высота = Выс;

   
Реквизит.УстановитьПривязку(ГраницаЭлементаУправления.Лево, ПривязкаЛев, ГраницаЭлементаУправления.Право);

   
Реквизит.УстановитьПривязку(ГраницаЭлементаУправления.Право, ПривязкаПрав, ГраницаЭлементаУправления.Право);

   
Реквизит.КнопкаВыбора = КнВыбора;

   
Реквизит.КнопкаОткрытия = КнОткрытия;

   
Реквизит.Доступность = Доступность;

КонецПроцедуры



&НаКлиенте

Процедура ДобавитьКнопку(Форма,ИмяРекв,Панель,Л,В,Ш,Выс,ПривязкаЛев,ПривязкаПрав,Заголовок,Картинка) Экспорт

   
Реквизит = Форма.ЭлементыФормы.Добавить(Тип("Кнопка"),ИмяРекв,Истина,Панель);

   
Реквизит.Заголовок = Заголовок;

   
Реквизит.Лево = Л;

   
Реквизит.Верх = В;

   
Реквизит.Ширина = Ш;

   
Реквизит.Высота = Выс;

   
Реквизит.УстановитьПривязку(ГраницаЭлементаУправления.Лево, ПривязкаЛев, ГраницаЭлементаУправления.Право);

   
Реквизит.УстановитьПривязку(ГраницаЭлементаУправления.Право, ПривязкаПрав, ГраницаЭлементаУправления.Право);

    Если
Картинка<>Неопределено Тогда

       
Реквизит.Картинка = Картинка;

    КонецЕсли;

КонецПроцедуры



&НаКлиенте

Процедура ДобавитьНадпись(Форма,ИмяРекв,Панель,Л,В,Ш,Выс,ПривязкаЛев,Данные,Текст)

   
Реквизит = Форма.ЭлементыФормы.Добавить(Тип("Надпись"),ИмяРекв,Истина,Панель);

    Если
ЗначениеЗаполнено(Данные) Тогда

       
Реквизит.Данные = Данные;

    КонецЕсли;

   
Реквизит.Лево = Л;

   
Реквизит.Верх = В;

   
Реквизит.Ширина = Ш;

   
Реквизит.Высота = Выс;

   
Реквизит.УстановитьПривязку(ГраницаЭлементаУправления.Лево, ПривязкаЛев, ГраницаЭлементаУправления.Право);

   
Реквизит.УстановитьПривязку(ГраницаЭлементаУправления.Право, Реквизит, ГраницаЭлементаУправления.Лево);

   
Реквизит.Значение = Текст;

КонецПроцедуры

Теперь добавим в этот же модуль обработку нашего случая:

 


&НаКлиенте

Процедура ДорисоватьРеквизитыФорм(Форма,Объект = Неопределено) Экспорт

    Если
ТипЗНЧ(Объект) = Тип("ДокументОбъект.ПоступлениеТоваровУслуг") Тогда

       
// Изменим ширину поля "СпособЗачетаАвансов"

       
Форма.ЭлементыФормы.СпособЗачетаАвансов.Ширина = 70;

       
//Добавим надпись, которая будет меняться в зависимости от типа справочника ("СтатьиЗатрат" или "ПрочиеДоходыИРасходы")

       
НадписьСтатья = ?(ТипЗНЧ(Объект.СтатьяЗатрат)=Тип("СправочникСсылка.ПрочиеДоходыИРасходы"),"Статья дохода/расхода:","Статья затрат:");

       
ДобавитьНадпись(Форма,"НадписьСтатья",Форма.ЭлементыФормы.ПанельКонтрагент,150,48,50,19,Форма.ЭлементыФормы.СпособЗачетаАвансов,Неопределено,НадписьСтатья);

       
//Добавим поле ввода для выбора статьи

       
ДобавитьПолеВвода(Форма,"СтатьяЗатрат",Форма.ЭлементыФормы.ПанельКонтрагент,Истина,200,48,100,19,Форма.ЭлементыФормы.НадписьСтатья,Форма.ЭлементыФормы.ПанельКонтрагент,"СтатьяЗатрат",Истина,Истина);

       
//Добавим действие "СтатьяПриИзменении" для изменения надписи

       
НовоеДействие = Новый Действие("СтатьяПриИзменении");

       
//Закрепим это действие за нашим полем ввода "СтатьяЗатрат"

       
форма.ЭлементыФормы.СтатьяЗатрат.УстановитьДействие("ПриИзменении",НовоеДействие);

    КонецЕсли;

КонецПроцедуры

 

В первую очередь мы поменяем ширину поля "СпособЗачетаАвансов", затем выведем надпись, которая тоже будет изменяться в зависимости от типа выбранного реквизита (в нашем случае это либо "СправочникСсылка.СтатьиЗатрат" либо "СправочникСсылка.ПрочиеДоходыИРасходы").

После чего добавляем поле ввода "СтатьяЗатрат" и связываем с ним действие "СтатьяЗатратПриИзменении", которое отвечает за то, чтобы изменялась надпись при изменении типа статьи затрат.

Теперь необходимо в модуле формы добавить вызов нашей процедуры а также процедуру "СтатьяПриИзменении", чтобы наш механизм заработал:

 


Процедура ПриОткрытии()

    ...



    ...



   
//Добавляем вызов нашей процедуры

   
_Формы.ДорисоватьРеквизитыФорм(ЭтаФорма,ЭтотОбъект);

   
//КонецДобавления

КонецПроцедуры



Процедура
СтатьяПриИзменении(Элемент)

    Если
ТипЗНЧ(ЭлементыФормы.СтатьяЗатрат.Значение)=Тип("СправочникСсылка.ПрочиеДоходыИРасходы") Тогда

       
ЭлементыФормы.НадписьСтатья.Значение = "Статья дохода/расхода:";

    Иначе

       
ЭлементыФормы.НадписьСтатья.Значение ="Статья затрат:";

    КонецЕсли;

КонецПроцедуры

Вот так будет выглядеть документ после наших доработок:

Результат доработок 

 

Теперь останется создать подписку на событие "ОбработкаПроведения", выбрать в качестве источника документ "ПоступлениеТоваровУслуг" и написать процедуру добавления проводки на списание номенклатуры.

После такого внесения изменений в форму при следующем обновлении конфигурации через меню "Поддержка->Обновить конфигурацию" мы на 99% вообще не сталкнемся с проблемами. Т.к. модуль формы "ПриОткрытии" практически никогда не меняется.

Но даже если он поменяется, то не составит особого труда добавить в него одну строку кода:


    //Добавляем вызов нашей процедуры

   
_Формы.ДорисоватьРеквизитыФорм(ЭтаФорма,ЭтотОбъект);

   
//КонецДобавления

 То же самое можно сделать и с формой списка документов и справочников.

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

P.S. Все эти приемы будут работать на платформе 8.1. и 8.2 (обычные формы)

См. также

PowerTools от 1 000
Подписаться Добавить вознаграждение

Комментарии

1. Саня Офигенски (AlexProg) 13.09.12 11:52
Не совсем понятно. При изменении конфигурации поставщика в этом объекте, он все равно заменится вместе с формой и модулем формы. Т.е. изменять модуль формы придется в любом случае. Вот только затраты на написание динамических элементов куда выше, чем размещение на форме реквизита. Поясните пожалуйста.

Объясню свою критику:
1. Если уж рассматривать правильности изменения в типовые конфигурации, то я бы написал о правильном добавлении ролей, интерфейсов, реквизитов объектов метаданных, модулей, форм. Там много интересных правил.
2. При создании динамических реквизитов формы, вы переводите их в разряд неявных. Особенно если их видимость зависит от других условий. Чем вводите в ступор других разработчиков, которые вместо 1минуты размещения уже своего реквизита, вынуждены разбираться в чужом коде или моделировать ситуации.
3. Вы сами можете врезаться в появление реквизитов типовой конфигурации по условиям. Вызвав безобразие на экране.
4. Некоторые документы очень сложны. Мне приходилось тратить множество времени на размещение реквизитов например в Отчете производства за смену, там несколько вариантов документа и сам реквизит нужно размещать несколько раз и дотошно его настраивать в разных функциях видимости в нескольких местах. В случае динамического размещения реквизита, это заняло бы кучу времени, как мне объяснить заказчику такое?
5. Если уж предлагать решение, то модуль целиком. Готовый, с указанными параметрами для расположения, родителями на форме, сервисом и т.д. Чтобы его можно использовать не только для расположения, а для всего спектра управления динамическими элементами.
DmitryZzz; Zeskord; RomanUzmov; Spacer; +4 Ответить 1
2. Сергей Ожерельев (Поручик) 13.09.12 12:12
(0) Методика переопределения и вызова обработчиков событий формы в 1С 8
http://infostart.ru/public/16980/
3. Игорь Маркин (Elgrego) 13.09.12 12:34
(1) AlexProg, Если производить обновление не сравнением CF, а указанным мной способом через меню Поддержка-> Обновить конфигурацию, то обновление происходит не целиком ФОРМЫ, а помодульно. И 1С сама проставит нужные галочки и действия напротив каждого модуля. Если Вы не знакомы с этой технологией, почитайте вот эту статью:
Технология обновления
Т.е. если в процедуре "ПриОткрытии" модуля формы нашего документа не будет изменений между старой и новой конфигурацией поставщика, то этот модуль останется в том виде в каком он и был на момент обновления (т.е. со строкой вызова нашей процедуры.)
А модуль "СтатьяПриИзменении" , который мы добавили ВСЕГДА будет находиться в форме этого объекта.

Насчет вашей критики:
1. Насчет добавления метаданных - думаю тема не заслуживает внимания т.к. с ними никогда не возникает проблем если использовать свой стиль наименования реквизитов. Например Наш_Реквизит1, Наш_Реквизит2. Что позволит избежать одинаковых наименований реквизитов в случае появления их со стороны 1С
2. Не соглашусь. Скорее наоборот, если разработчик поймет, что все действия с элементами форм происходят всего лишь в одном общем модуле, то он сделает аналогично.
3. Для устранения возможных проблем всегда можно добавить свою страницу и размещать все свои реквизиты там. Этот способ никогда не вызовет кракозябров.
Даже если не размещать реквизиты на отдельной странице и они вдруг наложатся с новыми реквизитами от 1С, это все равно быстрее исправить в коде, нежели сидеть и заново их вставлять физически в форму (причем это можно сделать только на глаз), устанавливать привязки, порядок обхода и т.д....
4. См. п.3.
5. Не вижу особого смысла выкладывать модуль целиком из-за слишком большого разнообразия задач. Я старался донести сам принцип...
4. Алексей 1 (AlX0id) 13.09.12 12:44
(3) Elgrego,
Т.е. если в процедуре "ПриОткрытии" модуля формы нашего документа не будет изменений между старой и новой конфигурацией поставщика, то этот модуль останется в том виде в каком он и был на момент обновления (т.е. со строкой вызова нашей процедуры.)

Ничего, что слова "со строкой вызова нашей процедуры" и "не будет изменений между старой и новой конфигурацией поставщика" взаимосключают друг друга? Или вы отсылаете поставщику все ваши изменения? )

По поводу динамического добавления реквизитов - согласен с автором полностью - затраты на динамическое добавление при соблюдении определенной процедуры (типовые процедурки работы с формой в общих модулях, например) вполне окупают себя, так как не приходится работать с кашей элементов управления на форме, которую генерит сравнение/объединение, в каком бы виде оно не производилось - обновление ли или просто сравнение.
5. Игорь Маркин (Elgrego) 13.09.12 12:55
(4) AlX0id, Видимо, вы тоже не знакомы с этой публикацией:
Технология обновления Рекомендую.
Попытайтесь вдуматься в смысл "различия между старой и новой конфигурацией ПОСТАВЩИКА".
Ни в старой ни в новой конфигурации поставщика нет нашей строки
6. Саня Офигенски (AlexProg) 13.09.12 13:04
(3) Elgrego, По порядку:
0. Самые ходовые документы постоянно модифицируются, каждые 5 релизов точно. И форма меняется тоже, и летит вся система. Я за свои 12 лет программирования 1С уже перепробовал все подходы.
1. Я вообще не про это писал. Я писал про общие правила модификации типовых конфигураций. При чем тут названия реквизитов?
2. Другой разработчик никогда не будет тратить время на изучение ваших мудрствований, а сделает как быстро. Он деньги зарабатывает, а не оптимизирует вашу разработку.
3. Вот вот, своя закладка, там свои реквизиты. Но тогда уже давным давно есть технология, позволяющая копировать реквизиты, их порядок и настройки, с другой формы, которая спокойно подлежит вертикальному изменению. На ней проще и понятней работать другим разработчикам. Но! Заказчику всегда всё нужно перед глазами, под рукой. И никто Вас не защитит от размещения нового реквизита самой 1С, и понеслось, куча времени, безобразие, и восприятие "вашей квалификации" на самом дне :)
4. Бред. Разместите свои реквизиты, а потом заставьте их жить вместе со схемой жизни самой формы. Куча переменных, догадки, домыслы... А как, почему тут так? Кому это всё надо?
5. Сам принцип хоть и удобный, но годится только для поддержки в однорепье несложной конфигурации. Почему пишу, потому что уже много раз встречал такое. Разрушенные формы, неработающие реквизиты.
7. Алексей 1 (AlX0id) 13.09.12 13:13
(5) Elgrego,
Читал.
Если заменять на свои обработчики - да, согласен. Хотя, честно говоря, не вижу особой в том надобности по причинам:
1. Не так сложно отследить свой правильно закомментированный код в чужом обработчике и сделать MRG после сравнения.
2. Необходимость анализировать взаимодействие своего и чужого кода в одном и том же обработчике все равно не отпадает, а вот наличие факта взаимодействия становится не таким явным.
8. Саня Офигенски (AlexProg) 13.09.12 13:20
Мне убегать уже пора. Вкратце еще.
Elgrego, нужно не тыкать других собеседников в "незнание".
Если предлагаете систему, то писать о пользе, и недостатках. Где и как можно применять, а где нельзя.
Описывать нюансы технологии, давать людям сервис и учить на конкретных разработках.
Вы же добьетесь только того, что оголтелая школота рванет делать, как "правильно" (по вашему). Но огребать кренделей будут они, а не вы.
А технология создания динамических реквизитов формы описана просто везде, даже тут полно разработок, существует уже давно. Все идеи уже были высказаны ранее многократно.
9. Игорь Маркин (Elgrego) 13.09.12 13:26
Ребят, я писал не про замену обработчиков событий на уже имеющихся реквизитах, а о добавлении новых.
(6) AlexProg, видимо мы с вами разговариваем на разных языках. Я говорил сейчас о ситуации, когда конкретной конфигурацией занимается конкретный программист. И именно для него я написал эти приемы дабы сократить время обновления. А не для случая, когда вы 1 раз пришли к какому то заказчику, что то добавили и забыли про него...
Так вот, работая по этой схеме более 3-х лет с конфигурациями Бух и ЗУП, могу сказать следующее - пришлось 1 раз изменить привязку в форме одного объекта. Это все! Надо просто включать мозг и правильно размещать свои реквизиты. Т.к. добавление реквизитов самой 1С как правило происходит либо вниз формы либо в правый край, либо на новую страницу... И крайне редко изменяется общий вид формы.
10. Саня Офигенски (AlexProg) 13.09.12 13:28
(9) Elgrego, воооооооооот. Об этом и писать в обязательном порядке. А то, я как представил своих такое делающих во франче, и как я их потом...
11. Игорь Маркин (Elgrego) 13.09.12 13:29
12. Алексей 1 (AlX0id) 13.09.12 13:44
(9) Elgrego,
Т.к. добавление реквизитов самой 1С как правило происходит либо вниз формы либо в правый край, либо на новую страницу...

Яаааа фиг знает.. может быть, в Бух и ЗУП действительно все прекрасно.. Но по опыту обновления УПП - даже если взять недавний релиз 1.3.27.4, то только навскидку могу вспомнить добавление реквизитов договора и номенклатуры в середину формы.. А уж сколько клиентов просят добавить реквизиты к этим справочникам - не пересчитать. Я, конечно, стараюсь всех отправить к свойствам и категориям, но удается далеко не всегда..
13. Игорь Маркин (Elgrego) 13.09.12 14:32
(12) AlX0id, В этом случае только добавление отдельной страницы спасет
14. Алексей 1 (AlX0id) 13.09.12 15:04
(13) Elgrego,
Спору нет - так и делаю обычно )
В принципе приходится подходить к каждому случаю индивидуально: для одного реквизита - так и вовсе кнопку на командной панели выводил ))
15. Алекс Ю (AlexO) 13.09.12 15:35
(0) при переопределении обработчика динамически добавленного ЭУ все равно нужно писать в модуле формы вызов процедуры обработчика. Либо - строить непростую схему из (2) по "динамическому" переопределению обработчиков.
А вообще весь сыр-бор - из-за того, что 1С неспособна реализовать ООП и обращение к УЭ и их событиям из любого места кода, а также неспособна реализовать механизм программного переопределения событий существующих ЭУ.
16. Алекс Ю (AlexO) 13.09.12 15:37
(14) AlX0id,
Кнопку для реквизита? сильно.
Посвятили бы ему отдельную форму тогда, что ли, с заголовком и эпитафией :))
17. Игорь Маркин (Elgrego) 13.09.12 16:08
(15) AlexO, Не спорю, что нужно писать процедуру в модуле формы. Но при обновлении через Поддержка->Обновить конфигурацию эта процедура всегда останется на месте т.к. этого модуля нет и не будет в конфигурации поставщика. Следовательно, это нисколько не повлияет на обновление конфы
18. Алекс Ю (AlexO) 13.09.12 16:12
(17) Elgrego,
сейчас очень часто меняют модуль формы документов в 1С, а по-процедурно заменять текст модуля (казалось бы, в чем проблема сравнить два тектстовика по тегам и сделать из двух одно?) 1С за 20 лет так и не научилась.
Поэтому все равно приходится востанавливать изменения.
19. Алексей 1 (AlX0id) 13.09.12 17:11
(16) AlexO,
А чо нет-то? ) Реквизит тот нужен был только для чтения и во многих документах с разнообразными формами, а более универсальной вещи, нежели командная панель формы - еще поискать.. Вот и добавил кнопку командной панели без обработчика ) На универсальность идеи не претендую, но право на существование имеет, имхо.

З.Ы. Программно разумеется.
20. Игорь Маркин (Elgrego) 13.09.12 20:50
(18) AlexO,
сейчас очень часто меняют модуль формы документов в 1С, а по-процедурно заменять текст модуля (казалось бы, в чем проблема сравнить два тектстовика по тегам и сделать из двух одно?) 1С за 20 лет так и не научилась.
Поэтому все равно приходится востанавливать изменения.

Слегка не понял Вашу мысль. 1С уже давно умеет сравнивать текст помодульно при обновлении через поддержку, начиная с версии 8.0. . На картинке, в колонке "Режим объединения" вы видите возможные варианты действий с данной процедурой модуля. Проблемы возникают только тогда, когда в одну и ту же процедуру модуля внесены изменения как 1С так и разработчиком. В этом случае Вам решать что делать. Так как здесь нельзя оставить и то и другое, потому что они могут взаимоисключать друг друга. Поэтому, я, как правило, оцениваю объем своих изменений и изменений 1С. Чьих больше - те и оставляю.
Если Вы имели ввиду вопрос, почему 1С сама не делает эту работу за нас, то я на стороне 1С. Т.к. порой код поставщика меняется настолько радикально, что свои собственные изменения становятся абсолютно неактуальны...
21. Armando Armando (Armando) 13.09.12 21:22
Я раньше тоже страдал всякими заморочками на эту тему. Потом понял, что заказчику на это пофиг, а себе только жизнь усложнять высчитывая пикселы, привязки и т.д. Хотя и есть способы облегчения этого процесса, я знаю. Проще и надежнее всего разместить реквизит на форме и в модуле написать комментарий, что, где, и зачем было изменено в диалоге. При обновлении вряд ли это сильно увеличит трудозатраты. Максимум на один час, в худшем случае на два.
Новенький_2209; AlexProg; +2 Ответить 1
22. Игорь Маркин (Elgrego) 13.09.12 21:32
(21) Armando, Позвольте не согласиться.
Если у Вас многолетние наработки по заявкам пользователей, которые касаются практически каждого документа в той или иной степени, то вы засядете на недельку-другую, уж поверьте.
А в случае применения этой технологии все обновление будет заключаться в проверке работоспособности форм уже ПОСЛЕ самого обновления. И, как правило, доработок не потребуется, если форма не была изменена кардинально.
Т.е. это позволяет вообще не анализировать изменения в форме поставщика на этапе обновления. Самое страшное, что может случиться - перекрытие вашим реквизитом какого то реквизита 1С.
23. Armando Armando (Armando) 13.09.12 22:56
Вот представляю ситуацию:
Есть база. Первый раз ее вижу. Надо обновить. Сравниваю. Вижу, что есть изменения в форме между конфигурациями поставщика, и между старой конфигурацией поставщика и текущей конфигурацией базы. Мои действия?
Отчет по сравнению показывает, что поставщик что-то накуралесил в форме. А в клиентской конфигурации вижу
_Формы.ДорисоватьРеквизитыФорм(ЭтаФорма,ЭтотОбъект);

Ладно, лезу в этот модуль, нахожу нужный блок кода. И что дальше? Как понять, что видел в диалоге заказчик, и что он увидит после обновления? Как понять, что нужно изменить, что бы все было на своих местах?
24. Игорь Маркин (Elgrego) 13.09.12 23:51
(23) Armando, Вы путаете понятия изменения в форме и изменения в модуле формы. Так вот, изменения на самой форме я не смотрю вообще. А чтобы понять что было на форме, достаточно открыть рабочую базу в режиме предприятияи посмотреть. Тем более, что в нашем общем модуле перечислены все добавленные элементы. Их очень просто найти на форме в режиме предприятия. А понять что надо будет делать можно уже после обновления, открыв эту форму в рабочем режиме. Но как правило делать ничего не приходится.
Например, если перед добавлением реквизита слегка изменить размеры самой формы, и положение панелей, чтобы появилось необходимое пространство для добавления нашего реквизита. Или вынести их на отдельную страницу. И т.д.
Я уже не говорю о добавлении реквизита в форме списка.
Повторюсь, эта публикация адресована тем программистам, которые закреплены за конкретной БД. А не тем, которые работают франчайзи. Согласитесь, у них разные задачи.
25. Armando Armando (Armando) 14.09.12 10:58
Armando, Вы путаете понятия изменения в форме и изменения в модуле формы.

В каком месте я перепутал? У Вас проблемы с восприятием информации.
Повторюсь, эта публикация адресована тем программистам, которые закреплены за конкретной БД

Я пока все комментарии не прочитал, не узнал об этом.

Оказывается, именно так правильно вносить изменения в типовую. А то, как это делают большинство разработчиков - неправильно.
В результате - это просто один из способов внесения изменений в диалог формы типовой конфы, путем программного добавления контролов, для программистов, закрепленными за определенной БД.
Тему эту за несколько лет уже устали обсасывать. Во многих случаях это действительно упрощает жизнь, в остальных вызывает батхерт. И я бы не стал называть эту методику однозначно правильной.
26. Игорь Маркин (Elgrego) 14.09.12 12:41
(25) Armando, Откуда такая агрессия?
Во первых, я не утверждал что именно так правильно делать изменения в принципе. Прочитайте название публикации целиком. Смысл как раз в том, чтобы избавить себя от необходимости ковыряться в формах в момент обновления.
Т.к. зачастую требуется быстро обновить конфигурацию, чтобы не потерять функционал. А возня с формами значительно усложняет весь процесс.
Во вторых я не утверждал, что это единственный способ.
И, наконец, прочитайте сами свою фразу:
Отчет по сравнению показывает, что поставщик что-то накуралесил в форме. А в клиентской конфигурации вижу
Код
_Формы.ДорисоватьРеквизитыФорм(ЭтаФорма,ЭтотОбъект);

Лично я эту фразу не понял абсолютно. Как связаны различия в форме и различия в модуле формы?
Может это не у меня проблемы с восприятием?
27. Armando Armando (Armando) 14.09.12 13:19
Погорячился я)
А в клиентской конфигурации вижу

Здесь я хотел написать, что это в модуле формы.
Один хрен каждый делает как ему удобней.
Честно я за 3 года во франче ни разу не сталкивался с такой методой у клиентов.
Потом три года сидел на фикси. Начал использовать такой способ. Лично мне было неудобно. И форма чуть дольше открывается. Вернул как было.
Сейчас работаю над проектом в команде. С трудом представляю, что будет, если начнем это применять.
28. Игорь Маркин (Elgrego) 14.09.12 13:45
(27) Armando,
Погорячился я)

Принято :)
На самом деле, тяжело это делать только первый раз для какого то вида реквизита (поле ввода, надпись, кнопка). В дальнейшем, тупо копируется рабочий код, расставляются привязки и все. А если как следует подумать, то можно эти процедуры делать с привязкой к какому то конкретному (уже имеющемуся) реквизиту на форме и передавать его в качестве параметра. А также размер и смещение в пикселях относительно типового.
Но в этом случае будет проблема если 1С его когда нибудь удалит :) Так что если вы уверены в каком то реквизите, то привязываетесь к нему и гарантия почти 100%, что ничего править не придется.

Я своих научил, им понравилось. Теперь эта процедура занимает от силы 5 минут.
29. Алекс Ю (AlexO) 14.09.12 14:03
(19) AlX0id,
Реквизит тот нужен был только для чтения .. Вот и добавил кнопку командной панели

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

в чем уж её такая универсальность?
Хоть пример свой разверните, а то непонятно совсем, что за задача стояла :)
30. Алекс Ю (AlexO) 14.09.12 16:46
(20) Elgrego,
во-первых, этот режим надо включать через большую "ж".
Во-вторых - если я уверен, что мой код ДОПОЛНЯЕТ типовой и не конфликтует с ним (да даже если и конфликтует - вот и посморим на тестовой, к чему приведет одновременная работа) - почему неможно нормально объединить по тегам (обычно внутри конструкций языка редко меняют, пишут свое рядом - а если и внутри, то тоже нестрашно, пусть отслеживает хотя бы элементарное соответствие синтаксису после объединения) разные конструкции?
потому что они могут взаимоисключать друг друга

ну так вот давайте я и решу, взаимоисключают они там друг друга, дополняют или вообще нужно сделать MERGE с закомменчиванием.
Поэтому, я, как правило, оцениваю объем своих изменений и изменений 1С. Чьих больше - те и оставляю.

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

не знаю, что там у вас за изменения, но мои изменения живут годами из-за дурости и тупоупрямства 1С...
Например, еще сделанное мной элементарные операции с выводом макета в УПП 1.1 так и не реализовано до сих пор в 1.3.
31. Модератор раздела Артур Аюханов (artbear) 14.09.12 17:21
(0) Тема известная.
У автора неплохо, но очень рутинно.
Ищи на сайте по слову "Декомпиляция", увидишь полезнейшие инструменты, которые позволяют твою рутину выполнить.
32. Алекс Ю (AlexO) 14.09.12 17:27
(31) artbear,
верно :)
но там тоже инструмент с недочетами делает автокод - почему я и не делаю отдельных "универсальных" процедур для создания элементов (привязки там "забывает", нюансы использования Данные в ПолеВвода и прочая казуистика от 1С). У 1С всегда так - все уникально, раз на раз не приходится, уж лучше сделать отдельно и перепроверить (и поправить где нужно), чем положиться на "автомат" и получить 1с-дулю...
33. Модератор раздела Артур Аюханов (artbear) 14.09.12 17:56
(31) Там инструменты с развитием.
Лучше юзать готовый код, который генерят эти инструменты, и слегка его поправлять под свои нужды, чем вручную писать размещения и привязки!
34. Игорь Маркин (Elgrego) 14.09.12 19:18
(30) AlexO, Что Вы имеете ввиду под большой Ж? :)
Для включения этого режима достаточно иметь актуальную конфигурацию поставщика на момент обновления. Не думаю, что это большая проблема.
ну так вот давайте я и решу, взаимоисключают они там друг друга, дополняют или вообще нужно сделать MERGE с закомменчиванием.

Так вот и решайте :) 1С вставит этот ВАШ код с тегом MRG, если вы не будете ничего трогать.
Если вы уверены что все правильно, просто находите тег и удаляете коммент.
На мой взгляд, самое оптимальное решение.
не знаю, что там у вас за изменения, но мои изменения живут годами из-за дурости и тупоупрямства 1С..

Не знаю какой опыт у Вас, но мне несколько десятков раз приходилось обновлять конфигурации, которые не обновляли годами. Не говоря уже о ситуации, когда в корне меняется логика программы. Например, перевод конфигурации ЗУП с 2.1 на 2.5 и т.д.
Это были ответы на Ваши вопросы.
Но в описанной мной технологии, к счастью, придется проанализировать всего одну процедуру модуля формы объекта "ПриОткрытии" и убедиться в наличии 1 строки с вызовом необходимой процедуры. Думаю, это легче чем проанализировать изменения на форме.
35. Игорь Маркин (Elgrego) 14.09.12 19:41
(33) artbear,
Полностью с Вами согласен :)
Но я в своей публикации не преследовал цель сделать все за программиста...
Я преследовал несколько иную цель - научить молодое поколение думать прежде чем что-то делать.
Для того, чтобы добавить реквизит на форму обычными средствами, много ума не надо, хотя некоторые даже с этим не справляются - забывают привязать обработчик, оформить привязки и прочее...
Даже используя инструмент, о котором Вы говорите, все проблемы не решаются. В свое время тоже загонялся этими механизмами. Был несколько разочарован...
В итоге пришел к выводу, что нужно просто включать мозг при добавлении реквизита. Остальное - компромисс.
Никто еще не смог изобрести достойный механизм анализа расхождений в неуправляемых формах.
P.S. Это только мое мнение. На истину в последней инстанции не претендую :) Надоело доказывать что я не верблюд :)
36. Игорь Хитров (Новенький_2209) 16.09.12 19:02
Скоро - совсем скоро подобные темы уйдут в небытие, с БСП и их дополнительными реквизитами и свойствами.
37. Дмитрий Ткачев (Ткачев) 17.09.12 08:13
Я там где дорабатываю модули ставлю в начале свою фамилию, в завершение три звездочки, потом проще искать.
Пример с изменением типового кода:

//Ткачев
// Если Стр.РазмерДанных > 6 Тогда
Если Стр.РазмерДанных > 10 Тогда
//***
38. Игорь Воронкин (Воронкин) 17.09.12 08:22
А в чем легче потом... При обновлении?
39. Дмитрий Ткачев (Ткачев) 17.09.12 08:37
(38) Воронкин,
Да, изменения могут затереться и потом с копии легко можно будет найти что где менял.
40. Игорь Юндин (kereo) 17.09.12 15:04
(35) Elgrego, не вижу в предложенном вами варианте никагого упрощения.

Если при обновлении в настройках фильтра поставить флаг "Показывать только дважды измененные свойства", то вы увидите какие из форм изменены (to8_img11.png).

А отчете сравнения объектов можно "Показать различия графически". В 1С 8.2 точно есть, про более ранние версии точно не скажу(Безымянный.png).
Прикрепленные файлы:
41. Игорь Маркин (Elgrego) 17.09.12 17:07
(40) kereo, На мой взгляд, я достаточно подробно объяснил, что в случае применения этой технологии сами формы (элементы управления) анализировать вообще не придется. В этом и есть облегчение.
То что вы увидите эти расхождения в отчете о сравнении, не избавляет Вас от необходимости вносить эти изменения повторно.
42. Геннадий Пиганов (Totoro) 18.09.12 20:28
(0) Проще доп страницу с нужными реквизитами добавить, если есть такая возможность, а не текущие двигать.
Или кнопку типа свойств объектов для редактирования своих доп. реквизитов (типа такого Универсальные механизмы для платформы 8.1.
А так обычные формы конечно быстрее обновлять.
43. Дмитрий Глеков (glek) 19.09.12 12:14
Сам давно пришел к необходимости программно располагать элементы. Правда, с моей точки зрения,выигрыш получается только в случае небольшого количество добавляемых элементов (до 5-10). Если получается больше, то проще словить и перенести при обновлении
45. Игорь Маркин (Elgrego) 20.09.12 07:51
(44) AlexBar, Прежде чем писать, пробовал найти нечто подобное. К сожалению, не нашел :) Идею с комментарием оценил. Спс.
46. Осипов Сергей (fixin) 20.09.12 15:52
Когда освоите эту тему, автоматизируйте дальше парсером, чтобы не ручками вставлять обновления в код:
http://infostart.ru/public/102193/
47. Осипов Сергей (fixin) 20.09.12 15:52
(43) если больше, проще добавить в прикладной объект еще одну форму (она будет сохраняться при объединениях) и переносить из нее программно, один раз написав функцию. Ручной труд - для мартышек.
48. Александр (aet) 21.09.12 09:21
Подход известный и правильный.
Число параметров ваших процедур глаза режет, структурой лучше передать имхо.
49. Алексей 1 (all_i_ance) 21.09.12 09:47
Модификации типовых конфигураций я бы условно разделил на 3 группы:

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

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

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

Справочники, документы и регистры также могут существовать в конфигурации не мешая типовым объектам. Например, у вас возникла потребность автоматизировать планирование затрат организации в рамках конфигурации "Бухгалтерский учет". Вы создаете документ "Смета затрат", к нему регистр накопления и отчет по регистру. Этот функционал использует данные конфигурации (справочники "Статьи затрат", "Подразделения организаций", "Организации"), но он никак не нарушает работу типового функционала и не требует его изменения.

В общем, модификации первой группы - это "хорошие" модификации. Они дополняют функционал конфигурации и, в то же время, не мешают ее обновлению.

Прямая противоположность первой группы изменений - изменения третьей группы. Это сознательное изменение типовых объектов конфигурации. Здесь, я полагаю, все понятно без примеров. Изменяя типовые объекты, вы получаете отложенную головную боль. Она будет случаться у вас каждый раз, когда вы будете обновлять релизы конфигурации.

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

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

В качестве примера такой модификации можно взять случай, описанный ранее, когда создание альтернативного приходного документа в конфигурации "1С:Бухгалтерский учет 7.7" повлекло за собой необходимость изменения типовых объектов, отвечающих за формирование книги покупок (документы "Запись книги покупок", отчет "Книга покупок"). Хотя в том примере было сделано даже еще хуже - были созданные альтернативные документ и отчет.

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

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

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

Ну, и в завершении - как обновлять релиз конфигурации после того, как часть ее объектов перестали быть типовыми. Если обновление релиза типовой конфигурации - процесс механический, сводящийся к нескольким щелчкам мышью, то обновление измененной конфигурации - процесс творческий. И я бы не доверил его никакому искусственному интеллекту. У меня достаточно богатый опыт обновления конфигурации "1С:Бухгалтерский учет" на платформе "1С:Предприятие 7.7". Я выработал для себя простую систему, которой готов поделиться с вами. Не претендую на истину в последней инстанции. Это всего лишь подход к решению задачи.

Итак, исходные данные: конфигурация Ai - типовая конфигурация i-го релиза; Aj - типовая конфигурация j-го релиза, причем j > i; Bi - модифицированная конфигурация, основанная на типовой конфигурации i-го релиза. Условие задачи: обновить конфигурацию Bi до релиза j, сохранив при этом все собственные наработки.

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

Ну что же. Вот, пожалуй, все, о чем я хотел сегодня сказать. Есть вопросы? Пишите!
eruil; Lenok-Angelok; lsp71; plevakin; +4 Ответить 1
50. Дмитрий Гомзин (plevakin) 21.09.12 09:49
(49) all_i_ance, Такие большие комментарии лучше выделять в отдельную статью. А так молодец!
all_i_ance; +1 Ответить
51. TAZMAG84 TAZMAG84 (TAZMAG84) 21.09.12 10:11
как и обычно при обновлении все свои модификации придется ручками поправлять!
52. Сергей Радченко (Rad90210) 23.09.12 11:06
Значит задача следующая - реализовать дополнительную аналитику в некоторых документах.
Как правило в ПриОткрытии() документа - есть вызов стратегии редактирования номера документа. Собственно туда дописываем:
Если В реквизитах шапки есть реквизит _ВидДополнительнойАналитики_ тогда на форме уменьшаем в пополам реквизит комментарий, и в появившееся место вставляем Надпись и реквизит.
Теперь достаточно в нужные документы вставить _ВидДополнительнойАналитики_ в шапку.
Обновляется за секунды. Минимальные изменения. Необходимая аналитика - присутствует.
Как по мне - искать в конфигурациях нужно именно подобные универсальные места.
Или ждать от разработчиков - расширения видов событий для подписки на событие...
53. Вида К (Vida) 07.11.12 14:48
Дорогой автор!
Очарована вашей идеей! Обязательно возьму на вооружение.
Подскажите, есть ли у вас стандартная процедура добавления нового поля ввода - колонки в таблицу документа. Или нужно модифицировать процедуру ДобавитьПолеВвода(Форма,ИмяРекв,Панель,Доступность,Л,В,Ш,Выс,ПривязкаЛев,ПривязкаПрав,Данные,КнВыбора,КнОткрытия)
убрав привязки?
54. Игорь Маркин (Elgrego) 23.11.12 07:20
(53) Vida, Спасибо за понимание :)
Конечно есть. Вот примерный ее текст:

Процедура ДорисоватьПолеВводаТЧ(Форма, Панель, Страница, ИмяТЧ, ИмяРеквизита, Заголовок, НомерКолонки, Флажок, Ширина) Экспорт
Колонка = Форма.ЭлементыФормы[ИмяТЧ].Колонки.Вставить(НомерКолонки, Заголовок);
Колонка.Имя = Заголовок;
Колонка.Ширина = Ширина;
Колонка.Данные = ИмяРеквизита;
Колонка.Доступность = Истина;
Колонка.Видимость = Истина;
Колонка.УстановитьЭлементУправления(Тип("ПолеВвода"));
Колонка.ИзменениеРазмера = ИзменениеРазмераКолонки.НеИзменять;
Колонка.РежимРедактирования = РежимРедактированияКолонки.Непосредственно;
Колонка.ЭлементУправления.КнопкаВыбора = Истина;
Колонка.ЭлементУправления.КнопкаОчистки = Истина;
КонецПроцедуры
55. Максим Евсенкин (tehas) 06.12.12 12:00
Есть у нас похожая разработка, только один плюс, в ПриОткрытии() ни чего дописывать нет необходимости.
56. Александр (aet) 06.12.12 14:20
(55) Это которая псевдоподписка ПриОткрытии?
57. Максим Евсенкин (tehas) 06.12.12 15:26
насколько я помню ПриОткрытии нет подписки, у нас все это дело вмонтировано в МеханизмНумерацииОбъектов
58. Александр (aet) 06.12.12 15:33
59. Максим Евсенкин (tehas) 06.12.12 16:52
(58) aet, да, Вы правы, так и есть
60. ГСГ (ГСГ) 12.01.13 11:40
(40) Полностью согласен, реквизит и так должен отработать.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа