In order for this site to work correctly, and for us to improve the site, we need to store a small file (called a cookie) on your computer.
By continuing to use this website, you agree to our cookies and privacy policy.
Home page Home page Home page Home page
Pixel Header R1 C1 Pixel
Pixel Header R2 C1 Pixel
Pixel Header R3 C1 Pixel

R3 Report Writer Reviewed by Richard Guise, CSS Ltd

R3 (pronounced "R-Cubed") is a "multiple-file banded report writer" newly released by Lester Associates Inc. (11 South Passaic Avenue, Chatham, New Jersey, 07928, USA. 201-635-2254 (Vox), 201-635-7449 (Fax)) in developer and runtime versions, compatible with all versions of AREV. The prices are $249 and $125 respectively and the latter permits the user to run R3 reports developed by others. Volume pricing is available, contact Lester Associates direct for details.

What is a "banded report"?

Before launching into the mechanics of setting up and editing reports, the manual's sole description of the end objective is the single sentence "`Banded' refers to the fact that the sequenced data is grouped in 'bands' and each band can have a unique set of headings and footings". The manual is in every other respect exemplary but in the next edition it would help to describe at the outset rather more clearly what the target looks like before trying to take aim!

However it doesn't take much study to realise that R3 is based on much the same underlying concept as R/List which will be familiar to most, if not all, readers of the manual. Like R/List, the R3 report is based on progressing through a main data file using records selected according to specified criteria and using single or multi-level sorting. Fields from the records, or derived from them, are then displayed across the page in columns taking one or more lines per record. This sequence can be interrupted at one or more levels by band definitions in much the same way as BREAK-ON in R/List.

What's the difference?

Having created the band breaks, R3 then offers a completely different level of control from R/List as to what the user can do. This includes headers and footers within bands, boxes around their contents, fonts, shading, etc. It also offers automatic portrait/landscape and normal/condensed setting (a significant omission in R/List definition). In addition to defined dictionary fields, there are facilities for data derivation to be defined in the report specification itself. At present proportional spaced fonts cannot be used (although the R3 publicity fly-sheet seems to use them) - nor it seems can normal/condensed or different line spacings be switched within a report.

As a rough indicator, there are about 20 controls available for the output of each report column (plus nearly as many additional prompts in relation to XLATEd and calculated columns). The definition of each band also offers about 20 control prompts and the overall report controls have about a further 20. These are not always all needed but are potentially useful in controlling how data is processed and laid out in different circumstances.

From this brief overview it will be appreciated that the task addressed by R3 is considerably more complex and the result is very much more configurable than R/List. Inevitably it takes more learning, time and experimentation to set up reports using R3 than with R/List, especially for new and occasional users. In many situations this extra effort will be well justified in order to present data to a higher standard and in ways not possible with R/List. R3 should therefore be viewed as a very valuable supplement for those who need the additional utility it offers.

User Interface

The command syntax and options for R/List are sufficiently straightforward and limited to enable specification by a simple command sentence, which can be entered at TCL, edited in a single record field and popup- driven in EasyWriter style. If a library of additional products is to develop around AREV, it is very desirable that the lead of EasyGraph in following this style should become as general as possible.

However the nature and complexity of the task addressed by R3 clearly makes these types of interface impractical in this case. The interface is rather different but is about as simple as could be devised to achieve the desired ends. As the brief description below indicates it is really not at all difficult when one "gets the hang".

The report designer screen comprises three windows displayed together. The main "layout window" takes about three-quarters of the screen and is purely a display indicating conceptually how the report will look. The central window underneath indicates the main control options and the "field window" and "band window" at each side of this are used to specify and display the fields and bands for the report. Control can be directed to either of these by SF2 and SF3 respectively. Once in one of these windows the contents can be specified or changed. By moving the highlight and pressing SF6, the controls for the highlighted field or band can be inspected and modified on overlaid edit windows (rather like the prompt details window in "Paint"). General report controls are accessed at any stage by pressing F10 for a menu of control screens (plus test run, etc.).

Existing R/List reports can be imported into R3 and this could enable reports quickly developed initially in R/List to be subsequently "tarted up" when the need arises.

Other Facilities

Unlike R/List, R3 offers pre-, post- and replace command hooks and access to a comprehensive array of common variables (including, unlike R/List, the current line number).

The more sophisticated printing suggests possible problems with less common printer command sets and with selecting the correct character set for the line draw characters. Apart from the comment that "Shading is also available on laser printers supporting PCL Level IV or higher", neither the manual nor Lester Associates' publicity comment on which printers are known to be suitable and/or unsuitable for use with R3 or the various facilities available therein. Another area which I suspect will merit attention in the first manual revision.

R3 also includes programs for printing out summary and detailed documentation on filed report specifications. This is a welcome contrast to the apparently increasing lack of interest in providing documentation facilities in AREV itself.


Very few! In a newly released product there are bound to be a few raw edges which will be tidied up quickly as users feed back comments and suggestions. Several of the screens would benefit from addition and tidying up of prompt tabs. There is only a single initial installation procedure but no separate procedure to install VOC entries etc. in additional accounts. The manual will, no doubt, be undergoing minor revision when reprinted.

The only relatively serious criticisms are shared by R3 and R/List and it would be good to see either or both systems overcome them. Firstly there are no controls (apart from forced page breaks every time) to prevent or allow bands, multiple lines etc. from splitting at page ends; thus addresses, subtotals, even total/underlines can become split at page ends (at least R3 doesn't seem to keep the line number secret although a note as to how to force a page throw would be helpful). Secondly, any totalled field automatically generates both subtotals and grand total (one of which may be irrelevant or misleading in certain cases) without any option to suppress either. Thirdly, thanks to AREV's SCRIBE window editor, user para breaks and system editor line ends are not distinguished; text fields containing paragraphs cannot therefore be reliably reformatted on output to different fields.


R3 offers a lot of possibilities beyond the scope and purpose of R/List and is a supplement rather than a replacement. It is more complex but has been made remarkably easy to use in relation to what can be done with it. The documentation is very well written and presented. If you want what it offers there should be no problem in quickly learning to use it effectively.

R3 has a very few minor raw edges inevitable in a new product but these are not critical and should be ironed out quickly. There should be possibilities for further development in due course within the initial concept and framework; these might include proportional font support, better page break controls, etc. However, it is already a facility which should prove useful to a significant number of AREV Developers.

Richard Guise is Principal of Consulting Support Services Ltd, Staplehurst, Kingsmill Lane, Redhill, Surrey RH1 5JX, UK . Telephone 0737 76299

(Volume 4, Issue 9, Pages 14,15)
Pixel Footer R1 C1 Pixel