REPORT FORM - THE dBASE REPORT GENERATOR Part Three

                  REPORT FORM - THE dBASE REPORT GENERATOR

                                Part Three

In past months the various features of the dBASE report generator we've

covered included how to obtain multiple data lines, definition of column

contents and column headings, use of the SPACE() function, totaling and

subtotaling (as well as how to obtain optional headings for the totals and

subtotals), and optional page headings.  This month we'll take a look at

using memo fields with REPORT FORM, displaying report data on screen, and

how to do some fancy report printing with REPORT FORM.

USING MEMO FIELDS WITH REPORT FORM

==================================

If you are still using dBASE III printing memo fields with REPORT FORM is

something of a hopeless task.  In dBASE III REPORT FORM provides no way to

control for page breaks with the memo field and the line counter for REPORT

FORM does not respond if the data from the memo field takes up more than

one line.  The line counter built into the report generator thinks only one

line has been used.

Other than placing each record on a separate page or using some other

similar methodology, you are sure to end up with a report that has page

breaks at the wrong places if there is any significant amount of data in

the memo fields.  Therefore, it is recommended that REPORT FORM not be used

to print memo fields in dBASE III.

Happily enough, dBASE III PLUS provides better control of memo fields in

REPORT FORM (and elsewhere) so it is usually possible to include memo

fields in a REPORT FORM with few or no problems.

Because dBASE III and dBASE III PLUS will not permit mixing of data types

in a single column, it is necessary to place the memo field used in REPORT

FORM in its own separate column.  

Remember that dBASE III PLUS provides the ability to SET MEMOWIDTH TO n. In

addition to specifying the width of the column for the memo field when

creating the report in REPORT FORM, the SET MEMOWIDTH statement should be

used in conjunction with the command to print or display the report:

        SET MEMOWIDTH TO 40

        REPORT FORM xxxxxx TO PRINT

dBASE III PLUS will break or wrap the information in the memo field based

on the spaces between words, hard page returns, etc.  And REPORT FORM's

line counter keeps track of the number of lines used.  It's really as easy

as that.

However, things can get pretty mixed up if MEMOWIDTH is set to a small

number - such as 10 - and the information in the memo field has words 20

characters long.  So try to choose a reasonable width for the memo field. 

I usually try to set up a report so the column width of a memo field is 40

or more spaces.

DISPLAYING A REPORT ON SCREEN

=============================

Once you have created your report displaying it on screen is a fairly

straightforward matter in dBASE and in FoxBASE.  You simply USE the

database and index and issue the report form command:

        USE TEST INDEX TNAME

        REPORT FORM xxxxx

and the report scrolls by on the screen.  Most of my clients want to be

able to pause the report periodically when it is displayed on screen but

dBASE and FoxBASE+ provide no specific utility for this.  The CONTROL/S key

combination must be used to pause the scrolling.  The CONTROL/Q key

combination is used to restart the display.

Theoretically it is possible to reassign these activities to Function keys

such as F3, F8, etc. to make life easier for you or your users.  Unfor-

tunately, in all versions of dBASE III, dBASE III PLUS and in FoxBASE+ this

doesn't work, so you are stuck with using CONTROL/S and CONTROL/Q. 

Ironically, FoxBASE+ is so fast even long reports from REPORT FORM scroll

by on screen too quickly to pause them effectively!  (I never thought I

would be complaining about speed.)

Another request I receive frequently once clients have seen a report

displayed on screen is the ability to pause the report and then page or

scroll backwards.  Alas, dBASE and FoxBASE+ can not handle this directly. 

However, there are several nice public domain and shareware utilities

around that can do the trick.

If you do download files from an RBBS and use them please keep the share-

ware ethic going by sending in your money.  The authors usually ask from $5

to $20 and it's little enough to pay for some great stuff.  If we don't

encourage people writing these shareware utilities - for dBASE and other-

wise - we will all be the losers in the end since the well will go dry.

On many RBBS you will find the shareware PAGES.ARC file by Andrew Schulman,

or you can order it from him directly ($15) by writing to:

        Andrew Schulman

        12 Humboldt Street

        Cambridge, MA  02140

This system, in effect, replaces REPORT FORM by letting you display any

ASCII text file or a file created from your database by using the commands:

        USE <database> INDEX <whatever>

        COPY TO xxxxx.SDF FOR xxxxx

The information can then be displayed on any part of the screen - or on the

entire screen - and you can page back and forth, jump from the beginning to

the end, to any page number, or search for a specific word or string of

words in the text.  It's all written in the dBASE language - and works well

in FoxBASE+ also.  Although the defaults are black and white it can easily

be changed to the colors of your choice by inserting the appropriate line

of code at the beginning of the program.

Another very nice such utility is SCROLL by Russell Freeland.  Russell

