dBMAN Tutorials #2 in a Series The Report Generator by John C. Leon August 21, 1986 distributed through the H.A.S.T.E. BBS Houston Atari ST Enthusiasts 713-955-9532 permission granted to distribute unaltered original text The example report file for you to look at while following this article is MEMTYPE.FRM. Call it up with the command MODIFY REPORT MEMTYPE. The next to last paragraph of this article refers to a user-programmed report (not generated by the report generator). That program is contained in the MEMLIST.CMD file. Both examples are available for download on the H.A.S.T.E. BBS at 713-955-9532. It was not deemed germane to this tutorial to include data files (DBF files) to go along with the report samples, as you can easily view the report formats and list out the CMD file without having the data and index files. Included on your dBMAN interpreter disk is a file called RPRTI.DBM (2485 bytes in version 2.00L). This is the report creation file called up whenever you use the CREATE REPORT or MODIFY REPORT commands. It is not needed to actually print reports with the REPORT FORM command. This report generator should be viewed only as a handy way to get simple reports. Sophisticated reports and customized formats must be programmed using the dBMAN programming language. Although severely limited, many database applications will not require anything more sophisticated than the built-in report generation functions. However, the manual does not include detailed instructions on how to use each part of the reporter. This article should help fill the void. Today Versasoft hinted that any future revision to the manual would include more detail on using the report generator. The slickest feature of the report generator is its treatment of many of its parts (headings, footers, group headings, field headings) as string expressions. This means that all of dBMAN's string handling commands are available in the reporter. For example, a two-line heading might be: CENTER('Members as of '+DTOC(DATE()),80) DUPCHAR(45,80) This centers a HEADING with the current date, with the second line (HEADING2) being 80 columns of hyphens to give an underlined appearance (ASCII code 45, repeated 80 times). Similarly, you could send your printer a set of escape or dBMAN Tutorials - 1 - The Report Generator control codes. The above example would look like this if you wanted the headings in emphasized print on an Epson: CHR(27)+CHR(69)+CENTER('Members as of '+DTOC(DATE()),80) DUPCHAR(45,80)+CHR(27)+CHR(70) The total length of the string expressions permitted in various places in the report generator may or may not be enough to contain both the text of your desired string, plus the string operators you want. The alternative is to program your own report (the subject of a future article?!). If you provide for a footer, you will find that the footer line in your printed report butts up against the last line of report detail on each page. Adjusting the line count does not help, as the footer line is basically programmed to print directly following the last detail line, regardless of where on the page that last line is located. It would be nice if a blank line appeared between the detail and footer. The solution (suggested by Versasoft's support staff) is to simply decrease the report's line count by 1, PLUS to begin your footer string with an ASCII carriage return and line feed: CHR(10)+CHR(13)+CENTER('Page '+STR(PAGENO(2),3),80) In this way, the CR/LF codes are sent to the printer before the footer text, creating a blank line. You are given 4 lines of text for each field heading. If you only use 1 or 2 lines, use the bottom ones. The reporter will always use the full 4 lines, rather than suppressing the unused lines. In other words, every report contains a band of 4 lines for field headings. They will print as blank lines or contain strings, depending on your design. Further, one blank line is ALWAYS left between the fourth line of field header and the report detail. Conversely, there is no blank line left between your group headings and detail, or between your group footers and detail. Here again, if you want a blank line under each group heading or before group footers, add a CR/LF string after the group heading string (or before the group footer string). I don't advise doing so, as there is not always a way to know how many times a group heading or footer will appear on a page, and the report's line counter won't "know" that you have a variable number of such blank lines popping up from page to page. I prefer to use emphasized print to set off my group headings versus use of blank lines, as you will see in the MEMTYPE.FRM file. In the alternative, you should be able to safely specify a page eject after each group. I say "should" because regardless of whether you answer yes or no to the question about page ejects, the program refuses to generate them. It turns out that you won't get page ejects unless you have a group footer! If you really dBMAN Tutorials - 2 - The Report Generator don't want any group footer but do want page ejects, use a group footer of ' ' (a blank space within single or double quotes). With page ejects, you could be assured that only one group heading would appear under your field headings on each page, and could safely provide the CR/LF codes as long as you decreased your line count by 1. There is no way to do a simple record count. While you can easily provide for sums of numeric fields, there is no way to simply count the number of items (records) in each group. This is a major faux pas in my estimation. In my MEMTYPE.FRM report, it would have been nice to get a count of how many members we have of each type (charter, regular, affiliate, etc). It can't be done without programming your report in your own code. When specifying column widths, remember that this is NOT the width of the field appearing in that column. If you have a field heading of "STATUS", for example, above a one-character length field, you need to specify a width of at least 6 characters to accommodate the field heading. You may need to experiment with various field widths and the number of spaces between columns to get the precise look you want. If you specify a non-zero left margin and attempt to center anything, you will find that centering will be off by the amount of the left margin. You need to make an adjustment to the character argument supplied in the CENTER function. When specifying a left margin, subtract that number times 2 from the argument. On an 80 column page, if you are using a left margin of 5, your string expression might look like this: CENTER('Members as of '+DTOC(DATE()),70) This instructs the program to center your string within an area of 70 characters, starting from the left margin. Since 5 plus 70 is 75, you will end up with the desired right margin of 5. This same kind of adjustment must be made whenever you use the CENTER function, whether you are centering strings onscreen, in the report generator, etc. In some of my programs I paint a box onscreen with the BOX function. Assume the left edge of the box is in column 12. To center my string on line 10 within the box, I might use the following: @10,13 SAY CENTER('Membership System',56) This command line would center the words "Membership System" on a line of 56 characters, between the left and right "margins" (the two sides of the box). Remember that reports can be directed to your screen, to your printer, or to a disk file: dBMAN Tutorials - 3 - The Report Generator REPORT FORM MYREPORT --->prints to screen REPORT FORM MYREPORT TO PRINT --->prints to printer SET PRINT TO A:FILENAME.EXT --->redirects output to a file REPORT FORM MYREPORT TO PRINT --->prints to specified file SET PRINT TO 1 --->resets print to printer If sending your report to a disk file, and if you have printer control codes in your report format, those codes are saved in the disk file. You can then print the disk file from the desktop, assured that your text enhancements (bold, italics, etc.) are intact in the disk file! Be careful when printing more than one report. If your report has headings, page numbering, footers, et al (and most DO), those variables must be reset before printing another report. If you print a three page report, then another report, your second report will begin with its first page numbered as page 4. Here is the sequence of commands you might use after printing any report to reset all such counters and variables to their default values: SET HEADING TO SET HEADING2 TO SET FOOTER TO SET PAGENO TO 1 SET LINE COUNT TO 60 SET LEFT MARGIN TO 0 SET TOP MARGIN TO 3 SET BOTTOM MARGIN TO 3 SET TOPFORM Depending on exactly which of these conditions may have been changed during printing, you may not have to reset all of them. The above is a complete listing of all variables that COULD be affected. It won't hurt to reset them all. For an example of a report programmed by hand versus the report generator, list out the MEMLIST.CMD file. It takes name and address information, creates a listing with two names across, and uses headings and footers containing string expressions. Note how the program has to keep internal track of line counts, etc. In essence, programming your report merely means that you generate the code to produce the particular format you desire, and that you might have to keep track of printer row/column data. Not a terribly big deal for simplistic reports, but I've lost a lot of sleep programming highly complex reports in this and similar database products for other (gasp!) computers. In tutorial #3 we will cover the SET SAY VIDEO commands. If you have comments, find errors herein, or have specific comments dBMAN Tutorials - 4 - The Report Generator or problems you want addressed, feedback is welcome on the H.A.S.T.E. BBS. Leave messages to SYSOP. dBMAN Tutorials - 5 - The Report Generator