О вертикальных линиях

lsgsoftware

Все мы часто сталкиваемся с проблемой печати в позиции отчета текстового поля с заранее неизвестным количеством строк(пример:счет-фактура - поле - наименование товара).Таких строк может быть одна, а может и двадцать одна.Конечно, ручками это сделать можно(делали много раз), но эта работа требует немалой квалификации и к тому же очень нудная и скучная.За что мы любим Кларион - да за то, что очень много рутины он берет на себя, оставляя программисту только творчество.Вот тут протестил(уже не в первый раз) следующий вариант:
- текстовое поле - в мемо-переменную
- ввод данных в форме - в переменную типа text(нужно помнить,что можно набить ровно столько текста, сколько влезет в бокс)
- в репорте - оставляем в первой детальке одну строку,текстовое поле берем из переменной типа text(memo) и помещаем в боксе типа text высотой в одну строку(не забываем ставить галки на skip,resize)
- во второй детальке чертим горизотальную линию-разделитель.
Вот и все, все работает очень четко , но: без вертикальных разделительных линий. Сколько я перевидал буржуйских отчетов - ну не принято у них использовать вертикальные разделительные линии(я думаю, что ноги растут еще со времен матричных принтеров,где вертикальные линии здорово замедляли печать).Но у нас бездельники-"проектировщики и постановщики задач" рисуют формы похоже специально, чтобы затруднить жизнь программистам и уж вертикальные линии-разделители при этом есть обязательно, хотя по делу они и не нужны.
Так вот, в описанной выше схеме ну никак у меня не получается придумать простой способ(без написания длинного кода ручками) прочерчивания вертикальных линий-разделителей переменной длины.
Может кто слышал об этом и подскажет решение

Amike34

