Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Use of THIS in a report
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire de rapports & Rapports
Divers
Thread ID:
00570893
Message ID:
00571009
Vues:
23
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?
Rick Borup, MCSD

recursion (rE-kur'-shun) n.
  see recursion.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform