В процессе разработки на платформе 1С:Предприятие 8.3 программисты часто сталкиваются с загадочным поведением управляемых форм. Одна из таких загадок — внезапное появление «звездочки» (признака модифицированности) в заголовке формы. Особенно странно это выглядит, когда у вас есть две визуально идентичные формы, но одна из них считает себя измененной при простейших действиях, а другая — нет. Разберем подробно, почему это происходит и где искать скрытые настройки, влияющие на это поведение.
Первое, на что мы должны обратить внимание — это свойства реквизитов формы. У каждого реквизита в палитре свойств есть флаг Сохраняемые данные. Рассмотрим, как это работает: если этот флаг установлен, любое изменение значения данного реквизита (пользователем или программно) автоматически переводит форму в состояние Модифицированность = Истина.
Проанализируем ситуацию: часто разработчики путают это свойство с «Сохранением данных в настройках». Это разные механизмы. «Сохраняемые данные» напрямую сигнализируют платформе, что данные формы критически важны и их нужно сохранить (например, в объект базы данных или просто зафиксировать факт изменения формы). Если в одной форме флаг стоит, а в другой — нет, поведение будет разным.
Важный нюанс: даже если вы программно сбросите этот флаг, но форма уже была «запачкана» изменением, звездочка может не исчезнуть до момента перезаписи или закрытия. Проверим этот момент в первую очередь.
Очень часто причиной модифицированности становится код в обработчиках ПриСозданииНаСервере или ПриОткрытии. Посмотрим на пример кода, который управляет параметрами и порядком динамического списка:
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
// Установка параметров
СписокДокументов.Параметры.УстановитьЗначениеПараметра("Расходование", Перечисления.бит_РасходДоход.Расходование);
// Программная очистка и установка порядка
ЭтаФорма.СписокДокументов.Порядок.Элементы.Очистить;
ПорядокДатаДокумента = ЭтаФорма.СписокДокументов.Порядок;
ЭлементПорядокДатаДокумента = ПорядокДатаДокумента.Элементы.Добавить(Тип("ЭлементПорядкаКомпоновкиДанных"));
ЭлементПорядокДатаДокумента.РежимОтображения = РежимОтображенияЭлементаНастройкиКомпоновкиДанных.Обычный;
ЭлементПорядокДатаДокумента.ТипУпорядочивания = НаправлениеСортировкиКомпоновкиДанных.Возр;
ЭлементПорядокДатаДокумента.Поле = Новый ПолеКомпоновкиДанных("Дата");
ЭлементПорядокДатаДокумента.Использование = Истина;
КонецПроцедуры
Выясним причину, почему этот код может вызывать модифицированность. Если в свойствах формы включено Автоматическое сохранение данных в настройках, то любое изменение КомпоновщикНастроек (отборы, сортировки, группировки) платформа воспринимает как изменение пользовательских настроек формы. Если эти действия происходят после того, как форма «считала» свои начальные настройки, она выставляет признак модифицированности, предлагая пользователю сохранить эти новые настройки при закрытии.
Разберем важный архитектурный момент. Если мы меняем отборы или параметры в процедуре ПриСозданииНаСервере, платформа обычно не считает форму модифицированной, так как это происходит в момент инициализации. Однако, если тот же код (например, вызов процедуры ОтборПоСчету) вызывается в обработчике ПриОткрытии на клиенте, ситуация меняется.
Рассмотрим сценарий:
ПриОткрытии срабатывает код, который меняет элементы СписокДокументов.Отбор.Чтобы избежать этого, старайтесь максимально инициализировать настройки динамического списка в серверном обработчике создания формы.
Иногда визуальное сравнение в конфигураторе не помогает. Это случается, если форма была создана копированием или «пережила» множество обновлений. Внутренние идентификаторы (UUID) элементов или скрытые настройки компоновщика могут дублироваться или ссылаться на несуществующие объекты метаданных.
Выполним следующие шаги для диагностики:
<Attributes> и <SettingsComposer>. Часто там обнаруживаются параметры, которые не отображаются в обычном интерфейсе конфигуратора, но влияют на логику модифицированности.Проанализируем еще одну неочевидную ситуацию. Признак модифицированности может зависеть не от кода формы, а от данных, сохраненных в системных таблицах настроек пользователя. Если один пользователь уже открывал форму и сохранил для нее настройки, которые конфликтуют с вашим программным кодом, 1С может пытаться «примирить» их, что приводит к флагу изменения.
Рассмотрим решение: очистите настройки пользователя для проблемной формы. Это можно сделать через меню Администрирование — Настройки пользователей и прав — Очистка настроек. Выберите конкретную форму и удалите все записи. Если после этого звездочка исчезла — проблема была в кэшированных данных.
При копировании форм важно проверить Основной реквизит (он выделен жирным шрифтом в списке реквизитов формы). Обычно это Список типа ДинамическийСписок. Если в одной из форм основным реквизитом случайно назначен другой объект или если свойство Основной реквизит вообще не задано, поведение формы при записи и отслеживании изменений будет существенно отличаться.
Также проверим свойство динамического списка Автоматическое сохранение пользовательских настроек. Если в одной форме оно включено, а в другой — нет, работа с отборами будет давать разный результат в плане модифицированности.
Подводя итог, если вы столкнулись с «беспричинной» модифицированностью, действуйте по алгоритму:
1. Проверьте флаг Сохраняемые данные у всех реквизитов формы.
2. Перенесите настройки динамических списков из ПриОткрытии в ПриСозданииНаСервере.
3. Убедитесь, что программная установка параметров списка не конфликтует с флагом Автоматическое сохранение данных в настройках.
4. Очистите пользовательские настройки формы.
5. Если ничего не помогает — сравните XML-структуру форм. Часто простое создание формы «с нуля» и перенос туда кода (как сделал автор темы) является самым быстрым способом избавиться от невидимого «мусора» в метаданных.