TAN()

_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


View Updates

Copyright © 2002 by Tamar E. Granor, Ted Roche, Doug Hennig, and Della Martin. All Rights Reserved.



Hacker's Guide to Visual FoxPro 7. 0
Hackers Guide to Visual FoxPro 7.0
ISBN: 1930919220
EAN: 2147483647
Year: 2001
Pages: 899

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net