Hi Rick!

How about taking this a step further?

Since you're using a class that takes care of calling the report, how about passing the parameter(s) to that class?

createobject("MyRptMgr","param1,param2,'param3'")

The object then would take care of parsing that "comma-delimited-quasi-stringified-parameters-list", creating variables of the right kind for the report to access.

Alex

>Hi Alex,
>
>>I've been doing some very neat things with this, such as having standalone reports to which I can pass parameters (as local variables).
>
>Yes, this is a very useful way to pass "parameters" to reports. I'd like to suggest that it's better practice to use PRIVATE rather than LOCAL, though, in case the REPORT command is not actually in the same method as the memvar you want to reference. For example, I use a report manager object to render reports in my apps. In this case LOCAL does not work because the REPORT command is in a method of the report manager object, and a memvar defined as local in the original procedure is no longer in scope. However, PRIVATE works fine in either case.
>
>Examples are below. MyReport has only one field in the detail band and it references lcx.
>

>*  Test local vs. private memvars with a report
>
>*  Create a dummy table with one record so report 
>*  doesn't terminate immediately.
>create table myTable ( cField1 C(10))
>insert into myTable ( cField1) values ( "aaabbbccc")
>
>*	Test 1
>LOCAL lcx
>lcx = "Hello World"
>REPORT FORM myReport PREVIEW  && This works.
>RELEASE lcx
>
>*	Test 2
>oRpt = CREATEOBJECT( "myReportMgr")
>LOCAL lcx
>lcx = "Hello World"
>oRpt.ShowReport( "myReport")  && This does not work because lcx is local
>                              && and therefore is not in scope in oRpt.
>RELEASE lcx
>
>*	Test 3
>PRIVATE lcx
>lcx = "Hello World"
>oRpt.ShowReport( "myReport")  && This works because lcx is private
>                              && and therefore IS in scope in oRpt.
>RELEASE lcx
>
>USE IN myTable
>ERASE myTable.dbf
>RETURN
>
>DEFINE CLASS myReportMgr AS CUSTOM
>
>PROCEDURE ShowReport
>LPARAMETERS tcReportName
>REPORT FORM ( tcReportName) PREVIEW
>ENDPROC
>
>ENDDEFINE
>

>
>-Rick
>
>
>>Hi Larry,
>>
>>Aparently there's a bit more to reports than meets the eye.
>>
>>As Sylvain mentioned, from a report you have access to all the local variables of the entity that called it.
>>
>>You can also refer to the report's dataenvironment object by using the report's name. i.e. MyReportName.tag. I haven't tried calling de methods from report variables, but I don't see why it couldn't be done.
>>
>>I've been doing some very neat things with this, such as having standalone reports to which I can pass parameters (as local variables).
>>
>>I think there's a lot of potential there...
>>
>>Alex
>>
>>>Hi All,
>>>I am in the process of creating a report and I tested something just to see if it would blow up. It didn't so I wanted to see if I am just late in discovering this "feature" and if so, how many out there are using it.
>>>
>>>In order to handle a lot of the cursor building stuff, I run my reports through a wrapper class. The class is a form (it used to be the only datasession object around) with a private datasession. I wanted to find out if I could add properties to the wrapper class and use them in the report for header/summary stuff. It worked!! I was able to use AddProperty in the wrapper class and display this on the report using THIS.MyNewProperty. I guess reports are different than PRGs.
>>>
>>>Comments?