>>>You might also try using a PRIVATE variable in the routine that calls your report form. It won't go out of scope like the LOCAL will. I have several static variables passed to reports with this method.
>>
>>Using PRIVATE in that way is every bit as bad as using PUBLIC variables. Macro sub is THE answer if he's going to use SET FILTER.
>
>

PROCEDURE PrintInvoice
>Private r_CompanyName
>r_CompanyName = Thisform.CompanyName
>REPORT FORM Invoice
>ENDPROC

>
>Overlooking the lack of error checking on such a simple example, I don't see why doing this is bad. Can you clarify?

Jay used a set filter, which is not what your example is doing.

However, as a rule, information should be explicitly passed between modules, encapsulation is a good thing. For your example, just add an r_CompanyName variable to the report with a different value and see the harm that causes. Another programmer given a report to modify would be unable to know all the possible private variables hanging around in your system before the report gets called.

The report could call a UDF which returns the company name. That gives you a single place to maintain the name and encapsulates the report and the UDF.