
This file contains information about:
REPTW : Report Form (FRX) File Format             

******** THD203.DBF ********
Msg#:  184317   Date:  29-Nov-91
Fm: Roger Bischoff [Fox] 76004,1651
To: Chet Musialowski 73700,2467


-Chet:

I confirmed in the new documentation that there is only one item that
has changed.

A new field, PDSETUP (21) was added to the .FRX file format listing.
The PDSETUP string for that goes in the NAME record.
If you would still like this information, please let me know.

Roger [Fox]


******** THD206.DBF ********
Msg#:  225836   Date:  29-Feb-92
Fm: CRAIG CHURCH 72030,1627
To: C. Blaise Mitsutama 72260,420 (X)

> How...gone?

I reset my HMC to verify receipt(if the info is critical). Here is
what we (CAC/Lisa) have determined on FRX objects so far:

        TYPE CODE BAND OBJECT
        ==== ==== =============
        9       0       Title
        9       1       Page Header
        9       2
        9       3       Group Header
        9       4       Detail
        9       5       Group Footer
        9       6
        9       7       Page Footer
        9       8       Summary

God only knows what CIM will do with this table<g>.

So to place any other object in its band postion, give it a VPOS that
accounts for all preceding band heights plus its position in it own
band, just as though you are placing it on the RW interface itself.

Starting with this simple concept, completely dynamic worksheets
are not far away.

Hi Ho..Hi Hi.....<CAC>
******** THD07.DBF ********
Msg#:  230500   Date:  10-Mar-92
Fm: Dave Watkins [Fox] 76004,2575
To: CRAIG CHURCH 72030,1627 (X)             >> Are Object Type/Code
pairs 9/2 and 9/6 in the FRX being used for anything<<
No.

>> Overlooked any reason why this won't work? <<

Nothing that I am aware of, however, I don't know how you would be
able to tell, until you had the majority of it developed.

>> While pondering various interpretations of the First Amendment, my
request may be resting comfortably in byte heaven <<

Have you requested this before? If so, then due to the recent problems
with CIS, I don't think we ever received it. We respond to all
technical questions directed to us, unless someone else has provided
the correct answer, in which case, we acknowledge that you received a
correct response in a Private message so that others don't have to
waste their time and money downloading these types of messages. If
your original request was lost, it was due to the problem with CIS,
not with Fox.

Dave

Msg#:  227962   Date:  05-Mar-92
Fm: Philip De Schutter 100034,1124
To: sysop (X)

Using the report builder, I see that the page-length of a report is
directly linked to the report itself, which means, I suppose, that a
report will always have a fixed number of lines.

Let's assume that a 60-lines report is printed on 2 different printers
with different paper lengths, 60 and 70 lines.

I can control, from within my program, that a different PDSETUP is
used, but that doesn't change the number of lines printed on a page,
does it. When the 70-lines printer is used, there will be 10 blank
lines at the bottom of the sheet, isn't it ?

My question: Is there a way to solve this, I.O.W. to change the
page-length of a report (not of the printer setup) at RUN-TIME
?Philip. Antwerp.


Msg#: 228648   Date:   06-Mar-92
Fm: Lisa Slater 72077,2417
To: Philip De Schutter 100034,1124

Yes, there's a way to fix this.

You'll need an editable copy of the FRX.  IOW, if you bind your report
form into the APP you'll need to do the actual REPORT FORM statement
from a copy on disk so that you can alter it whenever needed.

I do it like this:

    mselect = SELECT()
    IF ! FILE("copy.frx")  && is this the first time I'm doing it?
        USE bound.frx
        COPY TO copy.frx
    ENDIF
    USE copy.frx
    REPLACE height WITH no_lines_for_this_printer
      * IOW first record is the header, where this info is stored,
      * in the height field
    USE
    SELECT (mselect)
    REPORT FORM copy

>L<
