
This file contains information about:
REPTW : Page Design & Control (Headers/Footers)   

******** THREADS2.DBF, 2.0 BETA MESSAGES ********

Msg#:  2276   Date:  11-Feb-91
Fm: Cathy Corey [Sysop] 76177,3002
To: Ellen Sander 71001,3724 (X)

Ellen,

The value that number of rows following group header is set to
determines how many blank detail lines must be left on a page for the
report to print the group header on that same page.  Therefore, if you
specify 0 for the number of rows following group header, the group
header could be printed and orphaned on a page.  If on the other hand
you specify 5, there must be at least 5 available lines for detail
printing at the end of the page for the group header to printed on
that page.  If 5 lines are not available for detail printing, the
group header will be printed on the next page.

Cathy

Msg#:  19526   Date:  22-May-91
Fm: Tim McArdle (X!) 71441,2223
To: Glenn Hart 76703,4226 (X)

The formfeed suppression answer was found in setting _PADVANCE to
"LINEFEED" and _PLENGTH to 32727. This allows writing of pure ASCII
files easily through the report writer without any formfeed
characters.  It'd be nice to just set page length to unlimited for
these kinds of tasks but there are plenty of other ways to do it.
Doing these in the report writer is quicker and dirtier than most
other methods.  I don't often need to write out files bigger than
30,000 lines...
                       Do re mi - yeah we're in the groove now <g>-

                                                       TMx

Msg#:  16555   Date:  12-May-91
Fm: Richard Hurd 70421,2566
To: Lisa Slater 72077,2417

Remember how in March (how long ago that seems) I was whining about
not having an unlimited page length in the report generator, and you
told me what to do to get it, and we started BSing about LLFFns, etc.,
etc.?

I've got a way to get my data out the way I want; e.g., with no page
breaks and one line of data per occurrence in the database.

Use the label maker.   <s>   Works great.  It only took 2 months to
think of.



******** THD201.DBF ********
Msg#:  107010   Date:  05-Jun-91
Fm: Bob Rogers 76166,3362
To: Lisa Slater 72077,2417

Oh I am so sorry!  I haven't been Tapping lately and I forgot to
unformat the second half.  The first half was OK wasn't it?
Lets try that again....

*** Procedure linememo
*** RJR MicroComputer Solutions
*** Force a new page if the memo won't fit on the remainder of the
page *** *** Assumes:
**     no bottom margin (need to change the "theselines" portion) **
each memo doesn't extend over a page
**  Detail line in the FRX file:
**  [detail of the record.....]  [memofield with width set to 80] **
linecnt()    <---- format for this field is @;

set memowidth to 80   && properly should be in the PRG not here

skip
theselines = memlines(memofieldname)

if theselines > _plength-_plineno
   outstuff = replicate(";",_plength-_plineno)
else
   outstuff = ""
endif
skip -1
return outstuff
** EOP Linememo()


Msg#:  109366   Date:  14-Jun-91
Fm: Toni Taylor [Fox] 76702,1237
To: John Stuppy 70461,2757 (X)

John,

The HEADING in the Report Form line always go on the first free
heading line. If you do not have a Page Header in the report, this
Heading will go on the first line.  If you do have a Page Header, the
Heading will go on the first available heading line.  This may be line
2 or 3.  You could call a UDF from one of the Page Header lines.  This
UDF would simply return the string that you would like printed.  The
string could be initialized outside of the report and as long as the
variable is public, the UDF will be able to use it.  Doing it this way
allows you to decide where you would like the heading to be.
Toni-


Msg#:  141645   Date:  30-Aug-91
Fm: Lisa Slater 72077,2417
To: Ajjampur Manjnath 72117,1064 (X)

Well, we got orphan control to a certain degree, using group breaks --
it's called "number of lines after the header" or something like that
-- but this doesn't help you easily <g>!

I'm kind of in a rush and haven't tried this out for you exactly, but
the following *works* and is a neat idea:

Create a special grouping.   Group on RECNO() -- yes!!

