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'm quite annoyed with how this thread evolves, the thread title is about the rpoert footer and it turns out the actual problem is wasterd space over the page footer.

SitesMasstec, you're not alone with this, but the inability of people to even describe their problem has a level here that's beyond comparison with any other forum I worked in.

Please, think about how to describe your general problem, then start a thread. And if you realize during a thread the actual problem has nothing to do with the thread title anymore, just start over in a new thread. You can't get helped, if you are not even able to describe the actual problem you have.

Chriss

 

[SitesMasstec]

So your problem is now in the detail band,

No, Chris, the large space in the last lines of the Detail band, before the Footer, is solved, as I derivated a second version of the report (in the right side of the picture).

Yes I have "remove line if blank" both in left and right side versions. I had to make a version from the left side in the right side, because the last record to be printed in the page reserved 6 lines, even if there is a checked "remove line if blank"! Of course, the report has to preview 6 lines, even if it is going to print only 3 lines. I don't know it the report can do something like a pre-process of a record...

Also, I used "Start group on a new page when less than" 2 cm, for a better presentation.



Thank you,
SitesMasstec

 

[Chris Miller]

Of course, the report has to preview 6 lines, even if it is going to print only 3 lines. I don't know it the report can do something like a pre-process of a record...

That's a good question. I don't think the report automatically starts a new page when the last record wasn't yet processed in the sense of how the needed space for that records detail band shrinks due to "remove line if blank". I doubt it takes the detail band default height as a measure, because with the "stretch with overflow" feature a band that fits in the default height could turn out to not fit, while it's rendered and then a page break will occur. So that decision should always be made when dealing with the detail band, not before dealing with it and assuming it will have its height.

The screenshot doesn't tell how it solves your problem, but I'm relieved, if it does.

Chriss

 

[Chris Miller]

I used "Start group on a new page when less than" 2 cm

It won't make a difference when you have group starts on new page, though.

And it means a detail band (a record) is only printed in case there is enough room for it AND 2cm extra margin space to the footer. If you want to use up all space, then don't use that setting, or reduce it.
It will not mean that the margin between the last record and the page footer can't be more than 2cm, it will indeed always be more than 2cm and depending on how large the last record would print even more than double as much or even more. Setting this to 0cm can lead to the case where the page footer doesn't clearly stand out from the details, that's right, but you obviously got wrong how that works.

Chriss

 

[mjcmkrsr]

@ Chriss

SitesMasstec, you're not alone with this, but the inability of people to even describe their problem has a level here that's beyond comparison with any other forum I worked in.

Unfortunately the evolution of this thread reminds me thread184-1821100 also started by SMT. In fine we had to find out it was not a question of report design but a question of bad data design.

Hence SMT may want to upload some data with the report in order to let us check. Otherwise we will continue and guess what his intentions are.

@ SMT (short for SitesMassTec)

Do you think this book is enough, or is it advisable to acquire "The Visual FoxPro Report Writer: Pushing it to the Limit and Beyond" also?

What's new in Nine is definitely NOT enough in this respect and I hope your knowledge to work with reports stems from some other sources. However I consider Cathy Pountney's book a must-have.

hth

MarK

p.s. You may want to reconsider the demo code I uploaded in 2023

 

[Chris Miller]

MarK,

good summary. What I think remains to check is whether the default detail band height determines how the report engine decides whether a page break is due or not. That could be tested with some defined data and report layout which has varying height due to both the feature of removing blank lines and strectching with overflow.

What is clear is that marginal (no pun intended) savings of page footer heights would solve problems of the last record of a group not printing on the same page though there seems to be enough place. The additional minimum margin demanded with the group bands setting of Start group on a new page when less than" 2 cm leads to at minimum 2cm distance from the bottom of the last record to the top of the page footer, that's for sure. And eyeing that the record that's printed on the next page could have fitted is not checking whether it actually does, important though: with additional 2cm. The report engine will abide to that by the exact measurement, if the record fits and leaves 1.98 cm room that's not enough, SitesMasstec, have you measured that out? I don't see the demand of 2cm minimum distance to the footer. 1cm is making a clear enough distance and the footer is distinguished from a detail band record by layout anyway. If you want a clear separation wou could also put a line at the top of the page footer. All in all I'd say you stand in your own way.

Chriss

 

[Chris Miller]

Looking back into the old thread...

But it's still only working if all fields have been set to "remove line if blank".

I thought about posting that heere aleready and just thought "no, nobody can be that ignorant about what it takes for this feature to work".

Chriss

 

[mjcmkrsr]

Hi SMT,

