Not removing blank lines from Report footer 3

[SitesMasstec]

Hello collegues!

I created a report with some labels in the Footer, and gave directions to remove blank lines if they are blank:

In "Print only if expression is true" I have:

LEN(ALLTRIM(XObsRodape1))>=1

I have the same commands in the Detail band and it works fine.

Or this command ("Remove line if blank" checked) does not work for the Footer of a Report?


Thank you,
SitesMasstec

 

[Chris Miller]

I also think you have a misconception about what removing blank lines means. When the first line in your footer is blank and thus removed, that doesn't shrink the footer, it allows the second line to be printed at the place that's now not occupied by the first line. In that aspect it is as mJindrova said initially, the footer heihgt remains as is.

In the old thread thread184-1821100 I showed that removed lines in a detail band cause that detail band to have an effectively lower height, the gain of space is to the bottom, as further lines can be printed earlier, the detail bands with only one or even no populated lines end earlier, the shrink is always happening at the bottom.

A footer is defined as beginning a certain height above the bottom margin, if a footer even shrinks at it's bottom, it does not change its top margin.

So your only chance to get more space was in the detail band anyway. You made a sacrifice of easier maintainability by overlapping controls, Marks last example using my table design shows that there is no need to have 6 or 3 lines in a band, just because goods are in one of three units, just make the unit data and it's just one line that prints whatever unitsymbol is necessary for that unit from the units table. There's another bad habit I see in data design, not only by legacy code oriented developers, to think some simple data like units are not worth having a table with records about them. There's more you can put in a units table besides the meaning and unit symbol used, you could categorize units to be a weight, length, whatever and store conversion factors to a base unit and then do conversions.

And in the products table, where I have foreseen a salesunitid to point out the unit in which a prodcut is sold. One such unit could also be none, i.e. pieces - for products sold by quantity, like apples or oranges. And while they are only sold in whole pieces, they are still weighed for a price per kg. Such things could be considered and make a units table more useful than just for getting their symbol.



Chriss

 

[SitesMasstec]

Yes, Chris, after reading your last post, and also Mark's posts, I should have created a cursor to receive the data to be printed (product, unit used, etc), without having to overlay all those unit fields, now I see it clearly, .

Indeed, I have been using this concept for a long time (initially using temporary files, instead of cursor), but as you said, it is "bad habit in data design", so, sometimes I forget that professional way of programming in VFP. Of course, I will change the report to that clear way as soon as possible.


Thank you,
SitesMasstec

 

[mjcmkrsr]

...

and another example - this time grouped by OrderItem and Unit

Enjoy

MarK