Структура статьи:
- Цель
- Концепция
- Объекты системы без четкого описания методики изменения
- Методики
Сразу оговорюсь, что изменение конфигурации по описанной ниже методике более трудоемка, но время, потраченное на этапе разработки с лихвой окупается при последующих обновлениях.
ЦЕЛЬ
Модификация конфигурации, находящейся на поддержке, с возможностью последующего «быстрого обновления».
КОНЦЕПЦИЯ ИЗМЕНЕНИЙ
- Минимальная правка кода в модулях конфигурации. Все требуемые изменения нужно выносить в общие модули или модули менеджеров новых объектов (справочников / регистров / обработок), логически связанных с вносимыми изменениями.
- Отказ от «непосредственного» изменения текстов запросов. Касается как запросов расположенных в текстах модулей, так и запросов-источников динамических списков.
- Отказ от изменения форм объектов на уровне конструктора форм. Использование только программного (при помощи написанного кода) способа. Речь идет не только о добавлении/изменении элементов форм, но и о добавлении реквизитов форм, событий элементов форм (и самой формы) и условного оформления форм.
- Максимальное использование подписок на события.
ОБЪЕКТЫ СИСТЕМЫ БЕЗ ЧЕТКОГО ОПИСАНИЯ МЕТОДИКИ ИЗМЕНЕНИЙ
- Изменение ролей
- Изменение функциональных опций
- Изменение состава реквизитов
- Изменение состава регистраторов
- Изменение состава общих команд
- Изменение схем компановки данных
МЕТОДИКИ
- Комментарии к изменениям. Считается хорошим тоном, а в случае изменения модуля, находящегося на поддержке являются обязательными комментарии с открывающимися и закрывающимися «тегами» к программному коду который вы внесли/модифицировали. Обычный минимум – это дата изменения и «ФИО» разработчика. Плюсом будет номер тикета или краткое описание изменений.
- Минимальная правка кода в модулях конфигурации. Руководствуемся «достаточным» минимумом изменений. Конечно, если Ваши изменения в объеме 1-3 строки, то не стоит для этого их выносить в отдельный модуль. В случае если код «большой» или он используется в нескольких местах, выносим его из тела модуля.
Все вызовы функций/процедур воспринимаем как некий «черный ящик» у которого есть параметры/источники данных (передаваемые или общие) на вход и результат на выходе. Если мы можем изменить входные параметры таким образом, чтобы «метод» вернул нам требуемый результат – меняем входные параметры (передаем их в нашу процедуру/функцию) и там их переопределяем. Если есть возможность изменить/дополнить данные на выходе – вызываем наш метод после. В случае невозможности «подменить» входные/выходные параметры принимаем решение: либо разбираемся-«осветляем» ящик и ищем «точку входа» в нем, либо пишем свой метод взамен текущего.
Результаты запросов, если есть сложность и нецелесообразность менять сам запрос (см. методику модификации запроса ниже) тоже можно переопределить/дополнить, выгрузив его в таблицу значений и потом в качестве источника модифицировать в своем запросе.
Если есть некая конструкция кода с условиями и циклами, результат которого вам «не подходит» после нее напишите свой и «переопределите» результат. Нужно ли комментировать исходный код зависит от его ресурсоемкости. Желательно его оставить «как есть».
Свои процедуры и функции можно располагать в новых общих модулях или менеджерах Ваших новых объектов. К примеру, если Вы создали справочник «Номенклатура клиентов» и в печатных формах Вам нужно модифицировать запрос таким образом чтоб вместо артикула номенклатуры компании выводился артикул клиента – процедуру модификации запроса целесообразней расположить именно в модуле менеджера справочника «Номенклатура клиентов».
По возможности стараемся не менять обработчики событий форм. О переопределении обработчиков событий, их «отключении» без модификации самих обработчиков и формы см. в разделе «Отказ от изменения форм объектов на уровне конструктора форм»
3. Отказ от «непосредственного» изменения текстов запросов. Часто используемым подходом к изменению текста запросов является «непосредственное» изменение запроса с закомментированными в нем «исходными» блоками. Основной недостаток такого подхода – при случайном или необдуманном использовании конструктора запросов «слетают» комментарии и «куски» закомментированного запроса от поставщика конфигурации. Другой способ – копирование и модификация исходного запроса целиком в своей процедуре и последующая подстановка нового запроса. В этом случае при обновлении конфигурации есть необходимость сверять запросы м/у собой – новый от поставщика старый от поставщика и измененный разработчиком. Причем, так как нужно сравнивать уже 3 текста, делать это приходится не средствами 1С, а сторонними программами, к примеру — KDiff3.
Предлагаемый подход направлен на сохранение первоначального текста запроса и «точечной» его модификации. Для этого находим требуемые задачей «точки входа» и функцией СтрЗаменить() меняем исходный текст запроса – вставляем необходимые условия, соединения, выбираемые поля. Небольшой пример для понимания (пример надуманный и очень простой, но помогает понять вышеописанный принцип):
ТекстЗапроса = «
|ВЫБРАТЬ
| Номенклатура.Ссылка КАК Ссылка,
| Номенклатура.Наименование КАК Наименование
|ИЗ
| Справочник.Номенклатура КАК Номенклатура»;
Нам нужно ограничить выборку записями, имеющимися в некотором регистре сведений и вывести некоторые значения из этого регистра
Добавим внутреннее соединение
ТекстЗапроса = СтрЗаменить(ТекстЗапроса, «
| Справочник.Номенклатура КАК Номенклатура», «
| Справочник.Номенклатура КАК Номенклатура
|ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ДляПримера КАК Пример
| ПО Номенклатура.Ссылка = Пример. Номенклатура»);
Вынесем в результат требуемые поля
ТекстЗапроса = СтрЗаменить(ТекстЗапроса, «
| Номенклатура.Ссылка КАК Ссылка,», «
| Номенклатура.Ссылка КАК Ссылка,
| Пример.Поле1 КАК Поле1,
| Пример.Поле2 КАК Поле2»);
Таким образом, мы, сохраняя исходный текст на поддержке, при изменении его поставщиком (без кардинальных изменений), можем гарантировать обновление запроса поставщика без обдумывания наших изменений.
Немногим более сложна модификация предложенным способом пакетного запроса. Как вы уже догадались, пакетный запрос – это набор «одиночных» запросов. Нам остается разобрать пакет на отдельные запросы, изменить/подменить конкретный (ые) и собрать пакет запросов обратно. В УТ11 есть замечательные функции для этого «СтроковыеФункцииКлиентСервер.РазложитьСтрокуВМассивПодстрок()» и «СтроковыеФункцииКлиентСервер.ПолучитьСтрокуИзМассиваПодстрок()». Делителем строк будет являться символ «;».
Для динамических списков текст запросов меняем аналогично. В случае если динамический список использует реальную таблицу – меняем настройки динамического списка и подставляем текст запроса:
.УстановитьТекстЗапросаДинамическогоСписка_ЗаказНаПеремещениеСписок(Список);
Процедура УстановитьТекстЗапросаДинамическогоСписка_ЗаказНаПеремещениеСписок(Список) Экспорт
Список.ПроизвольныйЗапрос = Истина;
Список.ТекстЗапроса
= «ВЫБРАТЬ
| ЗаказНаПеремещение.Ссылка, ……
4. Отказ от изменения форм объектов на уровне конструктора форм. По моему мнению, самым проблемным в обновлении измененных конфигураций – это обновление форм. Решение, позволяющее упростить эту задачу – менять форму программным способом, т.е. использовать динамическое/программное изменение состава, отображения, поведения формы.
На программном создании элементов форм особо останавливаться не стоит, так как примеров и механизмов написано достаточно. Нужно только выбрать подходящий для себя. Я писал свой. Список добавляемых элементов хранится в макете. Вызов процедуры общего модуля происходит в процедуре ПриСозданииНаСервере(). При таком подходе я добавляю новые реквизиты в модифицируемый объект, прописываю вызов процедуры динамического создания элементов и добавляю в макет описание добавляемого реквизита. На все уходит не более 5 минут.
Реквизиты формы (те что нужны на форме только на момент ее существования и не должны храниться в базе) тоже создаю программно. Подход аналогичный подходу, используемый при создании элементов форм. При этом динамически созданный реквизит может являться источником (прописанным в пути) для динамического элемента формы.
Условное оформление тоже доступно для модификации программно. На момент написания статьи я еще не разработал более-менее внятного механизма по его «настройке» и просто прописываю в виде куска кода (конечно же, с вызовом в общем модуле).
Динамическое переопределение и добавление обработчиков событий формы.
Зачастую при модификации форм Вам, к примеру, на событие ПриИзменении нужно «добавить» обработку события. Обычно мы в форме определяем вызов метода «ПриИзменении» и уже в теле созданной процедуры описываем поведение. В этом случае при обновлении конфигурации у нас «распознаются» не только изменения модуля формы, но и изменения самой формы.
Мною разработан модуль «динамически подключаемых обработчиков событий» элементов форм и самих форм со следующим функционалом:
- Добавление обработчика события
- Удаление обработчика события
- Переоределение обработчика события с возможностью вызова оригинального обработчика до, после, либо возможность его отключить.
На практике на момент написания данной статьи мною разрабатывается конфигурация для крупной торговой компании, занимающейся поставкой инструментов, на базе УТ11. Формы справочников и основных документов товарооборота и планирования сильно доработаны. Добавлены реквизиты шапки, табличных частей, вычисляемые реквизиты форм, добавлены и переопределены обработчики событий форм и реквизитов. Блокируются строки в табличных частях товаров и многое другое. Всего не описать. Примечательно, что при всех этих изменениях в модулях измененных форм всего несколько вызовов процедур в процедуре «ПриСозданииНаСервере» и в случае динамически подключаемых событий по одному «шаблону-процедуре» на событие.
Данная статья не предполагает детального описания разработанного вышеуказанного механизма. В случае здорового интереса к нему готов написать отдельную статью с детальным описанием и выложить исходники с примерами использования модуля по созданию динамических реквизитов, элементов и подключаемых обработчиков.
5. Максимальное использование подписок на события. Собственно если есть возможность использовать подписку на событие – используйте.
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
интересна реализация вашего механизма быстрого внесения изменений в форму, а также как вы модифицируете проведение документов.
Неплохо бы посмотреть отдельную статью с детальным описанием и выложить исходники с примерами использования модуля по созданию динамических реквизитов, элементов и подключаемых обработчиков. А так +
(1) по модификации проведения документов зависит от задачи, но чаще всего реализация сводится к модификации запроса по принципам рписанным в статье. Если у вас есть конкретный вопрос, буду раз описать решение
(1)(2) я постараюсь до 04.02.2013 написать статью по динамическому изменению форм. сложнее всего будет создать пример и хелповое описание ).
По мне , так идея модификации запроса через «СтрЗаменить» плохая идея — получается собрать полностью запрос возможно будет только во время исполнения программы.
(4) Тут каждый волен выбирать что хочет получить ). Видить всегда полный запрос всегда, даже когда уже закрыл задачу и потом париться с объединением, либо «собрать» его тогда когда надо для отладки. На этапе программирования можно делать по старинке. но я стараюсь делать сразу таким образом.
Думаю здесь важно избежать ситуации, когда упомянутое увеличение трудоемкости при разработке выльется в увеличение трудоемкости при модификации доработанного, причем уже в логарифмической зависимости, а в некоторых случаях и при обновлении в итоге тоже может получиться усложнение вместо ожидаемого упрощения. Ведь «докопаться» до физического смысла доработки становится сложнее, что весьма затрудняет сопровождение доработанного по данной технологии решения, а сопровождение ведь это не только обновление. Думаю об этом не стоит забывать тоже. Плюс.
(6) Согласен. Всегда ко всем рекомендациям нужно относиться «дозированно» и никогда не принимать «на слово», потому что ответственность всегда лежит на исполнителе.
Мы всегда несем ответственность за свои изменения. Более того, изменения стандартной конфы зачастую несут глобальный характер с переименованием и переписыванием кода целиком. Могу ссылаться только на свой опыт. А получилость так что при обновлении на новый релиз мне пришлось проверять и вылавливать «стационарные» изменения регистраторов, реквизитов, комманд и т.п. и ни одной проблемы с динамическими элементами/событиями сменой текстов запросов и тп. Может повезло-не спорю, но факт остается фактом.
Спасибо за рекоммендации
Насчет модифицирования запросов — спасибо. Почему то не пришел в голову такой метод
Как раз начал задумываться над тем, как «изменять конфигурацию с минимум изменений».
Большое спасибо за статью!
С нетерпением жду следующей, с примерами!
(9) Спасибо, следующая статья уже в процессе. В ней будет минимум описания и прикреплена маленькая самописная база примеров.
В принципе ничего нового, но такие статьи всегда актуальны и полезны, как напоминание
Если изменений в запросе много или изменился запрос в основной поставке,
то метод с СтрЗаменить() иногда только затрудняет обновление,
мне проще переопределять текст запроса ниже типового текста зароса.
Для динамического создании элементов форм так и не нашел удобного для меня инструмента,
который позволял бы делать это быстро и удобно..
Но в конфигурациях на УФ с этим стало попроще благодаря встроенным механизмам
А в остальном все указано верно и соответствует здравому смыслу и метод. рекомендациям 1с по этому вопросу )
(11) expert.1c8, основная проблема при обновлении — это форма. При этом, казалось бы, т.к. форма управляемая, она полностью описываемая — почему в сравнении не указывать конкретные изменения в форме?…Я тоже не нашел никакого более или менее удобного инструмента для динамического создания элементов формы. Хотелось бы взглянуть на описываемую автором реализацию 🙂
Могу только подтвердить справедливость всего описанного выше и поставить +.
Правда, маловато написано про формы.
На этом сайте присутствует замечательная статья
.
С первого раза идея, изложенная в статье, мне показалась сложной, но прочитав текст статьи 2 раза и код процедур, я осознал простоту и гениальность метода.
Теперь для изменения форм я использую такой подход:
1) Все доработки я делаю только на копиях форм. Т.е. если я меняю форму элемента или списка справочника, я всегда делаю копию оригинальной формы (например, script_ФормаЭлемента), устанавливаю ее основной, и только потом приступаю к доработке.
При обновлении, в разделе объединение и сравнение … такой объект отобразится как измененный.
В свойствах такого объекта будет значиться, что изменена основная форма элемента.
Среди форм данного объекта появится «МОЯ» форма, а оригинальной формы не будет. Это значит что кроме моей формы, других изменений в объекте нет. Если же появляется и оригинальная форма, тогда становится понятным то, что поставщик внес свои изменения в данную форму и мы сможем увидеть отличия без наших доработок.
Далее принимаем решение, что проще? Перенести изменения в «Нашу» форму или скопировать обновленную, оригинальную форму и внести доработки повторно.
2) Элементы на форму я стараюсь поместить программно, но поскольку большинство моих конфигураций работают на обычных формах, такой подход не всегда реализуем или правильнее сказать, не всегда простой в реализации, но предпочтение я отдаю именно ему.
3) Это переопределение обработчиков событий элементов форм по, указанной в статье, методике.
Из опыта: умудрился подключить свою систему бюджетирования к БП 2.0, добавив только одну строчку в стандартной.
Все остальное — новые объекты.
Подписки на события форм, существуй они, серьезно бы облегчили нам жизнь.
(13) спасибо на ссылку по обработчикам. Хорошо то я ее не видел до текущего момента, так как, наверное, не заморачивался бы над своим механизмом. В итоге у меня подход к реализаии совсем другой, хотя методы установки и выполнения похожи, так как продиктованны возможностями платформы.
по п1. решение, по моему скромному мнению, интересное и, как вариант, может применяться должно при очень больших изменения форм. но в этом случае мы отказываемся от поддержки такой формы, а как следствие и вызываемых методов общих модулей (1С часто грешат тем что перекидывают из модуля в модуль и меняют параметры написаннх методов).
Небольшое дополнение здесь: если вы используете платформу 8.2 последних версий то для того чтобы не переопределять основную форму в метаданных есть подписка на событие менеджера объекта «ОбработкаПолученияФормы» в которой можно переопределить вызов основной формы.
довольно таки интересная статья, есть что использовать и применить на практике. Вот только вопрос обновление нетиповой конфигурации до конфигурации с УФ все равно приходиться делать методом сравнить-объединить конфигурации
(18) Хотелось бы увидеть аргументированную позицию
Буду рад прочитать статью ознакомиться с Вашей статьей и почерпнуть новые подходы, в чем я лично сомневаюсь.
Статья конечно не доработанна, но это не повод «так» о ней отзываться
Плюсик за приятное воспоминание о наивной молодости ;-))
ИМХО: код и формы лучше вообще не трогать, если хочешь их потом обновлять типовыми…
Стараться обходится внешками и максимум новыми объектами.
Эx…Хорошо бы, если бы кто-нибудь раскрыл тему «ОБЪЕКТЫ СИСТЕМЫ БЕЗ ЧЕТКОГО ОПИСАНИЯ МЕТОДИКИ ИЗМЕНЕНИЙ»
Хотелось бы побольше услышать о динамическом переопределении и добавлении обработчиков событий управляемой формы….
Если запрос глобально поменяется при обновлении, то при доработке с использованием закомментированных вставок легче будет понять, что конкретно было доработано, чем через «СтрЗаменить». Имхо. А вообще, вопрос поднят важный. Сталкивалась с обновлением нетиповой, когда даже печатные формы не были сделаны внешними, а вносились изменения непосредственно в макеты, вот это перебор уже:(
Какие бы ни были споры по поводу полезности статьи, я считаю, что это очень хороший, благодарный труд. Автору спасибо.
Мир этому дому! Статья безусловно полезна и сама тема актуальна. Каждый двигается своим путем, наступая на грабли и получая шишки, но в конце концов рождается решение, и оно работает. Чужой опыт бесценен. Я думаю, что статья будет расширяться, обретая новые направления и примеры.
(1),(2),(9),(11),(12),(13),(15),(17),(23),(26),(27)
В качестве анонса: вчера дописал статью «v8.2 Управляемые формы: Динамические элементы формы и переопределяемые события или как изменить поведение и внешний вид управляемой формы программно без лишних хлопот «. Это статья по примеру реализации пункта «Динамическое переопределение и добавление обработчиков событий формы.»
В данный момент статья на модерации. Как только она станет активной — сразу скину ссылку всем заинтересовавшимся.
(28) еще раз спасибо за труды! Ждем-с!
(1),(2),(9),(11),(12),(13),(15),(17),(23),(26),(27)
Статья опубликована.
Спасибо
(4) pumbaE, Думаю использование данной методики (СтрЗаменить для модификации текста запроса) будет оправдано в случае с динамическими списками, когда источником данных списка является произвольный запрос. В случае корректировки типового запроса непосредственно в свойствах динамического списка мы не увидим деталей при анализе различий в процессе сравнения/объединения конфигураций.
(3) очень заинтересовали, спасибо что сдержали обещание
(32) спасибо, приятно что обе статьи получили достойный отзыв.
При модификации типовой надо понимать, что «минимальное изменение типовых объектов и кода» не есть основной критерий, который определит трудоемкость последующих обновлений.
Нам, конечно, с одной стороны нужно добиться:
1. минимизации ручного переноса изменений в новые релизы
Но с другой стороны нам нужно:
2. обеспечить, чтобы все изменения надежно переносились в следующий релиз и надлежащим образом адаптировались к новому релизу, если есть такая необходимость.
Поэтому практику:
а) копирования семиэтажных запросов и изменения в них пары строчек
б) копирования типовых форм ради добавления пары элементов формы на них
и т.п. считаю вредной.
Если нам надо внести изменения в программу, то мы должны внести их так, что при обновлении было сразу видно что они, собственно, внесены, а также куда именно они внесены, и зачем они внесены.
(34) К сожалению, не совсем понял Вашу позицию. Вроде Ваши слова не расходятся с описанной в статье методикой, но ощущения посте прочтения остались, как-будто Вы не согласны со статьей.
(35) Да, по сути не расходится.
Но пункт №3 лучше переименовать, назвать не «Отказ от «непосредственного» изменения текстов запросов.», а что-то вроде «Модификация запросов при помощи СтрЗаменить()».
Поясню: в статье, по сути предлагается отказ как от
1.непосредственного изменения,
так и от
2. копирования
и предлагается 3-ий метод — СтрЗаменить().
А сейчас из названия пункта №3 возникают ощущения, что предлагается именно отказ от неопосредственного изменения запроса.
Еще я б конечно поспорил насчет того, какой вариант лучше, 1 или 3, но про это уже было выше 🙂
(36) Спасибо, что разъяснили Вашу позицию.
Учту замечания при корректировке статьи, которая будет обязательно произведена на основаниии Ваших замечаний и других «высазавшихся».
Так же планирую дополнить статью — так сказать по максимуму заполнить «белые пятна»
У меня скорее вопрос, чем утверждение. А не проще вместо СтрЗаменить добавить вызов процедуры в общем модуле, где будет осуществлена замена текста запроса и (если необходимо) указаны значения дополнительных параметров?
(38) Это всего лишь подход. Я задумывался по процедуре, только хотел чтоб она по определенной константе проверяла на то что сделала изменения в запросе. Нужно это только 1 раз при обнновлении конфигурации чтоб понять «отработала» ли замена корректно. если после выполнения стрЗаменить запрос не изменился тогда Сообщать
(38) Смотрите сами. Сделали вы так. В следующем обновлении 1С внесла в свой запрос некоторые изменения, допустим исправление критичной ошибки. Вы при обновлении видите свое изменение, переносите вызов подменяющей запрос процедуры. Исправление критичной ошибки пройдет мимо, если вы конечно не будете специально анализировать на изменение поставщиком все такие места, где производили дублирование типового кода.
(40) Вы не поняли смысла подхода. В том то и дело что в моем случае я вношу только свой код, а в нем нет критических ошибок поставщика
(40) aegoncharov, с таким же успехом, вы можете перенести замену подстроки, которая не будет работать…я в любом случае анализирую, что изменил поставщик в исправленном мною коде, иначе можно перенести кусок который с исправлениями поставщика будет работать еще хуже.
(40)(42) тут конечно нужно написать в комметариях дополняющей/правящей запрос функции что именно Вы в нем коректируете. Чаще всего это Ваш новый функционал, который вряд ли пересечется с дорабтками 1С.
Если Вы сами исправляете критическую ошибку 1С, то, наверное, правильнее править вносить изменения непосредственно в запрос с описанием типа «исправление такой-то ошибки» в надежде что ее поправят в послед. релизах. В этом случае Вы при объединении увидите и смодете проанализировать изменения на устранение оной.
(42), (43) Я просто понял фразу «где будет осуществлена замена текста запроса» из (38) как то, что будет замена всего текста запроса.
А в СтрЗаменить один из минусов заключается в том, что заменяемых текст должен точно совпадать с куском текста запроса, вплоть до пробелов и прочих символов. Переформатируют текст — и пролетит СтрЗаменить мимо.
СтрЗаменить применительно к текстам запроса признаю только когда идет замена специально подготовленных меток, как это часто делается в типовых.
(44) по точному соответсвию текста Вы совершенно правы. По этой причине я подумывал о спец. процедуре оберткекоторая сама бы проверяла произошла ли замена текста. К сожалению я не увидел ни одной из специально подготовленных меток в тех местах где мне они были нужы. В качестве меток я беру сущетвующую строку запроса и в замене заменяю на нее + свой текст.
(45) Метки это типа такого:
| //ДляРеглУчета СУММА(УчетЗатрат.ПостояннаяРазница) КАК ПостояннаяРазница,
| //ДляРеглУчета СУММА(УчетЗатрат.СтоимостьНУ) КАК СтоимостьНУ,
| //ДляРеглУчета СУММА(УчетЗатрат.КоличествоНУ) КАК КоличествоНУ,
|
| СУММА(УчетЗатрат.Стоимость) КАК Стоимость,
| СУММА(УчетЗатрат.Количество) КАК Количество
|
|ИЗ
| РегистрНакопления.УчетЗатрат%СуффиксРегл% КАК УчетЗатрат
|ГДЕ
| УчетЗатрат.Регистратор = &Регистратор
Используются для «ручной сборки» текста запроса.
В тех местах где они нам нужны их конечно не будет 🙂
(46) aegoncharov, куда более удобны метки вида &<ИмяПараметра>, например:
ТекстЗапроса = «ВЫБРАТЬ &Поле ИЗ Справочник.Номенклатура ГДЕ &Условие»;
а потом ТекстЗапроса = СтрЗаменить(ТекстЗапроса, «&Поле», «Ссылка») и ТекстЗапроса = СтрЗаменить(ТекстЗапроса, «&Условие», ?(ТолькоНепомеченныеНаУдаление, «НЕ ПометкаУдаления», «ИСТИНА»)).
Такие метки не «слетают» при редактировании конструктором. имхо, их то как раз можно более-менее безобидно вставлять в «штатные» 1с-вские запросы.
(47) Идея хорошая, но она реализуема только для условий и полей в запросе. Но что если надо вместо одного поля в запросе вывести другое, или присоеденить к текущей таблице еще одну?
А вообще идея состоит в том чтоб вообще не вносить никаких изменений в типовой запрос.
Что касается «они не «слетают» при редактировании конструктором» то зачастую, особенно в пакетных запросах 1С описывает наименование таблиц или вставляет комментарии и при использовании конструктора Вы теряете эти комменты.
(46) aegoncharov,
думаю, только для простейших случаев.
Если же рассмотреть задачи модификации алгоритмов проведения (к примеру, в модуле менеджера УТ 11 — инициализировать документ), то такой подход только усложнит разработку и понимание. Проще вызвать переработанный текст запроса полностью.
Статья полезная, слов нет, но много уже статей на эту тему и нет ничего нового в статье
(0) А зачем такой геморрой с формами? В большинстве случаев проще скопировать форму поставщика, назвать ее Измененная_ФормаДокумента, назначить ее основной и править все в ней. Правда при обновлении нужно будет руками вносить изменения поставщика в свою форму, но для сопровождения будет намного нагляднее что зачем сделано. И в 99% случаев форма будет работать без внесения изменений поставщика. А с программной привязкой обработчиков и элементов формы при неумелом обновлении (а чаще всего обновлять отдают низкоквалифицированному персоналу) форма может перестать открываться и вываливаться с ошибкой, если например поставщик переименовал один из элементов, к которому привязка устанавливается программно…
(51) a-novoselov,
А геморой именно в
Плюс к этому нужно будет как-то сверить уже 3 формы: старую от поставщика, новую от поставщика и новую с Ващими изменениями. Не очень приятное занятие, по крайней мере для меня.
Если еще принять во внимание тот факт, что 1С, зачастую, любить изменять формы до неузнаваемость, как это происходит на УТ 11 — я Вам не завидую.
В случае днамического добавления реквизитов на форму и динамических обработчиков максимум что произойдет — это ошибки при открытии формы о не найденных элементах формы с которыми очень легко разобраться.
Надеюсь я ответил на Ваш вопрос.
(0)
А можно для полноты в статью добавить ссылки, где есть примеры и механизмы?
(53) a-novoselov,
Да, статью буду дописывать, так сказать, закрывать «белые пятна».
по моему механизму Вы можете ознакомиться, пройдя по ссылке .
В ней есть демо-конфигурация описанная в статье.
Жду Вашего мнения )
Идеи в статье описаны интересные,
думаю пригодятся. ПЛЮС однозначно.
Программное редактирование форм для типовых на поддержке — возможно хорошее решение. А как быть со сложными формами, в которых 10 закладок, и на каждой таблицы, макеты, со своими полями и расположением + привязки? Это же замучаешься их описывать в коде и подгонять положение элементов формы.
(56) Maxisussr,
Что касается форм, нужно не решать проблему не в лоб, а универсальными механизмами. Для обычных форм у меня нет решения. Для УФ есть и оно опубликовано на инфостарте.
Самый легкий способ делать минимальные изменения — вообще не использовать типовые конфигурации :)))))
(57) , С обычными формами также легко работать, если их модифицировать на программном уровне.