I wrote a little demo with the data you provided in thread thread184-1821100 and I think I'm able to understand your concern : the waste of space on subsequent pages.

However there is little you can do. You might be able to arrange the height of the detail band for one group, but the next group might require a different setting - especially if Stretch with overflow and Remove line if blank is turned on. You could also play with Group starts on ... (e.g. New Line) but then it becomes really ugly (the group header could be on page x and the group details on page x+1). I guess you'll have to accept this report behavior.

BTW I added a dynamic page footer (Odd page - Even page) and a dynamic group header (changes color)

hth

MarK

 

[Chris Miller]

I haven't looked into the report details, but it works out.

And here's how data normalization helps to not need a detail band with multiple lines of report controls of which you need to remove some.
I chose to use sample data - Northwind - and a simple orders report listing all orders of a customer.

Here's the report design:

And here's the output (first few orders of ALFKI:

And here's code preparing the data relations for the report:

Close Databases All

Open Database _samples+"Northwind\Northwind.dbc"

* Open tables ordered
Use Customers In 0 Order Tag CustomerId
Use Orders In 0 Order Tag CustomerId
Use OrderDetails In 0 Order Tag OrderId
Use Products In 0 Order Tag ProductId

* set relations
Select Customers
Set Relation To CustomerId Into Orders

Select Orders
Set Relation To OrderId Into OrderDetails

Select OrderDetails
Set Relation To ProductId Into Products

* Set 1:many relations
Select Customers
Set Skip To Orders, OrderDetails

Select Orders
Set Skip To OrderDetails

* Report driving table: customers
Select Customers

Report Form orders for customerid="ALFKI" To Printer Preview

Notice how this is just using xbase features to relate the data and define 1:many relationsships without using SQL. This shows that no matter whether you're in the xBase or SQL camp of handling data, you always normalize data anyway, i.e. the xBase way of using, relating data also uses normalized tables. There's orders in the order table (only having master data about orders) and there's orderdetails, the product items, one for each record. There's not just one order record including the master and all detail data for up to say 10 items.

And the detail band is one item, the item list printed by it expands automatically by as many items as are in orderdetails of the same order. That detail band does not need any "remove line if blank" to work.

The overall report look is just a draft, but it's not there to convince by how good the design can be, it's intent is to show you how you get a simpler report layout and then don't depend very much on how page breaks are done by the report engine. This detail band is all that's necessary to cover orders with just 1 item, 2,3, any number of items. Items are a record each in orderdetails and that single item band just repeats as many times as it needs, done. This is how a normalized database design also cuases no headaches and special needs in report layout.

This is mainly what you're missing, SitesMasstec, not knowledge about advanced report features, just basic knowlegde of everything is enough, including the right database normalization. VFP comes not only with the Northwind but also a Tastrade database, there's a lot in there to learn that.

If you want to run all this on your own, I attach the report and the prg below.

Chriss

 

[SitesMasstec]

Despite the fact that the problem I posted here is about the Footer (thanks Chris and Mark) is solved, it could seem to the user that footer seems too height because of many blank lines in Detail band, which is not the case anymore. "The Devil is in Detail" , literally. This is why I ovelaid some fields in Detail (please see picture from July 13th post). The report only prints line 1 or line 2 or line 3 or line 4. Then line 5 (optional) and line 6 (optional).

So, the maximum the report can reserve for the next record, is 3 lines (instead of 6 lines in the left side of the refered picture) that can stay blank in on page, above the Footer.

Thank you,
SitesMasstec

 

[Chris Miller]

The report only prints line 1 or line 2 or line 3 or line 4. Then line 5 (optional) and line 6 (optional).

And that's exactly a problem of your table design, I bet.

Beisdes, if only 4.8 Oliver Hardys would fit on a bench besides 1 Stan Laurel, the culprit that you can't fit 5 Oliver Hardys is on Stan Laurel being too big, isn't it?

Chriss

 

[mjcmkrsr]

Hi SMT,

The report only prints line 1 or line 2 or line 3 or line 4. Then line 5 (optional) and line 6 (optional).

Without wanting to offend you, but that's crazy. You may want to go back to the basics and reconsider your data design. There a quite a few books around - e.o. Programming Visual Foxpro 3.0 by Whil Hentzen ISBN 1-56276-325-3. It has been written in 1995 - hence rather old -, but its step by step instructions of how to design data are still true today.

You may also have a look at my demo code (I uploaded it again), how I "normalized" the data you provided in thread184-1821100 and how they are shown in the report.

hth

MarK

 

[SitesMasstec]

Chris & Mark: My table has 4 fields for line 1 or line 2 or line 3 or line 4 for just one line be printed: if the item is Flour (Kg), Milk (L - litre), Tape (M - meter), Fabric (M2 - square area)

