Как сделать, чтобы производные параметры редактировались и считывались из IN4
Объясню зачем нужно.
Автоматизирую заполнение текстовки для in4 и техничек в шаблоне. Сделал подключаемый список (в папке List), в котором выбирая населённый пункт получаешь параметр содержащий КОАТУУ, зону, населенный пункт, голову с/р, начальника земотдела и т.д. через запятую. А в производных параметрах соответственно считываются данные отделенные запятой из этого параметра. Это работает. Но возникла другая проблема. При открытии in4-файла параметры, которые я сделал производными - не считываются . Кроме того они и не редактируются . Последнее вообще очень удручает, т.к. например если производный параметр используется для склонения по падежам, то единственный вариант поправить неправильное склонение - лезть в rod.txt, dat.txt - что не всегда удобно.
Отправил. Параметры 9 (исх. параметр),16,17,18(как пример производных) - в слое in4_квартал. Хотелось бы, чтобы все производные параметры могли редактироваться и считываться из IN4. Если Вас не затруднит, посмотрите так же параметр 32 (AU) - в слое in4_ділянка. При такой маске можно забить значения всего параметра и при повторном открытии параметра по троеточию в углу сохраняется его разбивка по полям. Но параметр дополняется запятыми в конце(.
Он потому и не редактируется, что производный.
Поэтому и при чтении происходит подмена, все параметры с формулами будут вычислены, а не считаны.
Используйте для чтения шаблон без масок и формул (сохнаните свой в normal.dmf и уберите все производные). А шаблон с производными используйте вызывая его явно, сугубо под составление.
Ага… А если надо открыть In4 - подредактировать и использовать дальше?
Или чего проще - подредактировать подставленный автоматом параметр. Ну, некогда, к примеру лезть в файл со склонением имен по падежам и разбираться какие там окончания надо повписывать. Подредактировал на ходу - сдал работу - отоспался - а уже после этого принялся за редактирования шаблонов… для души, имхо)
К тому же, если я (ни дай бог!) вознамерюсь сделать производный параметр для заполнения адреса по прописке… к примеру, в одном параметре из списка выбираем нас. пункт, а в AD автоматом заполняется все вплоть до ул. (ул, дом, кв - забиваются прочерками - “-,-,-”)…я же ни в жизни не смогу человека прописать в такой-то дом по такой-то улице…ни говоря уже про квартиру
Я вижу здесь только одно решение. Использовать 2 различных шаблона, с одинаковым набором параметров и слоев, коды параметров должны совпадать, только во втором шаблоне в параметрах удалены все формулы. Теперь после копирования объектов из карты, созданой на основе первого шаблона и вставки их во второй шаблон, все параметры станут редактируемые.
Нет. Это сложно. “Правка на ходу” на то и есть, что бы на ходу что-то исправить;)
К тому же, это никак не решает проблему невозможности считывания из in4.
Я вышел из положения таким образом, что те параметры, которые жестко производные (например, КОАТУУ, район, голова ср - от населенного пункта) - таковыми и остались. Подгружаем in4 - они не считались. Ну, и что с того? Мы быстренько выбираем нас.пункт - и всё заполнено. А “производность” остальных параметров прописываем через промежуточный (скрытый) - в их маске. Можно мириться Хотя потенциально, неплохо было бы, если бы производные параметры считывали свои данные только при изменении содержимого основного параметра, а в остальное время могли редактироваться.
Может вам стоит создать свой скрипт. При изминении главного параметра /например Х;У/ одним движением мышки и ее кликом, наполнить обменник. Процедура воплащения такой мысли в жизнь немного трудоемкая, но ничего результат того стоит. На своем примере - если это обычная приватизация, ИН4 с нуля заполняется до 2мин.
Ну, скрипты изучать будем чуть позже) (попробую обязательно ) - с параметрами сейчас закончил (см. предыдущий пост) - перекинулся на шаблон reports.
Cразу камень в огород разработчиков (не булыжник - небольшой такой камешек ) Функция GetV - не поддерживает разделитель “|” (как Get в предыдущей версии reports) - что очень печально, так как у меня есть подпараметры с запятыми в их значении . Хотя выход из положения естественно был найден при ближайшем рассмотрении вопроса, но проблема остается.
Функция GetV является полным аналогом функции GET из Digitals. Но, т.к. в новом FastReport более строгий подход к типам данных, то передаваемые параметры функции необходимо заключать в одиночные кавычки, например:
Проводя аналогию - получим “Два” - тоесть 2ой элемент первого подпараметра (1/2)…
Во всяком случае именно так получается, если будет строка ‘Один Два|Три,Четыре’ или ‘Один Два, Три|Четыре’… проверено
Ваш вариант - либо нерабочий, либо знак “|” считается за пробел
Так ведь не было в Репорте ver 2 функции SEF, она совсем недавно появилась. Кроме того в Reports в отличии от Digitals можно вместо одной формулы написать скрипт. У вас в руках все необходимые функции для разбора строк и работы с текстовыми файлами. Немного упорства и можно добиться всего, что желаешь.
На днях будут выложены обновленные шаблоны тех. документаций для Reports и dmt-шаблоны. Поземельная книга осталась практически в том же виде, исправлены некоторые неточности. Можете выслать пример Вашей поземельной книги или описание ошибок/неточностей в шаблоне.
Если участки смежествуют друг с другом, оптимальнее делать один квартал на двоих (объединяющий).
Примеры такой организации можно увидеть в том же reports.dmf из дистрибутива.
Выделять нужно участки, а не кварталы. Дигитал неявно формирует в буфере обмена инфу из параметров участка, его координат и списка его угодий. Эта информация затем “раскладывается” по бэндам и элементам шаблона Report’а.
Большинство шаблонов расчитаны на одиночное выделение (участок - отчет на него). Для группы участков используются групповые шаблоны, там есть некоторые отличия в организации бэндов.
На некоторых шаблонах как раз для такого случая есть надпись (вернее была) “Нужно помечать квартал” Так что не факт что нужно помечать участки, смотря для какого случая