home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Shareware Overload
/
ShartewareOverload.cdr
/
database
/
rptform.zip
/
REPORT3
< prev
next >
Wrap
Text File
|
1987-04-06
|
11KB
|
240 lines
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.