
This file contains information about:
REPTW : Report Writer Referencing                 

******** THD203.DBF ********
Msg#:  183776   Date:  27-Nov-91
Fm: Roger Aylstock 70353,2203
To: All

I have a procedure that runs through my database and builds a 5x7
array of numeric data for 5 catagories for each of 7 days of the week.
I would like to then call my report.frx and print out the values in
the cells of the array.  I have used the Page Header of the report
builder to present a matrix of cells (similar to a spreadsheet) but
when I try to use the array name in a field expression, it says that
the expression is not valid or that it can't find the array name.  Can
I use an array in a report in this way?  How do I pass the array to
the report.frx?  I read that I can use UDF's in a report field so I
guess I could pass the UDF the cell position and the UDF could get
that value from the array and pass it back but it seems like the long
way around.  I could also load the array to a database and report from
the database, but again that seems like the long way around.  Anyone
got any suggestions on what I might try? Thanks in advance for the
help.
   Rog


Msg#:  183788   Date:  28-Nov-91
Fm: Y. Alan Griver 71541,3150
To: Roger Aylstock 70353,2203 (X)

You should be able to print array elements in the report writer.  When
do you get that error?  When you print the report or when you build
the app. Would the FP2 Crosstab function help you here, btw?  How do
you get the data into the array, is it a lot of work?

yag

Msg#:  183838   Date:  28-Nov-91
Fm: Juergen Wondzinski 100015,676
To: Roger Aylstock 70353,2203 (X)

Roger,

You can definitly use arrays in reports...  But the array has to be
present when you do the preview or when you run the report. When
designing the report, you have to somehow create this array from the
commandwindow or save it in the original program and restore it later.

Another problem is coming, when you include this report into a
project.  Then the project manager alerts you for not finding
<ArrayName>.prg... I haven't found a way to avoid this error, since
you cannot put a #EXTERNAL ARRAY into the report...

JACKIE, CHRIS, ROGER any help to this part?

        servus
                wOOdy

Msg#:  183916   Date:  28-Nov-91
Fm: Lisa Slater 72077,2417
To: Roger Aylstock 70353,2203 (X)

How are you referencing the array in the report expression?  That
could be a problem, I suppose.

But the most likely possible scenario is this:

You have a program which calls the report.  Just prior to calling the
report is another line (DO subproc) that calls a subprocedure that
initializes the array.  This array isn't "known" to the parent
procedure, and hence not to the REPORT FORM, which is like another sub
procedure.

You can initialize the array in the parent program and then fill it in
the sub proc (so it is "public to the whole module") or you can make
it PUBLIC in the sub procedure and release it later.  Or (this is what
I prefer) you can make the initializing sub proc a UDF that you call
on startup by initializing a report variable to it... just store the
value .t. to the report var after that and never reset it...

>L<


Msg#:  184244   Date:  29-Nov-91
Fm: Cathy Selhorst [Fox] 76177,3002
To: Juergen Wondzinski 100015,676 (X)

wOOdy,

Providing a method of alerting the project manager about the array
reference within the report has been passed on to the development
staff as an enhancement.

Cathy


Msg#:  184252   Date:  29-Nov-91
Fm: Cathy Selhorst [Fox] 76177,3002
To: Juergen Wondzinski 100015,676 (X)

wOOdy,

I forgot to add in my previous message that you can declare the array
public. If you do, you will not receive the error from the project
manager.
Cathy



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

Paul,

I don't think your problem is that the RW has a different idea about
syntax than the rest of FP.  But there are a lot of places in the RW
that macros are a bad idea. Try your example this way instead:

   IIF(.T., EVAL(r_invoices+".subtotal"), 0.0)

.. and I think you are going to get what you want.

>L<

Msg#:  215165   Date:  08-Feb-92
Fm: Warren Van Orden 72611,1053
To: Paul L. Inman 70720,2614 (X)

You're right, the missing quote.   You've probably read Lisa's
response by now (#214501).  She knows where to place the quotes.

Although here example reminds me of the REAL reason I don't use the
period to separate the alias name from the field name.  First time I
glanced at the code I thought "the macro terminator doesn't belong
inside the quotation marks".  My mind parses the "->", even if FoxPro
doesn't.

Probably more crucial, searching code for "->" is possible, but
searching for a period would return a lot of meaningless clutter.

Warren

Msg#:  215228   Date:  08-Feb-92
Fm: Paul L. Inman 70720,2614
To: Warren Van Orden 72611,1053

Excellent point regarding searching for "->" vs. "."! I'll have to
consider that form more often, especially since virtually all of my
references to work areas are via variables - I write a LOT of black
box routines which have no idea of the context of the call and
cannot risk clobbering the current state of affairs. They all use a
UDF to return a unique (unused) work area's letter alias when passed
the name of the desired database. So, I end up with a lot of variables
representing work areas. On the other hand, I can pop up windows to
perform activities from almost anywhere, with little regard to what
else is going on (I come from the world of MS Windows programming, so
I am real big on user driven software).

I don't know *how* I got going on all of that! Stream of conscience...
I should compose these offline.

Anyway, thanks for the comments!

   -Paul