If you have other groupings, this one should be innermost.  It should
not have anything in its header or footer.  Just put the number of
lines required by your column six field  in the "number of lines after
the header" column.
There are alternative ways to do this that take a little more work if
your column six is of a variable length.  (You didn't say.)

Try something like this --  SET MEMOWIDTH TO the width of column6.
Then, instead of column6 as an expression, make it:

  column6 + notroom()

  FUNCTION notroom
  PRIVATE thisrec, mreturn
  thisrec = MEMLINES(column6) + _PLINENO
  * above tells us where next record is scheduled to start
  * now make sure it isn't going to end on its own anyway:
  mreturn = ""
  IF ! thisrec > page_length - footer_lines
     * check the length of the next record
     SKIP
     IF  thisrec + MEMLINES(column6) > page_length - footer_lines
        mreturn = REPLICATE(";",page_length-footer_lines -_PLINENO)
     ENDIF
     SKIP -1
  ENDIF
  RETURN mreturn

Give this expression the format of @;  -- what we're doing is forcing
a number of line breaks based on the contents of the next record.

Note that MEMLINES() works on a character field as well as a memo
field.
Also note that this will work will with a Rushmore-ized filter but
needs some extra work to check for WHILE or FOR conditions on the
REPORT FORM, when you're doing the skip.

For groupings, you'd also want to return "" from the function if the
next record is not in the same group, and you'd take care of this
situation separately (using the "lines following header" approach).

What do you think?  I may not have it exactly right, but it works...
>L<


Msg#:  139348   Date:  26-Aug-91
Fm: Lisa Slater 72077,2417
To: Larry Schneider 73767,2272

Hi, Larry...

I've created a couple of different procedures in which details are
broken in groups of 5 as you like.

The simplest way might be to group on an expression which is simply
the name of a report variable. The report variable would be
initialized to 0, and store this:

IIF(_PLINENO % 6 = 0,rept_var+1, rept_var)

* can also be written:

IIF(MOD(_PLINENO,6) = 0,rept_var+1, rept_var)

IOW, it will only change every 5th line.  The reason the MOD says 6
instead of 5 is that the extra line is the blank one -- you get it by
putting a dummy report expression in a group header line, something
like "   " will do.
To force a page break between group detail and group summary
section... hmm.
This is a PITA.  Could be complicated.  Two ways to do it that I can
see. Easier one would be to actually print each group as a separate
report, in a loop like this:

  SCAN
    thisgroup = group_expr
    REPORT FORM WHILE group_expr = this_group
  ENDSCAN

Now you can put your group footer in a summary band and choose to have
the summary band on a new page.

>L<

Msg#:  140504   Date:  28-Aug-91
Fm: Lisa Slater 72077,2417
To: Larry Schneider 73767,2272 (X)

Sure, you could modify the line break idea for your number of
pageheading lines!  But you shouldn't.  There are other
considerations, like how many groups you had on this page and how many
group header/footer lines there are. So, actually, I just gave you the
simplest way to do it, but *in my head* I wasn't really using _PLINENO
at all! I was using another report variable that you initialized to 0
and store one + itself to it, reset on page or on group; (Another way
to do this is to store anything you want to it, but choose its
Calculate option and Count.) Then just substitute the second report
var's name for _PLINENO, like this:

    IIF(second_var % 6 = 0, rept_var+1, rept_var)

.. something like that, anyway, would work regardless of how you
mucked around with the report definition, see?

I don't work for Fox.

PITA = Pain In The Anatomy.

<g>

>L<

Msg#:  38388   Date:  27-Aug-91
Fm: Jackie Jaynes [Sysop] 76177,2777
To: Tim McArdle 71441,2223 (X)

Tim,

The problem is that you have a 20 line detail and page footers, and
your page length is set at 66.  So, when you are at line 43, the
report writer tries to see if it can fit another 20 line detail on
this page.  It can't so it goes ahead and prints your page footer, and
ejects a page and prints the 20 line detail on the next page.  So,
when you set your page length to 80, it works because it can fit
another 20 line detail on the same page.

Jackie



******** THD202.DBF ********
Msg#:  162450   Date:  16-Oct-91
Fm: Lisa Slater 72077,2417
To: DI COOK 100033,1414 (X)

Easiest way I can think of:  Don't bother to group on customer number,
just do invoices for single customers, like this:

    SET ORDER TO custno

    * if your customer file is SELECTed:
    SCAN
      REPORT FORM NEXT 1   && will not move record pointer
      REPORT FORM NEXT 1   && will repeat invoice
    ENDSCAN                && will move you to next record

    * if some other detail file is SELECTed:
    SCAN
      mcustno  = custno
      REPORT FORM WHILE custno == mcustno
      SEEK mcustno
      REPORT FORM WHILE custno == mcustno  && will move you 1 record
too far       SKIP -1                              && so you move back
1
    ENDSCAN

..I'm doing this off the top of my head (may take a little tweaking to
get exactly what you want) and there are *lots* of other ways to do
this, though <g>.

