forum.clarionlife.net

Продолжайте Здравствовать!

И еще один эпизод из саги противостояния между мной и стандартным Отчетером (C55H, ABC).

Создается отчет, в котором посредством стандартного Header’a печатается на всех страницах название отчета и другие нужности и красивости. В этом самом отчете предполагается наличие нескольких разных таблиц. С пояснительными надписями касательно их.
Так вот вопрос: как сделать для каждой выводимой на печать таблицы свои header’ы? Да так, что бы на каждой последующей странице (таблицы ведь длинными бывают) вначале этот самый заголовок и печатался? А для страниц без таблиц, но с пояснительными записями, и духа его не было?

С уважением, и даже в какой-то мере с диким благоговением перед крутыми кларионовскими умами,

Александр.

Сколько я такого переделал, но все надо делать ручками. Вместо нидера скрытый детейл - и печатать его по условию.Конечено муторно - но другого пути я не знаю.

Полностью согласен lsgsoftware - в таком случае все придется сделать ручками (нужные тебе header-ы описываешь как detailX и сами DETAILXn связанных headerX описываешь как detailXn ). Ибо других возможностей в "стандарте" просто не просматривается - но даже в таком случае все это не так и сложно реализовать. Лучше все это реализовать в REPORT Source т.е. пишешь сам - Создаешь нужные тебе очереди QUEUE сразу по твоим условиям - и по определенным условиям (нужным тебе) печатаешь вначале HEADERX и DETAILXn по GET(QUEUE,признак выборки).
P.S.Удачи Всем ! В принципе в Source REPORT можно реализовать Все !!! - но что делать? Нужно приложить "ручки".

Нет, это все понятно:
Print(RPT:DetalHeader) ! Напечатали детайл-шапку таблицы
SET(….)
Loop
Next(MyFile)
Print(RPT:Detail) !Напечатали саму таблицу
End
Но как отследить, что слудующая строка таблицы будет печататься на следующей странице, и вместо нее напечатать (RPT:DetalHeader)?
«Вручную» считать напечатанные строки?

Я вдруг подумал, а что, если использовать свойство: Report{PROP:NextPageNo}?

И соорудил следующую конструкцию:
SET(…)
LOOP
NEXT(MyFile)
IF Errorcode() Then Break.
IF PageN# <> Report{PROP:NextPageNo} THEN PRINT(RPT:Hearder).
PRINT(RPT:detail)
PageN# = Report{PROP:NextPageNo}
END
Но она не заработала…
Интересно, я что-то сделал не так, или направление мысли принципиально не верно?

Но дело надо делать – работу сдавать.
Пришлось сделать все быстро, топорно (то бишь - по-русски). Но зато это заработало. Я посчитал, сколько помещается на А4 детайлов+1 шапка. У меня вышло 40. А дальше не мудрствуя лукаво:
SET(…)
LOOP
NEXT(MyFile)
IF Errorcode() Then Break.
IF PageN# > 40
PRINT(RPT:Hearder)
PageN# = 0
End
PRINT(RPT:detail)
PageN#+ = 1
END

Работает оно-то работает, но не правильно это как-то. Во-первых: чуть подкорректировал графику отчета и константу надо пересчитывать (переопределять имперически) заново. Во-вторых: если юзер изменит формат бумаги – вообще мрак полный.

Помощь, помощь нужна мне!

Вообще программный подсчет количество строк на листе дело хоть и муторное, но сверх эффективное. Вот если бы разработчики клариона доделали работу с переменной text, то дела бы пошли лучше.

К большому сожалению - подсчет кол-ва строк на листе для опредения номера страницы дело крайне неблагодарное, даже если у тебя строки имеют фиксированную высоту.
Дело в том, что отчет формируется с учетом высоты листа (зоны печати принтера), которая берется из данных драйвера принтера. Другими словами - один и тот же отчет распечатанный на различных принтерах может иметь разное кол-во строк на листе ... В свое время эти грабли проходили.