I can't create just a field for the Product/Item and a field to register the UNIT for the Product/Item (KG,L,M,M2, etc).

Thank you,
SitesMasstec

 

[Chris Miller]

I can't create just a field for the Product/Item and a field to register the UNIT for the Product/Item (KG,L,M,M2, etc).

Yes, you can

table1: products
id, productname, saleunitid
1, milk, 1
2, water, 1
3, flour, 2
4, sugar, 2

table2: units
id, unitname, unitsymbol
1, liter, L
2, kilogram, KG

table3: orderitems
id, productid, qty
1, 1, 2
2, 3, 1.5

Select * from orderitems ;
left join products on products.id = orderitems.productid
left join units on products.saleunitid= units.id

The unit then is data, you print the productname, qty and unitsymbol.

And if you have a product measured in a missing unit, you just add it to the units table. This is just straight forward thinking you're lacking, it's not even that hard to do. If you're trained about this it'll flow out of you without needing much thought about it.

Chriss

 

[SitesMasstec]

Yes, Chris, this is for an Order report. I use the way you showed above.

My report in this post is about a Price List, that is, for a list of prices of all products for sale.

Thank you,
SitesMasstec

 

[Chris Miller]

Fine, SitesMasstec,

you're not even reacting to the main points. This is not about the specific topic of the data or the report, this is about the general idea that you can design a database that has all you need in the right way so that you don't require such ill constructs.

Chriss

 

[tomk3]

Hello,

just to add to the tips here :

With a good datadesign (see above) I recommend to generate a cursor with the data and even in the order you need and use that for the report.

Regards
tom

Everything in datacentric applications starts with good datadesign , see exspecially Chris sample.

 

[Chris Miller]

Yes, Tom, that's an often used and recommended way of reporting.

Instead of the code I posted you could do a query into a report cursor starting from customers, joining orders, orderdetails, products into one big report cursor and drive it from there. I showed the way with SET RELATION and SET SKIP because SET RELATION is something I do see legacy programmers use and know, SET SKIP not so much, but it shows that even without SQL the intention of the xBase language constructs does not differ from SQL about the normalization of data. The concept of primary index (or candidate for free tables) and foreign keys also points that out. Still the database design of legacy programmers often is just one table containing all fields necessary for a form, tons of textboxes where you could use grids and listboxes, etc., etc. And then some "array" fields of which sometimes only some are used up and need "remove line if blank" to adjust. If you reject learning SQL it still doesn't mean rejecting database normalization, too, is a good idea.

All the detail problems that you have, SitesMasstec, can be traced back to not having a normalized database design. For example the way you need "remove line if blank" so often. Even considering VFP has a bug in not treating bands in their size as rendered but as designed and doing too early page breaks for that reason, you don't need a workaround or bugfix if by relation or joins you only have as much records as are really needed to print and detail bands that each only cover a single line and are always populated because there is no such thing as unpopulated fields in the data, the number of lines just results from the number of detail records.

You trade one easier aspect with a lot of problems everywhere else. And why? Just because some orderitem record like 2, 3, 1.5 only having numbers and no product name etc. is looking weird and wrong to you? It's the norm that a record which only points to lists by an id looks like that, the product name is in the products table and only there, it's looked up, a join is like a Lookup(), but that function, although it is xBase, too, seems unknown. People know LOCATE and SEEK, well that's two commands that also compare to what a RELATION or a JOIN does. You actually know the concepts, but still refuse to use them, that's what's so sad about this.

Chriss

 

[SitesMasstec]

Chris,
In the earlier version of my report, each record could, theoretically, print 1 to 6 lines. After I overlaid some report fields in the last version of the report, each record can print 1 to 3 lines only, and with use of ICASE in the footer, the amount of blank spaces in the end of each page decreased, and it is ok.

I have also reading again the posts from you and Mark, and trying to understanding and testing, researching also in some books I have from Hentzenwerke and others about VFP. This week I will be ordering the book "The Visual FoxPro Report Writer: Pushing it to the Limit and Beyond" cited by Mark.

Maybe I am 10 years late about knowing the fantastic possibilities of the Visual FoxPro language.


Thank you,
SitesMasstec

 

[mjcmkrsr]

Hi SMT,

This week I will be ordering the book "The Visual FoxPro Report Writer: Pushing it to the Limit and Beyond"

That's a good idea. However don't forget that in order to drive the reports you need the correct data.
To illustrate this I wrote a little demo based on the data provided by Chriss.
The first report is a "flat" one, the second one is grouped on the units.

Enjoy

hth

MarK