Конфигуратор: сохраняет также то, что наконфигурил программи

[Friendlyman]

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

Пример 1.
Статус-строка для дерева L_KATORG::IBANKS.TRKATB определяется с учетом настройки "Настройки Галактики \ Общие настройки системы \ Доступ к таблицам \ Запретить модификацию \\ Каталога банков":
- если настройка установлена в "нет", то статус-строка не изменяется, остается такой, как была задана для данного дерева при его описании.
- если настройка установлена в "да", то статус-строка меняется программно на другую.

Если отконфигурировать дерево L_KATORG::IBANKS.TRKATB со значением указанной настройки "нет", то получится конфигурационный файл, который не содержит информации об изменившейся статус-строке. Впоследствии при использовании данного конфигурационного файла все будет работать, как и задумывал программист, т.к. статус-строки для разных вариантов значений данной настройки будут разными.

Если отконфигурировать дерево L_KATORG::IBANKS.TRKATB со значением указанной настройки "да", то получится конфигурационный файл, в котором отражено, что пользователь изменил конфигуратором статус-строку для данного дерева (но я это не конфигурил!). Впоследствии функциональность программы будет работать неверно: в режиме для значения настройки "нет" изначальная конфигурация окна будет перекрываться конфигуратором, и не будет видна изначальная статус-строка. В режиме "да" статус строка будет такой, как планировал программист.

Пример 2.
Список M_TRANSP::KAR_WPS.BRTRANSP - после конфигурирования поле "Гос.номер" становится доступно на редактирование,
хотя никто этого не делал при ручном конфигурировании!

object 'c_BRTRANSP_TRANSP.NOMER_Гос._номер' : Column {
Protect = False;
} // c_BRTRANSP_TRANSP.NOMER_Гос._номер : Column
В данном случае возникает опасность случайной порчи данных!

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

НЕОБХОДИМО грамотное решение данной ситуации. Возможно, нужно делать отличия, какие свойства изменены пользователем, а какие программистом, причем в конфигурацию сохранять только пользовательские изменения. Возможны другие варианты решения проблемы...

У кого какие предложения? Кто еще сталкивался? Как боретесь? Что предложить Атлантистам?

[galover]

Чего-то я не уловил суть проблемы. Давайте по-порядку. Если правильно понимаю, то:
1) есть ручное конфигурирование интерфейса (создание cnf и компиляция в res) - суть его докомпиляция. Т.е. при этом создается новый интерфейс, отнаследованный от конфигурируемого с измененными свойствами.
2) есть конфигурирование программное: alter interface + вызов API функций конфигуратора (cfs...)
Проблема в ручном конфигурировании? Выгружается не то? Просто я с этими проблемами никогда не сталкивался, вот и хочу уточнить.

[Алексей]

Проблема в другом. Если отконфигурить интерфейс с определенной настройкой и подложить *.crf - то программное конфигурирование, которое работает на уровне кода интерфейса просто как бы перестает отрабатывать. сталкивался с таким.

[galover]

ну так это проблема Атлантиса, что перестает работать конфигурирование на уровне кода. Что тут еще предлагать - пусть фиксят баг

[edward_K]

програмер просто в данном случае обработал одно значение настройки(второе заложено при объявлении экрана), а должен был оба - пишите в ТП и все или делайте докомпиляцию.

[Friendlyman]

програмер просто в данном случае обработал одно значение настройки(второе заложено при объявлении экрана), а должен был оба - пишите в ТП и все или делайте докомпиляцию.

Но ведь это очевидно, что проблема инструментария, а не прикладного кода. А предлагаемое решение - это способ обхода "кривизны" инструментария.
Может все таки проще один раз нормально доработать платформу, чем сто раз каждому программисту дорабатывать свои интерфейсы и защищаться таким образом от глюков конфигуратора?
В общем мое мнение, что здесь, однозначно, более правильно дорабатывать платформу вместо того, чтобы долбаться прикладникам и клиентам.

Проблему, кстати, признает и сам разработчик Атлантиса. Признает он эту проблему еще в 21/05/2001 19:05 в ПИР 101.13645 первой критичности, тут же ее отправляет в Finance и по настоящий момент ничего не делалось по этому вопросу...

[Ged]

Есть же средства для докомпиляции фейсов.
Программно он будет точно выше по приоритету чем сконфигуренный рес.

[Алексей]

смотря как их подключать
я сначала докомпилирую фейсы, потом с уже подключеными фейсами делаю ЦРФ. и подключаются у меня сначала ресурсы, а потом уже ЦРФ.
Если сделать наоборот - не увидим изменений конфигурирования.

[edward_K]

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