Может поможет Вам это...
printreport routine
! Пример (может, поможет) динамического изменения высоты детальной строки и ?Box2
! если вертикальных линий много, соберите их рядом (подряд)
! и в LOOP им всем в динамике скорректируйте высоту
! Примечание ?detail1 и ?GFUzlU
! это USE переменные в Report
OPEN(Report)
Detail1Height# = Report$?detail1{PROP:Height} ! запомним высоту детальной строки
GFUzlUHeight# = Report$?GFUzlU{PROP:Height} ! запомним высоту GFUzlU
!!!...
IQ# = RECORDS(Q)
IP = 0
LOOP IR# = 1 TO IQ#
!!...
GET(Q,IR#)
DO NEXTPROCESS
IF IP => 2 AND IP = NumbHOM# ! если кол-во помещений узла учета =>2
SETTARGET(Report,?GFUzlU) ! нужн.поля должны быть между ?GFUzlU и ?GFUzlUK
?GFUzlU{PROP:Height} = GFUzlUHeight# ! восстановим
UNHIDE(?GFUzlU,?GFUzlUK) ! пропечатаются
SETTARGET
ELSE
SETTARGET(Report,?GFUzlU)
?GFUzlU{PROP:Height} = 0 ! высота GFUzlU = 0
HIDE(?GFUzlU,?GFUzlUK) ! спрячем (не печатаем)
SETTARGET
END
IF IP = 1
Report$?Box2{PROP:Height} = Detail1Height# - 2 ! восстановим высоту BOX2
Report$?detail1{PROP:Height} = Detail1Height# ! восстановим высоту детальной строки
ELSE
Report$?Box2{PROP:Height} = Detail1Height# / 4 * 3 - 2 ! уменьшим высоту BOX2 ! 396
Report$?detail1{PROP:Height} = Detail1Height# / 4 * 3 ! уменьшим высоту детальной строки
END
!.
!.

!!! ручками (может можно в дизайнере еще как-то)
!!! нужные вертикальные линии соберите рядом (чтобы они были друг за дружкой)
!!! далее RII# = Report$?U:Rgkal_1{PROP:Feq} - 1
!!! и в цикле через Report$(RII#){PROP:FontStyle} = FONT:Bold+FONT:underline
!!! их можно обработать все
!
!!! Тут еще динамическое изменение фонтов и т.д. !!!
! фонты разницы Гкал вида ТЭ по узлу учета ?Detail
RII# = Report$?U:Rgkal_1{PROP:Feq} - 1 ! от № поля обеспечим
LOOP I# = 1 TO 7 ! переход к индексу массива
RII# += 1
IF U:Rgkal[I#] < 0.0 ! от значения
Report$(RII#){PROP:FontStyle} = FONT:Bold+FONT:underline !жирн.,подч.
ELSE
Report$(RII#){PROP:FontStyle} = FONT:thin ! обычн.
END ! FONT:regular
IF U:Rgkal[I#] > 0.0
SETTARGET(Report,?Detail)
(RII#){PROP:Disable} = 1 ! затемним
SETTARGET
ELSE
SETTARGET(Report,?Detail)
(RII#){PROP:Disable} = 0 ! уберем затемнение
SETTARGET
END
END

PRINT(RPT:DETAIL1)
END
LocalResponse = RequestCompleted
DO CLOSEPROCESS
!!...

Игорь Столяров

Так много всего ... Вот пример печати линий в счет- фактуре c Detail переменной высоты:

ReturnValue = PARENT.TakeRecord()
! --- Вставка ---
Loc:LineH = Report$?Tov:Name{PROP:LineHeight} * Report$?Tov:Name{Prop:LineCount}

Report$?Line1{PROP:Height} = Loc:LineH
Report$?Line2{PROP:Height} = Loc:LineH
....
Report$?Line12{PROP:Height} = Loc:LineH
Report$?HLine{PROP:YPos} = Loc:LineH
! --- Вставка ---
PRINT(RPT:detail)

Где ?Tov:Name - это TEXT Field с наименованием товара, которое меняет высоту,в зависимости от длины товара, а ?HLine - нижняя разделительная линия для строками ... остальное думаю понятно.

Писал на память, так, что не обесудьте, если сразу не странслируется ... но это работает точно.

Amike34

Report$?Line1{PROP:Height} = Loc:LineH
Report$?Line2{PROP:Height} = Loc:LineH
....
Report$?Line12{PROP:Height} = Loc:LineH
!!!!!
! вместо этого можно
! что_то подобное
In# = Report$?Line1{PROP:Feq}
Ik# = Report$?Line12{PROP:Feq}
! если Line расположены подряд
LOOP I# = In# TO Ik#
Report$(I#){PROP:Height} = Loc:LineH
END

в цикле LOOP I# = FIRSTFIELD() TO LASTFIELD()
надо проверять I# на Create:Line, принадлежность (prop:parent) нужной детали и на нулевую длину, а не надеяться на то, что все верт. линии идут подряд.
И ещё, я бы для таких отчётов устанавливал разрешение в самых маленьких единицах (кажется в тысячных дюйма), иначе произведение PROP:LineHeight * Prop:LineCount будет "гулять" из-за округления

Amike34

Вдогонку, в генерируемых Report-ах в CLARION 6.3, насколько помню, автоматом в нужных местах (в зависимости от ширины полей в detail) расставляются вертикальные линии, т.е. можно подсмотреть как там это реализовано и все их сгенерировать. Ну и заодно за высотой вертикальных линий проследить.

Игорь Столяров

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

Есть только один маленький ньюанс: потом, при редактировании отчета, добавлении полей и т.д. нужно постоянно парится и проверять, что бы в эту последовательность линий ничего не вклинилось ...

Если бы их было сотни две, наверно имеет смысл, а для отчета класса счет-фактуры, проще повторить 12 операторов и больше никогда про них не вспоминать ...

Раз заговорили про линии - есть интересный вопрос: Сколько линий
(LINE) может быть в одной структуре REPORT ? Что бы этот отчет открывался в генераторе отчетов ... Спрашиваю потому, что есть такой отчет "Транспортная накладная, форма 1-T", на 2-х листах.
Его никогда не получается полностью нарисовать, приходится около трети линий дорисовывать динамически, при создании отчета ...

Кто-нибудь пробовал целиком нарисовать такую форму ?

lsgsoftware

Большое спасибо за обсуждение проблемы.Мне кажется,что ближе к цели предложение Игоря Столярова. Ничтоже сумняшась решил проверить - и вот чем душа успокоилась:
Всего то в точке вставки Take Record вставил код

LineH = Report$?fi11:txt{PROP:LineHeight} * Report$?fi11:txt{Prop:LineCount}

Report$?Line1{PROP:Height} = LineH

где fi11:txt - текстовое поле из мемо-переменной,размещенной в боксе текстовой переменной(тип text) репорта,а Line1 -вертикальная линия-разделитель
И все вроде бы заработало:
1-я строка отчета -нормально, а вот дальше в следущих строках стали появляться пустые места сверху, т.е. переменное количество строк печатается правильно,линия-разделитель -правильно,но сверху нарастающее по непонятному алгоритму изрядной количество пустых строк. Игорь,может посмотришь, если есть время.Заранее благодарен
|

Игорь Столяров

Легко. Косяк-то известный. Нужно просто в окне предварительного просмотра "выкрутить" маштабирование на максимум и посмотреть, как на самом деле Report прорисовывает линии. Накапливается погрешность на ... толщину самой линии. Попробуй добавить небольшое смещение (его легко подобрать методом "тыка", в зависимости от параметров Detail):

Loc:LineH = Report$?Tov:Name{PROP:LineHeight} * Report$?Tov:Name{Prop:LineCount} + 15

или

Loc:LineH = Report$?Tov:Name{PROP:LineHeight} * Report$?Tov:Name{Prop:LineCount} + (Report$?Tov:Name{Prop:LineCount} * 7)

Как я уже говорил - пример написал из памяти.

lsgsoftware

Спасибо, Игорь.Но твой совет не помог - стало еще хуже,хотя чувствую, что решение где-то рядом.Наверное, собака зарыта в переменной типа text с боксом переменной высоты.Еще результат - при переходе на следующую страницу опять первая строка печатается нормально. Впечатление, что накапливается не толщина, а высота.Может быть посмотришь еще разок

Amike34

Игорь же писал:
1.Нужно просто в окне предварительного просмотра "выкрутить" маштабирование на максимум и посмотреть (zoom)- нужно убедиться все ли переменные и вертикальные линии точно укладываються в "высоту" detail.
2. может еще и высоту detail аналогично вычислять динамически.

lsgsoftware

Amike34 писал(а):Игорь же писал:
1.Нужно просто в окне предварительного просмотра "выкрутить" маштабирование на максимум и посмотреть (zoom)- нужно убедиться все ли переменные и вертикальные линии точно укладываються в "высоту" detail.
2. может еще и высоту detail аналогично вычислять динамически.

Извини,но про ZOOM- это не из той оперы.Действительно, если что-то забыть вне ожидаемых границ детальки,то пойдут косяки. И zoom здесь не поможет.Поможет property editor, который и покажет "забытое" поле, особенно если оно вне границ отчета.Такое часто бывает, если рыбу отчета сделать в дизайнере, потом все ненужное поудалять. Но, у меня в детальке живет бокс-text высотой в оду строку, а раздвигает этот бокс сама клаша. Как решить эту проблему ручками я конечно знаю и делал это много раз, но хочется найти простое решение , которое может и другим пригодиться. Мне кажется, что подход Игоря Столярова где-то близок к решению этой проблемы.

Amike34

Понятно, что где-то что-то накапливается, возможно из-за каких-то мелких багов в вычислениях(округлениях) позиций detail или box.
Report у Вас в inches,points,mm?
Может быть проследить за конкретными значениями позиций этих элементов во время выполнения?
Может быть еще как-то влияет charset этих элементов?

Игорь Столяров

Я написал абсолютно рабочий вариант. И его не я придумал - кажется давно, где-то в буржуйском форуме подсмотрел.
Тоже TEXT BOX, тоже динамически расширяется в зависимости от кол-ва строк, все прекрасно работает.
Ну, не знаю как еще сказать - возьми покрась фон TEXT в какой-нибудь яркий цвет, тогда при просмотре отчета четко увидишь, где граница блока текста и как проходят по нему линии. А величина поправки на смещение линии напрямую зависит от толщины линий (я написал для толщины по умолчанию).

У меня все отчеты и размеры в тысячных долях дюйма.

lsgsoftware

Ну я наверное всем уже надоел.Что удалось выяснить: количество пустых строк в очередной позиции отчета пропорционально количеству строк в боксе предыдущей позиции, хотя высота вертикальной линии вычиляется правильно и лежит она на месте, да все данные позиции смещены вниз.Думаю, в этой проблеме можно погрязнуть(тем более как ее решать для конкретного проекта я знаю и много раз решал), легких путей наверное не будет, а жаль.Хотя може меня и заклинило где-то.Наглая просьба к Игорю Столярову:
может сбацаешь простейший тестовый примерчик и кинешь мне на мыло
lsgsoftware@yandex.ru