С XML в дигиталсе еще можно разобратся, поскольку элементы XMLя читаются как простые параметры, можем использовать уже накатанные пути заполнения параметров, к тому же разработчики постоянно дополняют функционал самой программы.
Но что делать с отчетами (Reports)?
Новые требования по технической документации запрашивают больше чем задано в ин4, по этому конвертацию из хмеля в ин4 не рассматриваю(собственно и развитие старых шаблонов).
Открыл пример нового обменника с сайта, и попытался создать отчет. Сразу понял что придется начинать с белого листа, список шаблонов был пуст, и это не удивительно, откуда им взяться?
Вставив буфер обмена в Notpade++, обнаружил совершенно новую картину:
В шапке огромное количество текста (более 7000 символов), были обнаружены знакомые нам ранее параметры. Далее часть тела XML, далее описание межевых знаков, и угодий, далее каталог углов поворота и длин линий с координатами.
В общем возникает вопрос, с какой стороны к этому подходить, и как начинать с этим работать.
Не дублировать элементы обменника в параметры подобные ин4 и далее с ними работать?
А что за новые требования по технической документации?
Я думаю, что примеры работы с xml можно почерпнуть в отчетах для Регистратора.
На местном уровне чинуши извращаются.
добавлено:
сам шаблончик
Не так все просто.
Продолжаем войну с ветряными мельницами 
Поскольку родной Report дигиталса пока адекватно не реагирует на XML, решил позаимствовать RegReports из регистратора (переименовав RegReports.exe в Reports.exe)
Далее скормил ему шаблоны регистратора, после чего отчеты не стали ругаться на свежие функции типа XPATH (пропала надпись слишком много параметров).
Насколько я понял теперь в буфер будет поступать чистое тело обменника(в отличии от “чистых” параметров ин4, и метрики), а уж далее операции будут производится с чистым XML.
Можно сделать вывод, что нужные строки можно подтягивать по тегам, структура стандартна и можно с ней работать.
Пока весит вопрос о метрической информации.
Хотелось бы увидеть, как работают новые функции, желательно на простых примерах.
PS: Так-же RegReports почему то очень долго выполняет обработку шаблонов на одном ядре 1,4гГц, и 512 оперативки, это нормально 
?
Было б здорово, если выпустили наконец Reports для работы с XML, с работающими функциями 
Уряя заработало!)
begin
xxx:=XPATH(‘AdditionalPart/ServiceInfo/FileID/FileDate’);
end.
в мемо переменная [xxx] отображает дату создания обменника.
можно заменить на:
begin
xxx:=XPATH(‘AdditionalPart/ServiceInfo/FileID/*[1]’);
end.
Лед тронулся 
Dmitry_Zolotar могли бы вы описать существующие оси, системные функции, тд.. для Xpath в отдельной ветке форума(которую могли править только вы, чтоб лишить её лишнего флуда).
Сам Xpath видимо увесистая функция.
Тяжко незнающему догадыватся
Функция как раз очень простая. Передается один лишь параметр, непосредственно XPath запрос. Сами запросы могут быть довольно сложные. Но так как XPath в Reports может возвращать лишь значение одного текстового узла, все запросы упрощаются до конкретного указания пути к узлу.
Начнем изучение работы репорта с отчетов регистратора, но тут в шаблонах коды под иной XML, придется много править и разбирать.
Пригодится легкий поиск пути в XML.
Такс, для легкого отображения пути к элементу в XML, я использую полезный редактор Notpad++, распространяется бесплатно и открытым кодом (лицензия GNU GPLv2.0), также использую его с выбором определенного синтаксиса при кодинге в Reports.
Тут понадобится плагин XML Tools (dll требуется распаковать в корневую папку программы notepad++, обратите внимание что не в папку плагин!)
Также нужны библиотеки из архива ext_libs.zip которые тоже распаковываются в корневую папку программы notepad++.
Далее Опции/Импортировать плагины выбираем XMLTools.dll и перезапускаем программу.
Пользуемся плагином (дополнением)через главное меню, или быстрыми клавишами Ctrl+Alt+Shift+P.
Получаем при этом в буфер нужный путь с отображением информационного меню на экране.
Приходится начинать все с “0”, поскольку программа в которой я работал совершенно не подготовлена к XML.
Скачал установочный файл Digitals
обрезал папку digitals и папку Templates до вида отображенных на картинках(удалил все “ненужное”, чтоб пока не мешалось, вес программы при этом сократился до 30метров).
В папку Templates и Lists вложил шаблоны и текстовые документы взятые из пакета Регистратора (LandBook.fr3; Zayava1.fr3; Zayava2.fr3).
На всякий случай обновил XMLNormal.dmf
Скачал образец XML файла.
Открыв XML в дигиталсе, запускаю репорт. Далее правлю пакеты документов( добавляю в дизайнер), в которых самым интересным является LandBook.fr3
В этом шаблоне практически все работает без сбоев, надо лишь решить вопрос с открытием изображения(я просто его отключил):
…
{procedure Picture1OnBeforePrint(Sender: TfrxComponent);
var FN:String;
begin
FN:=WorkDir+‘\Pictures\LBCP’+CadNumberClear+‘.bmp’;
Picture1.LoadFromFile(FN);
end;}
…
После запуска отчета, мы увидим странички поземельной книги, с экспликацией и многими полезными полями!
Меня это сильно порадовало, думаю стоит сказать спасибо тем кто трудился над шаблоном, за такие заготовочки!*
* заготовочки именно для технички, а не для того, чтоб заменить регистратор, на дигиталс (хотя это тоже полезно в некоторых случаях)
Первое, что заинтересовало как Дмитрий (Dmitry_Zolotar) перевел форму 6-Зем на XML, насколько я понимаю это его труд. Тут понадобится потратить времени на изучение 
Интересно, что весь шаблон использует условный оператор (if..then…else) постоянно определяя перед нами ин4 , или же XML. У меня даже мысли не появлялось использовать ин4, в регистраторе наверное надо использовать два формата.
При генерации шаблона LandBook.fr3 из ин4 для работы экспликации (формы 6-Зем) потребовалось файл 6ZemCols.txt записать в папку Templates.
Удивительно, что файл в новом дистрибутиве дигиталса 6ZemCols (размером 7,5Кб) “порвал как Тузик тряпку” нашу экспликацию, пришлось доставать из старых "запасов " 6ZemCols (размером 7,4Кб, 07.04.09 даты рождения), при этом экспликация приобрела читабельный вид, но поля шифр рядка и номер рядка заполнились не правильно
а вот, что это за зверь: XML573Root:String; //путь к корню XML573?
ко всему применимо:
then XML573Root:=IIF(IsNodeExists(‘InfoPart’),‘’,‘EmbeddedXML/UkrainianCadastralExchangeFile/’); ?
XPath запрос возвращает список узлов, удовлетворяющих условиям запроса. В Reports функция XPath не возвращает список узлов, не возвращает даже один узел. Она возвращает значение заданного текстового узла. Поэтому она намного проще чем полноценные XPath запросы.
Шаблоны новой версии Регистратора действительно создаются как универсальные, способные работать не только с данной программой, но и напрямую с Digitals. Регистратор последней версии передает в Reports все данные в виде XML файла, скопированного в буфер обмена. Данный XML содержит обменный UkrainianCadastralExchangeFile(он же XML573), целиком записанный в ветку EmbeddedXML. А также дополнительную информацию, которую XML573 не содержит: номер и тип заявления, данные о заявителе, данные о лице, заключающем договор и проч.
Во всех шаблонах используется переменная XML573Root, которая как раз и указывает на узел, содержащий обменный XML. Это пустая строка, если в буфере только обменный файл, или путь EmbeddedXML/UkrainianCadastralExchangeFile/, если в буфере данные из Регистратора.
Продолжаем “пилить” программу .
Добрался до setup.ini и папки Lists.
В папке Lists удалил во всех списках “лишние” области. Вряд найдутся специалисты орудующие в нескольких областях.
Далее ручки потянулись в setup.ini поправил нужные константы.
Выяснилось, что область, областная санстанция, областные экологи, областная архитектура (названия в разных падежах) превратились из списков в одну строку, в бессмысленную кучу файлов которых и без этого многовато.
Меняем:
RepНазва(Область)=SEF(RegionID,‘Obl.txt’)
DMTНазва(Область)=SEF(CUT(1,2,P[ID106]),Obl.txt)
на:
RepНазва(Область)=… область
DMTНазва(Область)=… область
и тд..
Таким образом было удалено 21 файл однострочных списков.
Хорошо б, чтоб LEdit.exe понимал этот файл (хотя это не критично, увидим позже почему).
Чтоб получить возможность работать в setup.ini с населенным пунктом, головой сельской рады(города), и сельским землеустроителем, в репорте требуется ввести еще одну константу аналогичную:
RegionID:=Copy(CadNumberClear,1,2);
RayonID:=Copy(CadNumberClear,1,5);
RadaID:=Copy(CadNumberClear,1,8);
LocID:=Copy(CadNumberClear,1,10);
Аналогично для DMF и репорт в setup.ini запишем:
RepНазва(…)=SEF(LocID,‘…txt’)
DMTНазва(…)=SEF(P[ID106],…txt)
Тут придется дописать списки голов, сельских землеустроителей и населенных пунктов.
Вот только LEdit.exe после такого надругательством над ini нужно похоронить .
В общем займусь правкой списков, благо они уже существуют(но устарели).
Никто не мешает “надругаться” над mysetup.ini, например
Как это ?
Не понимаю выгоды.
Лишенный 21го стандартного файла LEdit.exe все равно не выживет.
Файлы из дистрибутива можно было оставить, а в mysetup.ini ссылаться на другие файлы
Скрипт, подобный приведенному ниже, используется регистратором для формирования кадплана позем.книги по шаблону LBCP.dmt и сохранения его в растр под “правильным” именем.
Для формирования поземельной книги из Digitals:
- Откройте XML-файл
- Выполните скрипт
$PP=@ProgramPath
$N=@Map.Count
$I=0
%Loop
$I=$I+1
$LID=@Map.Object[$I].LayerID
@If $LID=70005 then @GoTo %Exit
@If $I<$N then @GoTo %Loop
@Break Не найден объект слоя XML-ділянка
%Exit
@Map.SelectObject $I
Документы | LBCP
$CPMap=@ActivateMap
@Dialog.WaitBox Отредактируйте кадастровый план и нажмите кнопку “Продолжить”
Файл | Сохранить
$FN=@Map.ClearShortFilename
@CreateFolder $PP\Pictures
$FN=$PP\Pictures$FN.bmp
@Map.SaveToTIF 300 24 $FN
@CloseMap $CPMap - Запустите генератор отчетов.
Это понятно, притом надо все шаблоны перелапатить с setup.ini на mysetup.ini, этим самым отречься от следующих стандартных шаблонов.
Сохранив жизнь LEdit, еще больше усложнив программу и её понимание.
Можно и не использовать setup.ini, а работать на прямую с txt, и менять ничего не придется, в любом случае количество файлов-списков еще увеличится.
Надо помозговать над альтернативным методом редактирования списков.
За скрипт отдельное спасибо(редко ими пользуюсь).
Все-таки решил “похоронить” LEdit, буду править setup.ini.
А для “пакетной” правки я верну родной setup.ini (на время правки списка) выполню изменения, и снова верну рабочий ИНИ файлик на место.
Более разумного решения пока не вижу, разве править LEdit, но это не в моих силах, и приоритет тут не высок