For your total to be on the last line of the form, put it in the page
footer, not the group footer.  You see that this will work nicely with
the NEXT 1.  If you like, stick a group on customer number anyway, but
don't print anything in it, just change some variable in the group
footer using a UDF -- this will indicate "end of group".  Your page
footer will check this variable before printing the total, in case an
invoice is more than one page in length, okay? Sorry this is a bit
sketchy, hope it helps, 'night.

>L<


Msg#:  162835   Date:  16-Oct-91
Fm: DI COOK 100033,1414
To: Lisa Slater, 72077,2417

Lisa, Thanks for helping with Paul & Fred's problem.  I suggested to
them that they had to use the page footer to print at the bottom of
page but they reckon it doesn't work - but of course they were using a
different technique to print the invoices in the first place.

BTW, getting back to the problem I had with page breaks, I have
finally got it just as I want it.  I hate too much white space at the
bottom of pages so I wrote a UDF to count up the number of records for
each group and inserted a variable to keep track of the record
pointer.  In conjunction with using _plineno I also inserted another
condition that checked to see how many records had to be printed
before the next control break (group) and if this was less than 12
(therefore needing to insert the total, yours faithfully, etc), then
variable incremented, otherwise stayed the same, i.e.

hererec - variable showing where record pointer is norec - variable
showing total number of records for group npage - variable to force
new page which is also data grouping 2 Equation for npage is
iif (_plineno=58 .and. norec-hererec<12,npage+1,npage)

Works just as I want, if there are more than 12 records left letter
prints down to bottom of page, if less than 12 records but not enough
room to fit onto page, a page break is forced and rest of letter
printed on next page. Thanks for everything, will let you know how
Paul and Fred fare with their problem.


Msg#:  145322   Date:  07-Sep-91
Fm: Lisa Slater 72077,2417
To: Jerry Burg 71331,1735 (X)

Hi Jerry,

The way to make a blank page footer "stay" is to put a blank report
expression in there!  Go into the page footer line you'd like to keep
and Ctrl-F for a report expression.  Put the expression SPACE(1) in
there, or just quotation marks with a couple of spaces, "   ".  That
will "fix" the line for you.
If you want to insert a blank line, try dragging with the shift key
held down. As a matter of fact, access the report menu with the shift
key held down and you should see the difference in the ^N option, too.
You can use Shift-Ctrl-N.

>L<

Msg#:  153179   Date:  24-Sep-91
Fm: Rick Strahl 76427,2363
To: Lisa Slater 72077,2417

How so? Well, my routine works the way it's supposed to. It works
something like this: If a certain line is reached go to the (variable)
group footer, which prints just a totaling line on every page, whether
it's less than the right amount of lineitems or more that are to be
continued on the next. But on that line I also have the aforementioned
UDF() which FIRST advances the printer to the proper line using plain
?'s, *IF* there are less items than alloted to this page. Thus the
Totaling Line will ALWAYS print in the same position on the page and
the Summary will also always be in the same position on the last
page...

It works, even though I had my doubts about using plain ?'s inside the
UDF(), but checking _plineno I could see that they were advancing FP's
linecounters properly.

I'm curious what you were refering to as "some ways don't work so
well"...
                         +++ Rick -


******** THD203.DBF ********
Msg#:  184240   Date:  29-Nov-91
Fm: Gerhard Paulus 100012,2300
To: Lisa Slater 72077,2417

Lisa,
I find Report Variables a sure way to confuse oneself <g>. IMHO they
would be more useful in a 2-pass way, built into the RW:

1.  scan a group and evaluate repvars
2.  loop back and print, but do not change repvars

This way we would know the group sums etc. beforehead, without the
necessity to use UDF's.

FWIW, I found a solution to print stretching group footer objects,
where variables are not obligatory. It works with a generic  skip
forward-skip backward UDF, to which the overall group expression is
passed.

Gerhard

Detail (with semicolon template):
--------------------------------
IIF(for_back("group expression"),chr(255)+";"+alias.memofield, " ")

UDF: for_back.prg
------------------
PARAMETERS m.gr_expr
m.gr_value= EVAL(m.gr_expr)
SKIP

DO CASE
CASE EVAL(m.gr_expr)= m.gr_value
m.result= .F.
OTHERWISE
m.result= .T.
ENDCASE

SKIP -1
RETURN m.result


Msg#:  180415   Date:  20-Nov-91
Fm: Lisa Slater 72077,2417
To: Robert Turenne 73457,3343 (X)

There are a couple of ways to do this...

The first: does your report require a header or footer ?  If not or if
you can print them separately at the beginning and end, you can do
your report as a very wide *label* instead of an FRX <g>.  Do any
necessary calculations in a UDF.

The second:  will work whether you use a pdriver or not:  Report as
usual to the file, with *no* page header or footer lines -- make any
necessary header or footer title/summary bands instead. Then use the
low level file functions to remove the offending characters from the
file. You can check to see if a pdriver is loaded, and if so remove
the chars found in _PDPARMS(6), I believe... and if not, remove the
usual CHR(12)-type stuff. This is most often the easiest and the best
way.

The third:  is *incredibly* weird <g>.  I haven't actually tried it in
2.0 yet although I used to do it in 1.02.  Let me know if neither of
the above will work for you and I'll check it out in 2.0...

>L<


******** THD204.DBF ********
Msg#:  184601   Date:  30-Nov-91
Fm: Bill Nemmer 71560,1631
To: sysop (X)

I have 8 lines of summary in a report. If some of the lines carry over
to the next page, the page header is not repeated.  How can I avoid
this without forcing the entire summary onto a new page?  If
necessary, I will settle for having the entire summary go onto a new
page if all 8 lines cannot fit on the current page (this seems to be
the way that the group footers work so I've changed it to a footer for
a dummy group.)

Msg#:  185911   Date:  03-Dec-91
Fm: Lisa Slater 72077,2417
To: Bill Nemmer 71560,1631 (X)

Bill, there's actually a way to do this, I suppose <g>... hmmm.

At the beginning of *each* line of the summary band, put a UDF().
You'll need to set up a variable for this purpose -- make it a report
variable that doesn't get used for anything else; initialize it to 0
and store its own name to it -- this way you'll avoid making it PUBLIC
and it will just sit around waiting for you to use it in the summary
band.

In the UDF, check _PLINENO.  If it is lower than the current value of
the reptvar, use ?'s to print all the page header lines and a couple
of extra blank lines for good measure (this should only happen once
per report, obviously). Then store _PLINENO to the reptvar and RETURN
"" from the UDF. Then your real summary line goes ahead and prints.

>L<


Msg#:  188146   Date:  07-Dec-91
Fm: Lisa Slater 72077,2417
To: William J. Hartman 70353,1063

I understand what you are saying, but IMHO it's important to
understand the way pagelength works in an FRX. Yes, it is easy to
misunderstand, because this is different from the way other products
handle the issue, you are certainly correct there.

But in an FRX the page length refers to the number of printable lines,
not the number of lines on the piece of paper from which you subtract
top/bot margins to get a number of printable lines. In an FRX you get
the number of lines on the piece of paper by adding the top and bottom
margins to the form length, which *Fox* refers to as page length.

Since, frankly, I have never liked this fact <g> I always use a top
and bottom margin of 0 and put the blank lines in the header/footer
myself. That way there is no question about what the page length is
referring to; the form length and the page length are one and the
same...

>L<


******** THD205.DBF ********
Msg#:  201555   Date:  09-Jan-92
Fm: David Gibson 100015,2106
To: Lisa Slater 72077,2417 (X)

Lisa,

I hope you don't mind me addressing this to you directly - but I know
that you are a RW expert.

Is there a way to ensure that the summary band of a report will not
get split across two pages ?

What I am looking for is something like the <# of rows following
header> group band thingy, but for use with the summary band.

I know that I can check <[ ] New Page> for the summary and force it
onto a new page but this is a pain if the rest of the report finished
only a few lines down the previous page.

My summary bands tend to be around 6 to 12 lines long depending on the
report and I just hate it when they get split across two pages. <g>

