We have a form that is used in smartclient for printing. It is a simple form with the following parts:
– header
– leading subsummary
– body
– trailing subsummary
– trailing grand summary
– footer
In all parts there is a single html element that contains a runtime evaluated snippet of valid html code. The elements are 10-15 pixels high and the width of the form minus a few pixels. There are no “problem” warnings in the application about this form.
All elements have printSliding set to grow and shrink in height only.
The header, body, trailing grand summary, and footer parts all print correctly and expand and contract depending on the data to be rendered.
The leading subsummary and trailing subsummary parts do not grow or shrink and often will completely truncate the data to be displayed. Sometimes you can see a portion of the data but never all of it. In some cases you can disable shrinking and see the data but… you lose the shrinking.
These forms were originally created in 3.5.x and have worked correctly in the 3.5.x realm for some time. When we converted them to 5.x we noticed these problems.
Is anyone successfully using grow/shrink in leading/trailing subsummary parts with html data?
Hey folks, just adding a little bit to this post since it is our last remaining issue before flipping to 5.2 from 3.5 and it is a big one.
The problem is a bit more simple than was originally thought. Through testing we found that ANY summary part where the element is record based does not grow/shrink. This means that if the element is based on a column or calculation grow/shrink does not function. If the summary element is instead based off a global it does grow/shrink like every other form part (header/footer/body).
Has anyone else seen this or are all you lucky people based completely in Jasper at this point?
The fields do not grow/shrink as you would expect them to because in a subsummary part grouped by pk, the field is linked to a column/calculation dataprovider. This results in null data being fed into the field.
If you would use an aggregation/variable it would work because it would be possible to give it a value…
It is true that in this special case where you group by pk, you will only have 1 record per subsummary and there is indeed a single value in the group for each column/calculation dataprovider… but are you sure this worked in 3.5?
I looked a bit more into it, the data used for layout in this case is null, but when displayed, the fields do contain the expected values.
I’ll keep you posted.
There is urgency on our side as this bug is holding up our departure from 3.5. We had planned on going straight from 3.5 to 5 and have a version completed and tested except for this issue. Many of our most important reports use this so we can not release without it. There is more to the story of releasing now but I won’t get into that. We could test a beta if possible.