>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.

You would need some way to tell the report manager what the name of the parameter was supposed to be, wouldn't you? IOW if the report has a field whose expression is 'lcx' then the report manager would need to know it should create a local memvar named 'lcx' and store the value of the parameter in it. If you're going to write your own parser anyway, then I suppose one way to do this would be to pass a name=value string, as in

createobject("MyRptMgr","lcx=param1,lcy=param2,lcz='param3'")

I see another benefit to this: you could create a table with validation rules for each report so the report manager would know how many and what type of parameters to expect. That way it could check for missing or invalid values and respond accordingly, instead of simply letting the report fail with a VFP error like "Variable 'LCX' is not found".

FWIW, the way I use the report manager object is that it's instantiated at start-up time as part of the application object so that it's available to anybody for the duration of the app. I then pass parameters to the ShowReport method to specify the report name and options such as whether or not to ask if the user wants to print the report after they've previewed it, and whether or not to print a summary report or a detail report. The last two things are choices the user can make under 'Options' at the application level, which gives them some control over how they want reports to work.