Изменения вносятся только в текст модуля.
Модификация формы производится созданием дополнительной формы с новыми/изменёнными элементами, реквизитами и командами.
Используется метод разбора формы из //infostart.ru/public/304736/
Идея такая:
В конфигураторе создаётся модифицирующая форма объекта/списка/выбора или любая другая
— с новыми элементами формы
— со старыми элементами (по свойству: имя) к которым привязываются новые — для поддержания иерархии формы
— со старыми элементами (по свойству: имя) с изменёнными свойствааи (видимость, доступность, шрифт, цвет, и др.) — для модификации свойств элементов
При запуске рабочей формы модифицирующая разбирается на косточки.
Затем эти косточки внедряются в рабочую форму.
Если в модифицирующую форму добавлен элемент для поддержания иерархии, без изменения свойств самого элемента, тогда в его заголовок необходимо включить подстроку «_()_»
Если требуется, кроме поддержания иерархии, поправить еще и свойства оригинального эелемента, тогда в заголовок необходимо включить подстроку «_(*)_»
Если элемент необходимо вставить в форму перед определенным элементом, тогда в его заголовок необходимо добавить подстроку «_+ИмяПостРеквизита+_»
Реквизиты с именами «Объеты», «Список» и/или с заголовком с подстрокой «_()_» не обрабатываются
Служебные подстроки вида «_…_» вырезаются из заголовка при добавлении элемента в рабочую форму
Добавление новых обработчиков команд и событий элементов:
1. создать в модифицирующей форме процедуру обработки с пустым телом (заглушка). Привязать к команде/событию.
2. добавить в изменяемую форму процедуру обработки команды/события с тем-же именем, что и в новой форме и с полным функционалом
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Изменение текста модуля формы — уже изменение конфигурации, Слава, кто Вам сказал, что это хорошо? Расширения позволяют этого избежать, или цель посадить клиента на обновления?
Изменения в тексте модуля намного проще переносить при обновлении, чем объединять изменения в самой форме.
Пока расширениям доверия нет. Может быть позже, когда допилят по надежности и функционалу можно будет их использовать в рабочих базах.
(2)
стесняюсь спросить — А почему? Прекрасно работают.
(3) Alex_E,
Например тут комментарии 36, 39
Для себя решил так: своих старых клиентов, с писаными-переписаным конфигурациями, буду поддерживать по-старинке без использования расширений.
Если появится клиент с конфигурацией с расширениями — буду на нем эксперементировать.
(4) Вы количество + в статье видите,но ориентируетесь на два комментария, которые автор сминусовал?)))
(0) Мы кодом в ПриСозданииНаСервере добавляем всё что нам нужно (кнопки, табличные части, события и т.д.). Не увидел у вас в статье преимущества по сравнению с добавлением кодом элементов формы.
(1) Alex_E, расширения, это конечно хорошо, но, например нам они не подошли:
1. В базе тысячи изменений и если всё переделать расширениями на это уйдёт год (-ы).
2. Допустим всё перевели на расширения (общие модули разработчики уже разрешили делать расширениями, допустим вышла 8.3.9 со своими плюшками). Как у нас сейчас происходит обновление: 2 программиста обновляют минимум неделю базу. Будем обновляться буквально за минуты, но вот только ничего работать не будет после этого.
Например: мы в базе сильно потрогали учёт НДС, который разработчики меняют каждый релиз. Без окна сравнения конфигурации мы этого не увидим и либо словим ошибку, либо будет работать стандартный механизм. Чисто теоретически можно покрыть каждую разработку тестами, но опять на это уйдут годы. Да и тест только покажет где проблема, а на анализ изменений без окна сравнения уйдёт значительно больше недели…
3. Плюс нельзя в процедуре просто поменять/добавить одну строчку посередине кода. Обязательно нужно дублировать всю процедуру в расширение и отслеживать изменения.
Итого для себя сделал вывод: расширения это хороший механизм. Зря его некоторые на форуме люто презирают. Можно без изменения конфигурации внести изменения в конфигурацию)). Конфигурация остаётся стандартная — пользователь может обновлять сам без вызова программиста, чем экономит себе деньги. Но для сильно изменённой базы расширения не актуальны.
(6) klinval, я разве где — то предлагал полностью отказаться от изменений типовой кофигурации? У меня есть несколько настроек, которые полностью в расширения тупо не уложатся, ну и что с того (нет, и вряд ли будет возможность через расширения менять состав объектов, ну там добавить справочник или документ, или изменить их реквизиты, хотя чем чёрт не шутит? вдруг)? А вот с изменением форм с помощью расширений, ИМХО, — самое оно, а тут предлагается ломать конфу — не комильфо)))) Если есть возможность не менять типовую — нужно её использовать — так будет честно, по отношению к клиенты (для себя может и меньше бабла, но, клиенты оценют)))))))
(6) klinval,
У меня так-же было сделано. Потом переделал на предлагаемый вариант.
Приемущество в наглядности — примерно для того, для чего и сделан визуальный редактор формы.
Когда много новых/измененных элементов на форме, тогда разбираться в коде становится несколько затруднительно.