I tried messing around with a UDF to do a conditional EJECT but
couldn't get it to work.

Thank you for any suggestions you may have.

David

Msg#:  201623   Date:  09-Jan-92
Fm: Lisa Slater 72077,2417
To: David Gibson 100015,2106 (X)

Well, this is a PITA but can be done <g>.

Here's the idea:

Create a report variable that is initialized to a return value of a
UDF. In the UDF, do something like this to find out where the last
record is:
  FUNC UDF1
  go bottom  ** or whatever, depending on your reporting conditions
thisrec = recno()
  go top
  return thisrec

.. store this report variable's own value to it, so it is not changed
during the report.

Now put an expression *at the right end of your last detail line* that
looks something like this:

   IIF(recno() = reportvar, UDF2(), "")

.. make this expression stretch and float using the format @;
(at-sign, semi-colon).  Here's what UDF2 has to do:

   FUNC UDF2
   IF _PLINENO  < some_value && you can pass or hardcode this value
      RETURN ""
   ELSE
      * figure out how many extra lines you need to force to a new
page       RETURN REPL(";", that_number)+"   "
   ENDIF

.. now your summary band will be forced to the next page... the only
problem with this is that your group footer is going to be moved,
also! So if you have a group footer you can do something very similar
by putting an expression at the end of the group footer instead. It
does this:

   IIF(recno() = reportvar, UDF3(), "")

.. where UDF3 checks _PLINENO and decides to ??? a bunch of CR-LFs as
necessary, proceding to print the summary band entirely on its own.
Since, when you do this, you may screw up your page footers <g>, you
may still have some things to work out... but it usually can be
done.>L<

Msg#:  202200   Date:  11-Jan-92
Fm: David Gibson 100015,2106
To: Lisa Slater 72077,2417

Thank you for your help re not splitting the summary band over two
pages.
I have got this to work now, but came across a couple of things which
I thought might be worth mentioning for the benefit of anyone else
following this thread.

First my code - I used your function UDF1 exactly as suggested. But
because I *do* have a group footer I had to write UDF3 which goes as
follows:
FUNCTION UDF3
* m.printing is true if doing REPORT FORM to the printer,
* false if sending it to a file.
* If <_PLINENO > whatever> then there is not enough room
* on this page for the summary band.

IF m.printing AND _PLINENO > whatever
   FOR i = 1 TO (_PLENGTH - _PLINENO)
      ??? CHR(13)+CHR(10)
   ENDFOR
   * Alternatively you could just use
   * ??? CHR(12)
   * in place of the FOR/ENDFOR
   * This works for me but depends on setting of _PADVANCE (I assume)
ENDIF
RETURN ""

The points to watch were:

1) This does not work if a top or bottom margin is set in the RW page
layout dialog. With the default settings of 2 for each margin I found
that the summary band was moved onto a new page but then still got
split by 4 blank lines at the point it would have split if I had not
moved it. ( If you see what I mean <g> ) Setting both margins to zero
fixed this.

2) The expression IIF(RECNO() = reportvar, UDF3(), "") must be put on
a separate line of its own at the bottom of the group footer. Making
it the last item on a line with something else causes the something
else to be moved down to the next page as well.

Thanks again for the help

David

Msg#:  202330   Date:  11-Jan-92
Fm: Lisa Slater 72077,2417
To: David Gibson 100015,2106

Good points about the sending-to-file (I handle that a little
differently) and about the top/bottom margin.  Folks, I guess I should
explain that I *NEVER* use a top or bottom margin in the RW.  Too many
reasons to explain here.
About the IIF() expression, though... I thought it was clear from my
explanation that this detail line was to be a pseudo-summary line <g>.
It never occurred to me that you would put *real* detail items on that
line too... I'll be more specific about that in the future.  Thanks!

>L<


******** THD206.DBF ********
Msg#:  215233   Date:  08-Feb-92
Fm: Lisa Slater 72077,2417
To: Paul L. Inman 70720,2614 (X)

OK, I think my kludge is a *little* better <g>.