takes a different approach to the same situation by creating CALLable and

LOADable .BIN files that do window scrolling or full page scrolling.  Data

fields can be used or text files.  And, of course, you can page back as

well as forward.  The scroll window can be set up at any point of your

choosing on screen.  The SCROLL system can be found on many RBBS as

SCROLL.ARC and is also available for $7.50 directly from the author:

        R. Russell Freeland

        Synergy Corp.

        1780 SW 43 Avenue

        Ft. Lauderdale, FL 33317

Russell can also be reached on CompuServe at 76146,371.

Of course, the ideal situation would be to print a REPORT FORM to disk as

an ASCII text file.  Then it could be used easily in the above utilities,

used as a .TXT file in dBASE and FoxBASE, or saved for printing hard copy

at a later date.  Some of my clients, for instance, want to print out

reports overnight and stacking the ASCII text files in a print spooler is a

good way to handle this.  Alas, dBASE III can not handle this directly. 

FoxBASE, on the other hand, does have this capability.

Again, shareware utilities and Russell Freeland come to the rescue.  A file

usually called PRFILE.ARC can be found on many RBBS.  This consists of a

CALLable and LOADable .BIN file and a documentation file that will let you

print a REPORT FORM, LIST, etc. to an ASCII text file.  Or the system can

be obtained for $10.00 from the author, Russell Freeland, at the above

address.

PRINTING REPORTS WITH REPORT FORM

=================================

Printing plain vanilla reports in hard copy with dBASE or FoxBASE is a

fairly straightforward matter once you have created the .FRM file.  The

command REPORT FORM xxxxx TO PRINT does the trick.  And there are various

options available with this command.

When command REPORT FORM xxxxx TO PRINT is used in both dBASE III and dBASE

III PLUS the printer will first do a page eject before beginning printing.

This can be suppressed by including the NOEJECT option in your command

line:

        USE <database> INDEX <whatever>

        REPORT FORM xxxxxx NOEJECT TO PRINT

The NOEJECT statement does create a potential problem, however.  dBASE has

a built in line counter for use with REPORT FORM that is an entirely

separate matter from the line counter in your printer.  Normally when you

issue the REPORT FORM xxxxx TO PRINT command dBASE will automatically reset

its line counter to zero when it finishes printing the report.  But using

the NOEJECT option disables this reset feature.

If you use the command REPORT FORM xxxxxx NOEJECT TO PRINT the dBASE line

counter does NOT reset itself to zero when it finishes printing the report. 

Therefore, the first page of the next printed report, LIST TO PRINT, etc.

may produce page breaks (form feeds) in the wrong place and print data

across the perforation lines of the tractor feed continuous paper.

The work-around for this problem is to issue an EJECT statement after the

report has finished printing:

        USE <database> INDEX <whatever>

        REPORT FORM xxxxxx NOEJECT TO PRINT

        EJECT

dBASE III PLUS also provides another option that will solve the problem. 

When creating your REPORT FORM in dBASE III PLUS you can change the "Page

eject after printing" option that appears on the first screen to Yes.  This

has the same effect as issuing an EJECT after the REPORT FORM xxxxx NOEJECT

TO PRINT command line.  This feature is also available in the FoxBASE+

CREATE REPORT utility, but not in dBASE III.

The question of page breaks in printed reports is further complicated by

the line counter in your printer - which may not always agree with the line

counter in dBASE or FoxBASE.

The line counter in the printer can also be skewed when users use the

platen knobs to manually adjust or move paper in the printer.  For example,

if the printer line counter is at line one and someone manually advances

the paper instead of using the line feed button or the form feed button on

the printer, the paper is no longer at line one but the printer THINKS the

paper is still in that position.

If a report ends up printing across the perforations and/or producing a

page break in the middle of a page users are normally convinced there is

something wrong with the customized program written for them or with dBASE

or FoxBASE itself.  The fact that this happens intermittently only exacer-

bates their frustration.

To ensure proper positioning of paper in the printer and proper co-ordina-

tion of line counters and page ejects in dBASE and the printer when writing

custom systems I often use the approach of issuing an EJECT statement prior

to printing a report.   A screen then requests the user to check to make

sure the paper is positioned properly in the printer.  If not, the user can

make manual adjustments to the paper that do not effect the dBASE line

counter nor the printer's line counter.  All reports are then printed with

the NOEJECT option and an EJECT statement is issued at the end of the

report.  This also has the effect of ensuring all data is flushed from the

printer and printed in the report.  While this may not sound like par-

ticularly elegant programming, it is extremely effective.

Next time we'll take a look at some ways to create printed reports that use

your printer's abilities to change font styles, use bold or emphasized

print, underlining, and other features.

All of this is further complicated by the fact that your printer has its

own line counter which is completely independent of the dBASE line counter

and may not always agree with the dBASE line counter.