Выход: делать зону печати отчета - как в стандартных отчетах 1С, т.е. отступ "по 2 пальца" со всех сторон листа или принудительное начало новой страницы после печати определенного (минимального с запасом) кол-ва строк на листе.

NewUser писал(а):Я вдруг подумал, а что, если использовать свойство: Report{PROP:NextPageNo}?

Но она не заработала…
Интересно, я что-то сделал не так, или направление мысли принципиально не верно?

Вся проблема в том, что "движек" формирования отчета в Кларионе держит в памяти сразу две страницы - текущую и предыдущую. По этой причине невозможно легально отследить завершение первой страницы. А вот следующие страницы уже отследить можно. Но! Это не поможет - если печатаемая деталька не помещается на текущем листе, то производится завершение печати текущего листа (с печатью страничного футера), после чего на новом листе печатается страничная шапка и деталька, которая не влезла на предыдущей странице. Если в этот момент подменить страничную шапку, то новая шапка пойдет только со следующего листа! Т.е., менять страничную шапку необходимо ПЕРЕД переходом на страницу, с которой новая шапка должна печататься. Но только ПОСЛЕ того, как на текущей странице уже была напечатана хотя-бы одна деталька. Иначе новая шапка начнет печататься уже с текущей страницы.
Вообщем, как видно, если использовать стандартный "движек" формирования страниц отчета, то менять страничные шапки будет очень затруднительно, а иногда - просто невозможно.
Выход, как правильно подсказали коллеги, только один - самому формировать страницы отчета. А для правильного решения данной задачи необходимо в любой момент времени знать две величины - текущий остаток высоты рабочей области листа и РЕАЛЬНУЮ высоту печатаемой детальки. Сразу отмечу - даже использование 1/1000 дюйма в качестве единицы измерения отчета не гарантирует правильный ручной подсчет использованной высоты рабочей области листа и ее остаток. Дело в том, что RTL Клариона для всех подстчетов использует внутреннюю единицу измерения, реальная величина которой зависит от используемого в данный момент драйвера принтера. И практически ВСЕГДА будут иметь место погрешности округления при переводе этих единиц измерения в единицы измерения отчета. А несовпадение вычисленной ручками свободной высоты рабочей области страницы с ее внутренним значением может привести к тому, что "движек" RTL сам выполнит смену страницы и, тем самым, "обломает" всю красоту ручного формирования отчета!
Таким образом, для полного счастья необходимо знать внутреннее значение свободной высоты рабочей области страницы и высоту печатаемой детальки, опять-же, во внутренней единице измерения. Сразу скажу - это возможно. Но! Необходимо за этими данными "залезать" в структуру отчета и детальки. Сам я использую именно этот вариант, но не советую тем коллегам, которые плохо разбираются во всех этой "кухне" - вполне возможны проблемы при переходе между версиями (иногда - даже между билдами!).
Кстати! Кроме вышеперечисленного есть еще один подводный камень - РЕАЛЬНАЯ высота деталек переменной высоты. Особенно - деталек с TEXT-контролом, работающим с RTF-текстом! И опять - выход здесь только один - одновременно с основным отчетом открываем временный отчет с теми-же параметрами, что и основной, но только с одной деталькой. И, естественно, в режиме предпросмотра. Перед печатью детальки переменной высоты выполняем ее печать на временном отчете и определяем реальную высоту, занятую этой деталькой в отчете - для этого можно воспользоваться разницей между предыдущим и текущим значениями внутреннего остатка высоты рабочей области отчета. Хотя я предпочитаю брать эти данные несколько по-другому - прямо у самой напечатанной детальки из очереди напечатанных деталек на текущей странице. Эта очередь, как и вся прочая полезная инфа, так-же "сидит" в структуре отчета.

Да! "Заслать-бы" своего "козачка" в SV - что-бы он надоумил разработчиков "открыть" как можно больше такой вот полезной инфы в разных структурах (отчет, окно, контрол) - тем более, что через существующий интерфейс PROP-ов сделать это очень легко!