Are we talking about the real summary band or do you mean a group
footer?
Here's what I do:  I create a report var that holds the last recno()
for a given group (or for the report in total if you mean a real
summary band -it's all the same except where you reset the value of
the report var).  You do this by creating its initial value using a
UDF. This UDF is called once per group (once per report if you mean a
real summary band). In the UDF, after  it checks for the last recno in
the group, obviously it seeks the group again or GOes firstrec#,
before RETURNing the lastrec# to the report var.  You store this
report var's own name to it, so the RW never changes its value during
the detail lines.

Now I create a special detail line after all my other ones.  It has
this in it:

     IIF(lastrec = RECNO(), REPL(CHR(255),mylineno -_PLINENO),"" )

.. Choose Stretch Vertically for this expression, make it 1 char in
length, and choose to Suppress Blank Lines for this report.  You don't
need to worry about the @; Format in this case, folks, since the 1
char expression will be forced to do what you want if it Stretches
Vertically.

You may have to jimmy the variable I'm calling mylineno a little --
I'm not sure if it should be the line you *want* your summary line to
be, or the line *before* the line you want, or what, but it will work
something like this <g>.
But as you can see, this expression will create no havoc at all except
when it gets to the record you've specified ... and then it does the
job for you <s>.
>L<


******** THD07.DBF ********
Msg#:  248465   Date:  16-Apr-92
Fm: Lisa Slater 72077,2417
To: della martin [Woolpert] 76244,3533

Ah.  Thank you <g>. In the title band is like this.

You use a page header line, and you check  _PAGENO = 1, as follows --
exprP is an expression you want in line 1 of the page header, can be
whatever you want, even CHR(255) for nothing if nothing starts at that
position of the page header:

 IIF(_PAGENO = 1, memofield+";"+exprP, exprP)

Set this expression to format @; (at-sign semicolon).  Tell other
stuff in the page header to float as band stretches if it is in lines
other than line 1 of the page header.  If it is in line 1,  put it *in
the same line* as the expression above, like this:

 IIF(_PAGENO = 1, REPL(";",MEMLINES(memofield))+your_expr, your_expr)
Tell this one to format @; as well.  Make sure MEMOWIDTH is SET to the
width of your memo report expression.

Obviously, the rest of your title band can either be in the page
header band also or in the real title band, depending on whether it
precedes or follows the memofield.  If they must follow the memofield,
it can get a little more complex.

For your line 1 of the page header, remember that you can *overlay*
expressions and they will both get evaluated.  Make sure that the
title band expression start to the *left* of all the page header
expressions on that line, even if you have to jimmy expressions to
arrange that, or if they start at the same position make sure the
title band expression is Sent to Back so it is evaluated first.

>L<

Msg#:  233674   Date:  17-Mar-92
Fm: Steven Black 76200,2110
To: Ray Hooton 100023,2360

Ray, there is a way to make dynamic headers and footers.  Appologies
to all who say otherwise...

Checkout HEADFT.ZIP in the libraries.  This will give you a couple of
library routines (.PLB files) that place things center/left/right in
the headers and footers of windows.  It's shareware, uploaded by Scott
Mackay.

**--**  Steve
Msg#:  231007   Date:  11-Mar-92
Fm: Chaim Caron 72520,2272
To: Jordan Powell 74206,2521 (X)

Jordan,
  I recently investigated a report writer problem that caused improper
pagination of reports.  I came upon the same cause and resolution you
did in your message to David Gibson on 11/24/91 (from Threads).
  The problem is that the printer driver uses the logical page length
(lines per page specified in the report) as the argument for the
physical page length command which it sends to the printer as part of
the startup escape sequence. In other words, it sets the physical page
length to the logical page length.   Your solution was to set p_flen
to blanks in p_codes for the relevant printers so that no page length
command would be sent, and I decided to use that solution as well.
  One problem I see with this solution is that the printer's physical
page length will not be reset--whatever setting existed previously
will be carried over.  This will be fine in most cases, but if the
previous report printed had some odd page length, or if paper size
changed, then the solution will fail.   Do you have any more
information on this problem?  Did Fox ever comment on it?  I first
noticed this after patching to 11/15--do you know if this problem was
introduced with the 11/15 patch?  Does the solution work without
problems? Did you ever refine the solution?
  Thanks, Chaim

Msg#:  226857   Date:  03-Mar-92
Fm: William Tulloch 100031,2267
To: Lisa Slater 72077,2417 (X)              Hi >L< it's me again.

