I have a report created with Digital Metaphors ReportBuilder (VCL edition, in Delphi XE3).
It's an invoice, with header, detail and footer bands.
When the data fits in one page, all is well.
If I have more data, that fills, lets say for the sake of argument, 2 pages, I would requires:
Footer band only in the last page
On all other pages, the footer band should be replaced with only the running amount from the detail band, up until that page (from the first one).
On all but the first, the header should include the running totals of all previous pages.
Something like:
Page 1:
- (Header)
- Detail
- "Value until now: (Sum of one the the fields present in the detail band)"
Page 2:
- (Header)
- "Value until now: (Sum of one the the fields present in the detail band) of previous pages"
- Detail
- Footer
I've tried to investigate group totals, using a DBCalc component, but those aren't aware of the page. It only shows the total in the end, and not at the end of the page.
Any pointers of how I could do this?
Thank you
You will need to make some use of the Calc tab, in order to decide when you want certain bands to be shown or hidden. The Report has a PageNo property which you can use to decide when to show a header or a footer, in the header or footer's BeforePrint event.
As for showing a running total at the bottom of each page, you could use a ppRegion component (which is the ReportBuilder equivalent of a Panel). Again, you can use the BeforePrint event to decide when this shows.
The running totals themselves should be done using ppVariables. As you traverse through the data, add values into each variable that you need. Put these variables in the Region mentioned above, and they will display the value as it is at the end of each page. Timing can play a part here, so you may need to adjust the Variable's CalcType, ResetType, CalcComponent and ResetComponent properties to fit your needs.
I have been using ReportBuilder for almost 10 years and believe me, everything can be done, but some operations may just take time to perfect. We now use it exclusively in our software, both for the standard reports that we issue with our product (over 300) and for users to create their own reports.
Related
Assuming that I have a Title, sub detail and footer. Both footer and title are static (won't change) while the sub detail is dynamic, basically drawing a table from a database.
How is it possible to make it load a specific amount of lines in the Sub-detail and creating as much pages as needed? Let's say I have 30 lines in my database table. and I want to limit 10 lines per page. that will make it 3 pages
you could have a local variable keeping track of the number of time the detail before print event has been called. Once it hits 10 call NewPage()
You can use a child band
Enter your text in the child band, and when the data is more than one page, place a portion of your data on the next pages.
You can have more than one child band.
We are developing a BI Publisher invoice print report using RTF layout. This report prints the customer details at the top of the page, followed by the invoice lines' details, and a summary table (of amounts and taxes) at the bottom of the page. Brought-forward are carry-forward totals are displayed at the top and bottom of each page (in case of multi-page reports).It is important to maintain the consistency of the print format (so that the customer address is always at the top left corner of the page, summary table is always printed at the bottom etc). To print the summary at the bottom of the page for each invoice, we have used the tag with section break, as recommended in the user guide. This works fine in situations when the invoice has multiple lines spilling over to the second page.
However, we are facing an issue in a particular scenario : Invoice has few lines that fit in the first page itself, but there is no space left to print the summary table in the same page , so the summary table alone is printed in the second page at the bottom. In this case the carry-forward total in page 1 and the brought-forward total in page 2 are not being displayed. If you have observed a similar issue anytime please suggest how to fix this.
Consider separating your sections and not using Word's header and footer.
Place this code at the start of your document
<?initial-page-number:'1'?>
<?call-template:tHEADER_VERSO?>
<?start:body?>
<?call-template:tHEADER_RECTO?>
<?call-template:tCONTACT?>
<?for-each#section:On_Payment_Terms_S3?>
<?call-template:tDETAILS?>
<?end for-each?>
<?end body?>
<?call-template:FOOTER?>
Then to define a section
<?template:tFOOTER?>
insert content here
<?end template?>
That way the document will always preserve enough space to print your carry-forward totals. I experienced the same odds results when you put your carry-forward in the Word's footer.
I have a form which has a table which may contain 0 rows or several rows.
The problem is that if there are several rows I want close the table on the first page before the content spills over to the next page. Then create another table for the rest of the rows on the next page along with a nice header and table headings. The hard part is, because characters have different widths and I can't predict what the user will type, it's hard to calculate how many characters can fit on a row and how many rows can fit on a page. Also if the user types something in some of the row data, it wraps to a 2nd row.
The printout looks bad when the row has only a few rows because there is a lot of whitespace on the bottom so I was thinking of adding in blank rows to fill it up. But again, I won't exactly know how many rows I need to fill before it spills onto the next page.
Does anyone have a solution to this?
EDIT:
Sorry about that. To be more clear on what I'm doing, I created a form view using CF and HTML which mimics visually like a paper invoice. Invoice line items can be added in dynamically via AJAX. There's a bunch of info to be filled out on top (Company name, address, etc), then in the middle there's the invoice lines in a table with column headings, then under it there's more info to fill out including signature fields. This format cannot be changed as it is a requirement.
So the form layout is:
Top section (info including customer info and a bunch of other things)
Middle section (table of invoice line items)
Bottom section (a bunch of other info including signature fields)
Visually on the page the above format is maintained and if there's a lot of invoice line items added, the page just scrolls and the bottom section is still at the end.
An unlimited number of invoice lines can be added so if you simply just print the page, the invoice lines will overflow onto the next page and the "bottom info" including signatures will be on whatever page the last page may be, which is undesired.
I need it so that whatever number of lines that can fit on the first page without having the form overflow be displayed on the first page along with the "bottom info" including signature. The extra lines are displayed on the next pages with headings "Continuation Page" along with the table column headings of the invoice lines.
My solution is to create a "print view" which creates the form with entered info and cfloops the invoice lines query but only loop just enough to fill the first page. If the addition of another row makes the form overflow then I would stop the loop, display the rest of the form with the "bottom info" and signatures so it all fits on the first page nicely, then do a page break with the header "Coninuation Page" and display the invoice line table with column headers and the rest of the invoice line items. Of course if the continuation page is going to overflow then I would need to do a page break and repeat the "Continuation Page" process. The tricky part is how to determine how many lines can actually fit on the page because the length of data in each row varies depending on user input. Maybe only one invoice line row filled with tons of data is all that can fit on the first page without having the form overflow. Maybe it's 10 invoice line rows when little data is entered.
My main purpose is to keep the entire form on the first page. If several invoice line items are added which pushes the bottom of the form onto the next page then I want to display only enough invoice line rows to keep the form on the first page and have a Continuation Page for the rest of the invoice lines that didn't fit on subsequent pages.
Note: The print is done via a print link on the form page which pops up the print view page (without site heading, etc.) in another window. From there they can either print from the browser or click on a print link that does a javascript print. the same "print view" I created to print the invoice nicely is also used for a PDF view created using CFDocument. The number of characters per line is not the same in the generated PDF as the HTML print view so it's even harder to determine how many rows can fit.
If I understand your question correctly, then a PDF generated with CFDocument would seem to be the optimal solution. Using the cfdocumentitem tag you can specify headers and footers, which insure that the content you want appears on the first page. The cfdocument.currentpagenumber variable can be used to insure that it only appears on page one, and that the header on pages 2+ display the "Continuation Page" text that you desire. There is also a way to get the PDF to auto-print using a DDX file, though that is subject to security limitations.
You mention using CFDocument to create a separate print view, but I didn't see an explanation as to why an HTML version was required as well. I apologize if I missed it.
From personal experience with a similar project last year I would tend to recommend against using CSS for this and instead just require a PDF reader. It's possible that someone with more skill than I could make it work easily, but it was nothing but a headache for us and we could never get it to work quite right.
I use Delphi2006 and QuickReport4 Components in a Clinical Analysis.
I need to print pages with results of patient's exams.
When I print, I use the PageHeader band in blank with a certain height to avoid printing on the paper logo. But when the paper with logo is over, the report enables other band with that same logo.
The problem is that the third Band is the Patient Information Head and it was supposed to appear in every page, but the only band that does it is the Header and Footer.
I've setted up both blank band and information band as HeaderBand, but the QuickReport only accepts the first one as a header.
Any ideas of how do I print another band on every page at the top of the page?
I also have this same problem with the doctor signature that should be on every page, but only appears on the last one.
You can use a ChildBand, having the PageHeader as its ParentBand.
Every time your (blank) PageHeader will be printed, her child will also be printed right after it.
I'd like to create a content box with two tabs. Each tab is associated with a table which contain server-side data. My thought right now is just to load the page with 10 rows worth of data for each table and hide/display each table respectively to begin.
I was then going to toggle display of the tabbed content based on either click events on the tabs OR GET parameters relating to which tabbed content is being acted on (through pagination, for example).
Should I just handle this with UI tabs or is toggling display reasonable in this case? Since the user can update their data, I assume that caching via the tab UI isn't helpful in this case.
Thanks,
Brendan
From what I understood, I don't think its going to be overkill. If you are worried about performance, ten rows for 2 tables is just 20, which is not much. Paginating will also get 10 more rows for each 'click' so it's still good there.
Do use tab activation through click events, but also use GET parameters to know in which page the user currently is, from which tab.
Regarding caching data that you know will change, it might be unnecessary (see my 1st paragraph). Caching can sometimes become unwieldy, so don't add an uneccesary layer of complexity.
As someone who suggests simplicity above all else, I'd discard the whole 'tab loading' thing but leaving the tabs per se (i.e. the interface elements that will be clicked) and when the user clicks each tab, it takes to another page with the tabs too, old-fashioned style.