_ASCIICols, _ASCIIRows

These system variables control the layout when you use the ASCII clause of REPORT FORM. _ASCIICOLS has logical, intelligent behavior, while _ASCIIROWS, by behaving the same way, is incredibly silly.

Usage

_ASCIICOLS = nColumns
nCurrentColumns = _ASCIICOLS
_ASCIIROWS = nRows
nCurrentRows = _ASCIIROWS

The defaults for _ASCIICOLS and _ASCIIROWS are 80 and 63, respectively, the appropriate size for a U.S. standard portrait page. As you change _ASCIICOLS, the width of the columns in the report and the amount of space between them changes. Be forewarned that some data may be cut off as the number of columns decreases.

Foolishly, in VFP 6 and earlier, _ASCIIROWS acts pretty much like _ASCIICOLS. As _ASCIIROWS increases, more space is left between rows. As _ASCIIROWS decreases, the rows are put closer together. We think this is incredibly stupid. If you increase _ASCIIROWS, it's because you want more data on the page, not more space between the data.

In VFP 7, _ASCIIROWS is even stranger than before. You no longer get white space between rows, regardless of the setting. However, the number of rows on the page is fairly random. Things seem to work correctly until _ASCIIROWS is larger than 50. After that, it gets weird. We suspect that all they did was take out the extra rows of white space, but not let you have more rows per page.

There was one additional bug in the original release of VFP 7 that put the page footer immediately after the detail band. That's fixed in SP1.

Doug comments that he doesn’t like the way _ASCIICOLS behaves, either. Having extra spaces between columns is a pain when you want to process the text file afterward. He finds that he needs to set _ASCIICOLS to the exact number of columns in the report to get what he needs.

Prior to VFP 7, Microsoft didn’t see it our way and maintained that the original behavior was correct. Their view was that _ASCIIROWS controls the amount of space taken up by a single row of the detail band. If you make _ASCIIROWS bigger, therefore, it means you want that row to take up more space. Because a row in an ASCII file takes a fixed amount of space, they resolve this by adding blank lines between rows and between repetitions of the detail band.

We can’t imagine why anyone would want this behavior, and are glad Microsoft seems to have come to its senses. However, since the new bug renders _ASCIIROWS totally useless, we’re not sure what they’re thinking now.

Example

_ASCIICOLS=105  && Landscape width
_ASCIIROWS=48   && Landscape height
REPORT FORM MyReport TO FILE Landscap.txt ASCII

See Also

Report