I have returned again to the reports area using your techniques for
pseudo group headers and trailers in the detail lines. All seems to
work, ie. the correct lines print when expected, HOWEVER :-) the
report seems to decide a new page is required FAR too early.

The details section has about 18 lines most of which are smart headers
and footers, and only one or two at most are real detail lines. The RW
decides a new page is required and leaves about 18 lines blank above
the page footer, and may then only have a couple of lines to put on
the next page.
What is the vital point I have missed ? or have you missed this
concept <g>
William

Msg#:  226902   Date:  03-Mar-92
Fm: Lisa Slater 72077,2417
To: William Tulloch 100031,2267 (X)

I don't think you've missed anything -- I think there is a limitation
to this concept in that if the RW thinks that the detail band is 18
lines long it may think it needs to go to the next page to print the
record's detail if it doesn't have another 18 lines.  I don't think I
ever intended the concept to be used that way.

Generally speaking, no matter how many lines of "smart headers and
footers" I would have put in the detail band, each one can take only
one line apiece. That's because detail items can stretch.  So I would
put the header information in *one* detail line with the separate
header bands' objects concatenated with semi colons and using the
appropriate format (@;) to force line breaks in them.  For
convenience' sake if I had only 2 header lines I might put the stuff
on two separate lines rather than using this technique, but not for 9
header lines.  Same for footer.

When you do this, of course, remember to mark all your detail objects
(including the "footer" ones) to float.

Also, remember that just because you have *some* header and footer
lines set up this way, that doesn't mean that you need *all* of them
set up this way. Often I can split up the header and footer lines
between the ones designated in the detail band and the ones split up
normally.  It mostly depends on the order of the header and footer
objects, and which ones need to stretch.
>L<

Msg#:  247708   Date:  14-Apr-92
Fm: Anders Altberg 100021,232
To: Lisa Slater 72077,2417 (X)

Lisa
my my are we getting fancy - page numbers?!
It is possible to work around _pageno; _plineno can be carried over to
the next report.
Page length is set to 66 in both reports, blank lines suppressed, no
page footer and print to a file. I get a formfeed and a new page
number every 66th line. This report does not page break on group.
Producing integrated many-to-many reports is tricky in FP - I'd
like a SET SKIP TO dbf ADDITIVE - but I still think this way or
loading repeating fields into a memo are comparatively easy. This
method could be expanded to do many-to-many-to-many by just sticking
in another report. -Anders

public line , dummy, page
line = 1
page=0
select courses
go top
scan
  co=course
  set skip to personel
  report form personel while co=course
  seek co
  set skip to students
  report form students  while co=course
endscan
set printer to
set printer off
proc findline
  _plineno=line
  return ""
proc setline
  line = _plineno
  return ""
procedure page
  para none
  if  between(_plineno,0,1)
    page=page+1
    _pageno=page && not used
  endif
  return page
  --------------------------------------------------------------------
COURS1.FRX
  PgHead  course.name
iif(_plineno=0,page(page),"")   1-dummy findline()
iif(_plineno=0,page(page),"")   Detail  _plineno  personel.name
iif(_plineno=0,page(page),"")   1-dummy setline()
  PgFoot
  --------------------------------------------------------------------
COURS2.FRX
 PgHead
 1-sid   findline()
 2-cours   course.num
iif(_plineno=0,page(page),"")  Detail  _plin    students.name
iif(_plineno=0,page(page),"")  2-cours
 1-sid   setline()
 PgFoot

----------------------------------------------------------------------
/EXIT
 post unfo
Msg#:  247738   Date:  14-Apr-92
Fm: Lisa Slater 72077,2417
To: Anders Altberg 100021,232

Page numbers isn't the problem, Anders, it's _PLINENO and getting the
pages to break properly.  You can *always* do page numbers yourself,
NBD.

But are you saying that you get this to work if REPORT FORM students
runs to several pages?  That's pretty cool... I haven't tried to do it
in a long time but when I *did* try it, I couldn't re-set _PLINENO
properly -- your procedure findline, IOW, didn't work for me.

Maybe it's different now, or maybe I just did something wrong!  The
problem of where all these system variables get re-set (and in what
order) is really crucial, but I certainly don't know all the rules...

Does this work equally well when you print to the printer, as to a
file? That's where I had the problem, I think...

>L<
