
This file contains information about:
REPTW : Report Writer General Tips & Tricks       

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

Msg#:  20799   Date:  26-May-91
Fm: Lisa Slater 72077,2417
To: Ellen Sander 71001,3724 (X)

Although I haven't used PLAIN in a long time, its meaning used to be
that it suppressed page headers after the first page... let's see...
it is still working as advertised. Kind of.  It gets weird when you
also have "PLAIN" checked off in report options.

If you have both PLAIN and HEADING in the command, it will suppress
the page headers after the first page and the HEADING clause entirely,
I think.

>L<

Msg#:  16410   Date:  11-May-91
Fm: Lisa Slater 72077,2417
To: Jim McKinney 75140,2217 (X)

I haven't tried it, no.

Let me think about this...

OK, this works for me (unless I'm misunderstanding you).  When you
build the project or the executable, you will get an error, "unable to
locate file temp.frx" but you just need to tell the "builder" to
ignore that. It doesn't hurt anything:

  newsize = 24
  use a.frx
  copy to temp.frx
  use temp.frx
  locate for objtype = 1        && should be first record anyway
  replace height with newsize
  replace ejectbefor with .f.
  replace ejectafter with .f.   && etc.
  use x                         && etc. etc.
  report form temp
  erase temp.frx
  erase temp.frt

>L<


******** THD201.DBF ********
Msg#:  120401   Date:  22-Jul-91
Fm: Chip Doolittle 73347,2775
To: Tony Stewart 70233,1745 (X)

Tony, not to but in buuut..

I have a report dbf that has a 35 character description field.  I use
this with the popups for the user to pick.  I also have a bunch of
other fields such as report length, size paper, the actual FRX name,
is it queryable, what order this report is printed, what relationships
it has etc. etc. etc. Goodness knows my users would be lost if they
had to choose from frx's, but choosing from 'Customer list by last
name' looks a lot better.

       --Chip

Msg#:  121273   Date:  23-Jul-91
Fm: Lisa Slater 72077,2417
To: Chip Doolittle 73347,2775 (X)

Don't forget you don't really have to maintain the frx dbf the way you
used to in 2.0.  Just write a program to take a look at the project
database and grab all the frx's from there... there are a lot of memo
fields that are not used the pjx for a report-type record.  I haven't
tried it yet but probably you could stick the report name right in
there (since the field isn't ordinarily used for reports, I don't
expect FP will ever look in there and get confused <g>!). If this last
part doesn't work, you could stick the "long name" into the Comments
memofield of the first record (you remember, the stuff that used to be
the first line in an FRX file?) of the FRX itself...

>L<

Msg#:  141961   Date:  31-Aug-91
Fm: Lisa Slater 72077,2417
To: Martin Schiff [CONSULT] 76702,1355 (X)

Martin, you basically have to have a non-read-only copy of the report
(means not the one in the .APP) to do this... it's not such a big
deal, though. Your install program does something like this, using the
read-only "model" your app contains:

      SELE 0
      USE mergeltr.FRX       && the one in the app
      COPY TO mergeprt.FRX   && the one you'll actually use
      USE mergeprt.frx
      REPLACE height WITH newheight NEXT 1
      USE

>L<


Msg#:  142056   Date:  31-Aug-91
Fm: Lisa Slater 72077,2417
To: Martin Schiff [CONSULT] 76702,1355 (X)

If your app is distributed with the frx files separate, then they are
modifiable as is, no problem, that's correct.

BTW, let me clear up a certain misunderstanding that it *sounds* as if
you have (and that others may have, forgive me if you already know
this, Martin):
It's not that _PLENGTH doesn't override the page setting, exactly.  Or
it's not exactly that it doesn't affect reports.

The fact is that _PLENGTH is not going to affect a report if you have
_PADVANCE set to its default of "FORMFEED".  However, *if you use a
non-default page length for your printer* (if, for the most common
example, you're printing continuous form invoices of 7" or continuous
form postcards on a dm printer), you will need to set _PLENGTH
properly, which usually means *TO MATCH YOUR REPORT FORM LENGTH*. You
will also set _PADVANCE to "LINEFEED".
Page length in the FRX determines how long the report is per page.
But at that point, if you don't want an EJECT set (which, in this
case, you don't), _PLENGTH will determine how many line feeds are
issued to get to the next top of form.

OK?

Or at least this was my experience with 1.02.  I haven't tried it in
2.0 yet but I have no reason to believe this has changed.

>L<


******** THD202.DBF ********
Msg#:  154581   Date:  27-Sep-91
Fm: Cathy Selhorst [Fox] 76177,3002
To: Harvey Minot 76347,3041

Harvey,

Filters are not saved when saving the Environment for a report.  This
is working as designed.

Cathy



Msg#:  162694   Date:  16-Oct-91
Fm: Bill Pearce [TSC] 76675,2537
To: Lisa Slater 72077,2417 (X)

 Lisa:

Is there any way to force the REPORT command to abort?  I tried the
following UDF which I thought should work, but it doesn't.

 SET FILTER TO
 SKIP 1
 IF LOCATION > ENDLOC
    GOTO BOTTOM
 ELSE
    SKIP -1
 ENDIF
 SET FILTER TO <original setting>
 RETURN

I put a call to this UDF in the REPORT format at the end of the detail
line, and it did in fact go to the last record when the last valid
location record was reached, but the REPORT command still burned away.
It must be keeping it's own record pointer or something.  Any ideas?

       Bill

Msg#:  162715   Date:  16-Oct-91
Fm: Lisa Slater 72077,2417
To: Bill Pearce [TSC] 76675,2537 (X)

The RW doesn't "keep its own record pointer"! I prove this in almost
every report I write. <g>  And I've used the GO BOTTOM command to
interrupt reports, so I *know* that works.

What do you mean "the REPORT command still burned away"?  Do you mean
after the GO BOTTOM, or that the whole report is still slow?

It can't do any output if you've reached the end of the
condition-group, so the former seems unlikely... in re the latter, I
would think that doing that SET FILTER back and forth in every detail
line would cost you a *considerable* amount of time, though. Remember
we don't know exactly how re-usable the last set Rushmore creates from
the last-but-one SET FILTER command is to the new SET FILTER TO
<original setting>. I would tend to think it has to create a whole new
map or whatever.

I suppose you could try putting the SET FILTER TO <original setting>
inside the ENDIF, so it isn't done for the last record.  I don't
really see why this would make any difference, though, unless "the
REPORT command still burned away" meant "after the GO BOTTOM".

Bill, I'm taking it on faith that your tags are all exactly the same
as your filter expressions, I *hope* we're not wasting our time here
<sigh>... let me know if it is faster/slower with a conditional index
instead, okay?
>L<

Msg#:  162729   Date:  16-Oct-91
Fm: Bill Pearce [TSC] 76675,2537
To: Lisa Slater 72077,2417

 Lisa:

 OK, I put a RETURN inside the IF......

 SET FILTER TO
 SKIP 1
 IF LOCATION > ENDLOC
   GOTO BOTTOM
   RETURN
 ELSE
   SKIP -1
 ENDIF
 SET FILTER TO <original>
 RETURN

... so that the filter is NOT getting reset on the last record before
returning control to the REPORT command and that worked. Stopped on a
dime after the last record. It doesn't seem to slow the processing
speed down, but then again this report has a full page of detail lines
and I've got a slow printer.  I'll have to try the same thing on a one
detail line report. I've got several that need it.  Setting that
filter back to the report conditions messed up the REPORT record
pointer for some reason.  When I said burning, I meant it kept looking
for records after the last record meeting the report condition had
been met. I'm not gonna try the index method, because this has got to
be faster. FP's not gonna index a 5000 record file in under 1 second,
no matter how good Rushmore is. That's how long it takes FP to find
the first record (even at the end of the file) with the FILTER method.

 Thanks for your help.       Bill


Msg#:  162825   Date:  16-Oct-91
Fm: Lisa Slater 72077,2417
To: Bill Pearce [TSC] 76675,2537 (X)

Well, then, your answer is 'Yes, "the REPORT command still burned
away" meant "after the GO BOTTOM"'.

If you'd said that before I would have seen what was wrong with your
UDF much sooner <g>.

Glad it's solved now, anyway, just sorry about all the time-consuming
red herrings...

Even with a one-detail-line report, this method might work out for you
if your printer is slow.  Hard to say; let me know what you find.
This is generally useful and interesting stuff.

>L<

Msg#:  163004   Date:  16-Oct-91
Fm: Bill Pearce [TSC] 76675,2537
To: Lisa Slater 72077,2417 (X)

 Lisa:

 No slow down on a one liner.  Using a 486 though.  Might be different
on a 286.  I would think a 386 would keep up.

      I learned a lot of new stuff today.  Thanks.


                          Bill



******** THD203.DBF ********
Msg#:  173746   Date:  06-Nov-91
Fm: Lisa Slater 72077,2417
To: Ira Kemp 74066,3412

OK.

Printing the line numbers is quite possible...

What I suggest you do is to put a report expression next to your memo
field report expression (same line, I mean).  Format this expression
as @J; (that should be at-sign J semi-colon, in case CIS messes up
<g>-- it means "right align and line-break on semi-colon").

Make this expression as wide as you figure you may need it for the
number of memolines -- if you might have 1,000 lines in one memo, for
example, make it 4 chars wide, at least for the rudimentary version
I'm giving you. The report expression itself should be a UDF.  When
you get the idea of what I'm suggesting, you should be able to change
it to suit yourself with more elaborate formatting; but this version
*will* give you line numbers next to your memofield.

Before running the report, SET MEMOWIDTH TO the width of the memo
expression so that MEMLINES() will behave properly. If this is
impossible for some reason, save and re-set it within the UDF itself
as I show you below.
Here's my simple UDF:

   FUNCTION the_udf
   oldwidth = SET("MEMOWIDTH")
   SET MEMOWIDTH TO the_width_of_the_memo_expression
   xx = MEMLINES(the_memo_field)
   SET MEMOWIDTH TO oldwidth
   mreturn = ""
   FOR x = 1 TO xx
     mreturn = mreturn + ALLTRIM(STR(x))+";"
   ENDFOR
   RETURN mreturn

.. not too shabby for a few minutes work <g>.  You could make it
generic by passing the function the width of the memo expression.

Your other idea ("page 2 of whatever") would take quite a bit more
effort, although I believe I could probably do it also <g>.

>L<


Msg#:  182864   Date:  26-Nov-91
Fm: Robert Turenne 73457,3343
To: Chaim Caron 72520,2272

There's another way to suppress form feed at end of page.  I had the
problem while printing to a file. FP kept sending CHR(12) to the file.
I created a small function that STORE 0 TO _PLINENO.  FP then thinks
it never reaches end of page.  Of course, that report did not have
header and footer info.  I just wanted to create a clean ascii file.
Robert.


******** THD204.DBF ********
Msg#:  184901   Date:  01-Dec-91
Fm: Jeff Davis 70242,1470
To: David Applin 100012,2106 (X)

'Scuse me for jumping in on this thread, but if I understand what you
are trying to do correctly, there is a MUCH easier way to do it.

1.  Give your users a pre-defined list of variables to put into their
form letters.  You could use an OKL to bring up a popup on screen, and
when they select it, load their selection into _CLIPTEXT and paste it
into thier letter. This is how Q&A does it, and it's really easy for
the user.  It'll keep them from having to learn the complexities of
IIF() and other Foxpro specific stuff.

2. Before printing each record, initialize the non-field variables
(i.e. the ones which aren't actual database fields...

3. Use a report form.  I've already done this and it works great.
Just include the memo field containing the merge text and check the
"Stretch Vertically" box.  Incidentally, by using a report form you
can use the "Variables" option to have the memvars created on the fly,
which would minimize hand-coding (call me lazy, but it works with a
minimum of fuss).
If you like I can try and put together a small example of this
procedure.
JD =:)


Msg#:  192258   Date:  17-Dec-91
Fm: Bob Reagan 75236,1430
To: Lisa Slater 72077,2417 (X)

Lisa,

On a slightly related note ... Is there any way to prevent the aliases
from becoming part of the report definition?  Sure makes it hard to
use the same FRX with different DBF's, even if the fields are
identical.


Msg#:  192354   Date:  17-Dec-91
Fm: Lisa Slater 72077,2417
To: Bob Reagan 75236,1430

Sure thing.

Un-check "add alias" if you start with a quick report, and no aliases
will be included when you use the EB.  If you don't start with a quick
report, just go into the EB Preferences dialog, and you'll see fairly
sophisticated options for controlling its use of aliases....

If your report already has aliases in it, you can write a small
procedure to remove them from your report definitions by USing the
FRX.  I think there's one of these in the book somewhere...

>L<




******** THD205.DBF ********
Msg#:  202710   Date:  13-Jan-92
Fm: Lisa Slater 72077,2417
To: Bob Duncan 76517,1733

Bob, with a report, you can use either NOCONSOLE or OFF.  With LIST,
since OFF refers to the recno()s, you can only use NOCONSOLE.  Check
the LBN <s>!

>L<

Msg#:  207880   Date:  23-Jan-92
Fm: Lisa Slater 72077,2417
To: Stephen Cox 71640,2036 (X)

Fred, Stephen,

I do it a little differently <g>.

  total_page = "0"
  REPORT FORM the_report NOCONSOLE
  total_page = ALLTRIM(STR(_PAGENO-1))
  REPORT FORM the_report TO PRINT

... the report has an expression that is something like this:

  "PAGE "+ALLTRIM(STR(_PAGENO))+" of "+total_page

It may seem weird to do this but it's the only way I know to account
for stretching memo fields, multiple groupings and stuff like that
-basically you are running through the report "in the report writer's
head" once.
>L<

Msg#:  208112   Date:  23-Jan-92
Fm: Fred A. Stewart 70471,2041
To: Lisa Slater 72077,2417 (X)

Lisa;

       If I understood Stephen properly he needs more than total pages
for his report. He wants to know total pages breaking on a group.
Therefore he appears to need something more complex as I've tried to
advise.

?ok-eh<g>  ( obscure Canadianism )

Fred

Msg#:  208175   Date:  23-Jan-92
Fm: Lisa Slater 72077,2417
To: Fred A. Stewart 70471,2041 (X)

Fred,

You'd be able to handle this with a slight adaptation of my approach.
I assume you are saying that he is using new page on group/ reset page
number on group here (otherwise this doesn't make much sense to me,
but it really doesn't matter -- see the note in the UDF below).

You'd create a report variable to count groups. Before running the
report the first time, you would set a flag (call it firsttime) and
initialize an array (you should probably PUBLIC it so it doesn't
confuse the PM <sigh>).  In the *group footer*, you would put a UDF
that did something like this:
   IF firsttime
     DIME the_array(current_group_count)
     * redime the array to have current group count # of elements,
     * using the reportvar
     the_array(current_group_count) = ALLTRIM(STR(_PAGENO))
     * if he isn't using reset page number on group, you simply
     * have a another couple of report variables to provide a
     * page count on the group level -- this isn't hard --
     * and STORE that instead of _PAGENO here
   ENDIF
   RETURN ""

Before running the report the second time, you set firsttime .F.

Now your page number expression would be something like this:

    "PAGE "+ALLTRIM(STR(_PAGENO))+" of "+ ;
            IIF(firsttime,"0",the_array(current_group_count))

.. clean up by RELEASing the array and flag after running the report
the second time.

I haven't fleshed this out and there could be problems with it that I
haven't (yet) dealt with, but frankly, I don't think your advise
handles "somewhat more complex" situations, since it cannot be used
with suppress blank lines, floating or stretching lines, etc.

>L<

******** THD206.DBF ********
Msg#:  217442   Date:  12-Feb-92
Fm: Lisa Slater 72077,2417
To: Bob Duncan 76517,1733

There are a lot of nice things about PREVIEW.  For one thing it is
nice when you have printer drivers in place, since you don't end up
with messy codes in your view of the report.

For another thing MODI FILE/COMM can take a lot of disk space and time
for a really big report, because it has to run through the whole thing
"in its head" whereas PREVIEW does it a little at a time.  If the user
only needs to see a few records to check something, that's all that
gets run.

I enjoy it! It's limited but it's easy. NBD if you don't, though <s>.
>L<Msg#:  218047   Date:  13-Feb-92
Fm: Bob Duncan 76517,1733
To: Lisa Slater 72077,2417 (X)

Will PREV allow you to scroll up and down through the report output?
Bob.Msg#:  218098   Date:  13-Feb-92
Fm: Lisa Slater 72077,2417
To: Bob Duncan 76517,1733

Nope, just down, but sometimes that's good enough.

To get scroll up *and* down you need to have the whole report "done".
I think Preview is more like a browse -- it paints only what it needs
-- and probably unlike a browse it is only designed to "paint" in one
direction because reports are designed for calculations as you move
through the records.  I know you *can* do this in a browse but it's
difficult to get it behave when you page up and down, isn't it <g>?

>L<
Msg#:  222954   Date:  24-Feb-92
Fm: Tamar E. Granor 73227,3303
To: Lisa Slater 72077,2417 (X)

       What I was thinking about here was what if you want to use the
same report form to both process a query result and work with the
original dbs? Say you have invoices and line items with the obvious
1-to-many relationship.  If you make the report to work with the
original 2 dbs, you need to alias at least the line item fields.  But,
if you then create a table with Select that incorporates both invoice
and line item info, the report won't work.        I don't think this
is a big issue for me, but I think this is the question Louis was
asking in the first place.
       Tamar

Msg#:  223016   Date:  24-Feb-92
Fm: Lisa Slater 72077,2417
To: Tamar E. Granor 73227,3303 (X)

Yep, that's why I said the answer is *generally* to remove the
aliases.
However, it's possible to build a cursor or temp table to contain a
result set for output but without joined information from lookup
tables, to save space or time, and then build its relations with the
lookups the same as you would do with the original table.

That's why the answer to his original question, taken literally:

>> If I send a Query to a report does the report have to be aliasless?
<<
is actually "no".  You just want the expressions from the *selected*
workarea (which would be the main table or cursor/temptable) to be
aliasless.
Make sense <s>?

>L<

Msg#:  223098   Date:  24-Feb-92
Fm: Tamar E. Granor 73227,3303
To: Lisa Slater 72077,2417 (X)

       Yeah, it makes sense, and I did know it.  It just is one more
in my growing list of things that make certain kinds of debugging
harder.  In this case, unless I do a select before editing the report
form, I can't preview the report, since the RW doesn't know about the
fields.  I guess I could keep a dummy table around, but I'd need a
different one for each report, so it's probably not worth it.  Oh,
well, it's not that much trouble, just a minor annoyance.
       Tamar

Msg#:  223159   Date:  24-Feb-92
Fm: Louis D. Alston, III 76004,1504
To: Lisa Slater 72077,2417 (X)

>>Make sense <s>?<<

Yup, but it wasn't quite what I was thinking.  I'd like to have a
report that I would use for general relational dumps, but I'd also
like to send queries that would do relational sorts, filters et al.
The only other way I could think of to do this would be to use
complicated indexes.  I think a query would make more sense.

What I'm asking is does it make sense to use queries to filter
information to reports 51% of the time.  And if so does it make since
to do so 100% of the time just for the advantage of having data
'independent' reports.
Gee I hope all that made sense.

Msg#:  223310   Date:  24-Feb-92
Fm: Lisa Slater 72077,2417
To: Louis D. Alston, III 76004,1504 (X)

Well, it sorta made sense <s>.

The problem is not so much the aliases -- you can fix that with one
all-purpose alias used for either cursor or real file -- but with the
fact that in one case you can have the same fields coming from one
file whereas in the other they are coming from more than one file.

The only way I know to handle this is to store the aliases to
variables. In one case, you store the same alias (or a null string) to
*all* the variables, whereas in the other you store different aliases
to the different variables. These variables are then used as part of
all your field expressions, using EVAL().

Alternatively, I suppose you could use a PRG on your FRX, REPLACing
aliases in all field expressions as necessary for each use of the FRX.
Not sure it's worth the effort but you could do it.

Frankly, I'd design the report using the real files, strip the aliases
using my UNALIAS.PRG on the FRX *once*, and then use that report with
a query 100% of the time.

>L<Msg#:  223304   Date:  24-Feb-92
Fm: Lisa Slater 72077,2417
To: Tamar E. Granor 73227,3303 (X)

I wouldn't keep a dummy table around for testing the report... I'd
keep a dummy *query* around. Would take up less space <s>. If its
"result" is REPORT... PREVIEW it's not *quite* the same as a Ctrl-I
but it's pretty close...

>L<

Msg#:  224244   Date:  26-Feb-92
Fm: Jerry Ela 71051,1230
To: Lisa Slater 72077,2417

I keep a database with the same name as the report and one record (or
as many as needed to preview the report) with the report. This allows
me to use the RW field picklists etc.  Also some some of my reports
use the results of queries that take up to 20 min to run (multiple
outer joins). Running the query to test the report is not a practical
option.


Msg#:  214900   Date:  07-Feb-92
Fm: Larry Keyes 75170,64
To: Lisa Slater 72077,2417 (X)

That is exactly it.  I want to summarize *some* line items, and print
out the full detail of others, perhaps based on a flag in the line
item record.
(This is from a client..... no way would I think this idea up on my
own...) <g>.   -- Larry

Msg#:  215020   Date:  07-Feb-92
Fm: Lisa Slater 72077,2417
To: Larry Keyes 75170,64 (X)

Bleh <g>.

Well, here's how you'd have to do that:

-- all your group totals would have to be report variables but you
would have to accumulate the information into them yourself.

-- Do this accumulation at the end of the group header band, with some
CALCULATE WHILEs. Check the flag.  IF summarize, stay where you are.
ELSE SEEK groupexpr, to go back to the first record.

>L<

******** THD07.DBF ********

Msg#:  276446   Date:  19-Jun-92
Fm: Elaine Fogt [Fox] 76711,570
To: Greg Van Boven 71740,1770

Greg -

This is a function of FoxPro.  When a Report Form is printed to a file
an extra linefeed is added at the top of the file.  At this point, the
only way to remove this line is to use low-level file functions to
remove the linefeed or to play a keyboard macro.

Elaine

Msg#:  269211   Date:  03-Jun-92
Fm: Dave Watkins [Fox] 76004,2575
To: Thomas J. Wieczorek 73210,2715

Thomas,

You may want to check Library 2 or Library 6 for a thermometer
program. The following program utilized the FP2 function CHRSAW()
which may help you to get the output of a REPORT FORM to stop
printing:

       SET ESCAPE OFF
       IF CHRSAW()
          WAIT WINDOW "" NOWAIT
          IF LASTKEY() = 27
             GO BOTTOM
          ENDIF
       ENDIF
       RETURN""

Just call the above program STOPIT.PRG and in your report detail line,
just add a field and have the expression be STOPIT() with a width of
1.  You could refer to the Report Writer section of the FoxPro
Interface Guide for additional information on implenting a UDF inside
of a report.

I don't know of a way to estimate the amount of disk space needed when
using a .CDX, but I will do some checking around Thursday and see if I
can uncover anything.

--Kevin [Fox]Msg#:  269232   Date:  03-Jun-92
Fm: Calvin Hsia 72251,1725
To: Thomas J. Wieczorek 73210,2715

Tom,

Try ON KEY LABEL ESC GO BOTT

CDX size is not easily calculated. It depends on your data.  If many
of your index keys are similar, then they will be more compact.

i.e.   SMITHSONIAN, JOHN and SMITHSONIAN JAMES

The old way would store both keys. The FP 2 way stores the first, and
just the changes to make the 2nd.

Msg#:  251097   Date:  22-Apr-92
Fm: Erik L. Rogers 70323,1673
To: Lisa Slater 72077,2417 (X)

Lisa,

   Another question for ya!

   I have a daily transaction report printing. I do my SQL into a
cursor and then do my REPORT FORM. When the cursor (or for that matter
any DBF) is empty the report generator does not generate a report. No
Page headers, footers....nothing. What I want is a Report that shows
me my page header, no detail, and totals at the bottom.  There is an
opening and closing balance that are predefined and get printed as
part of a lengthy summary.
   any ideas?   TIA, Erik
Msg#:  251339   Date:  22-Apr-92
Fm: Lisa Slater 72077,2417
To: Erik L. Rogers 70323,1673

Pick some other file for your SELECTed file, then.  Anything with at
least one record.  Do the following:

REPORT FORM SUMMARY NEXT 1

I *think* this will do what you're asking for.  You should check
_TALLY after your SELECT to decide when it is necessary.

>L<
Msg#:  251789   Date:  23-Apr-92
Fm: Erik L. Rogers 70323,1673
To: Lisa Slater 72077,2417

Lisa,
   Thanks a lot for your help. I plugged some code into my report
generator module and now reports that have empty data sets print a
summary shell. The only additional test I needed was some additional
code to account for the possibility of a user generated FOR or WHILE
clause. So instead of _TALLY after my QUERY is run I do:
     COUNT &forexpr &whilexpr TO lctally
and test lctally for > 0. If not then I SELECT a file that I know has
one record (my user profile in this case) and issue the REPORT FORM
SUMMARY NEXT 1. Since this command is issued without the ENVIRONMENT
clause everything works the way I want it to.

     Thanks again.

     Erik

Msg#:  233198   Date:  16-Mar-92
Fm: Chris Pudlicki [Fox] 76702,1237
To: Charlie Plowman 70400,1747 (X)

-Charlie

To do what you want with the RW you would need to create a single
field item with the expression that Doug described. (ALLTRIM(lname)+",
"+
ALLTRIM(fname)+" "+mi)

This is because the FP RW treats each item or field on the report as
an individual object and places it starting at a specific position.
This is a completely different approach from dBIV which concatenates
each line into an individual print statement.

--ChrisMsg#:  226421   Date:  02-Mar-92
Fm: Carl Karsten 70471,516
To: Anne E. Pruitt 72335,777

Anne, Not only am I going to show you a way to pause a report, but it
also includes code to display the percent done on the screen (kinda
neet!). In your FRX, define a Variable as Name: RPRTCLC, Value to
Store: GPRTCLC(), Initial Value: 0, Calculate: Nothing.  Back in your
calling program: COUNT TO XRECTOT
XRECCNT = 0
REPORT FORM ??? TO PRINT

PROCEDURE GPRTCLC
XRECCNT = XRECCNT + 1
@  5, 70 SAY XRECCOUNT/XRECTOTAL * 100 PICTURE "999"
IF INKEY()<>0
  DO GPRNPSE
ENDIF
RETURN ''

PROCEDURE GPRNPSE
WAIT WINDOW

My GPRNPSE gives the users the option of continuing, stoping, or print
one line (KEYBOARD ' ', prints untill the inkey is checked again, then
pauses again.)

Im running out of room, so let me know if you want more info.

^Carl

Msg#:  227068   Date:  03-Mar-92
Fm: Chris Pudlicki [Fox] 76702,1237
To: Anne E. Pruitt 72335,777 (X)            -Anne

The only method that I am aware of, to interrupt a report, is to
include a UDF in the report form that checks for a certain keypress
then gives you the option to stop the report.

--Chris

Msg#:  229244   Date:  08-Mar-92
Fm: Lisa Slater 72077,2417
To: Jim Hendricks 70313,2123

Jim,

If the FRX had code snippets, it would have to generate code to be
run.  If it generated code to be run, it would have to be compiled.
If it had to be compiled you couldn't let your users MODI REPORT and
you couldn't USE the FRX programmatically to adjust the report
yourself if your users ran under the DK instead of the Dev edition.
So there are always tradeoffs.

Meanwhile, I think you can do what you want if you do something like
the following:

   mselect = SELECT()
   m.pause = .T.
   SELE 0
   USE y.FRX
   REPLACE height WITH 24
   DEFINE WINDOW x FROM 0,0 TO 24,79 NONE COLOR SCHEME 10
   ACTIVATE WINDOW x
   SELECT (mselect)
   REPORT FORM x
   RELEASE WINDOW x

 where your report form has a UDF in the page footer:

  IF m.pause
      WAIT WINDOW
      IF LASTKEY() = 27
        GO BOTTOM
      ENDIF
  ENDIF
  RETURN ""

.. what do you think; would it fly?  To use the report normally, you'd
simply USE the frx, replace the height value with whatever you wanted,
and say m.pause = .F.>L<
