>>Ok, that's the how. What about the "should I?" It seems good in that the report is encapsulated, but loading a whole problem in one of the DE methods (probably AfterOpenTables?) seems wrong somehow. I know there's really not a "wrong" way to do things, but there are better and worse ways. I don't want to start a habit that will be frowned upon buy future bosses.
>>
>>Thanks,
>>
>>-Michelle
>
>What we have done, and I have seen it other times is to create a report catalouge. This would list all the reports in the system... It would also be a place where the user can print reports from, but it doesn't need to have an interface.
>
>Basically, you would create a class which you could call to print your reports. The class would find the record for the report. You could have fields such as...
>
>PreReportProcedure()
>PostReportProcedure()
>
>Your report class would call the procedure prior to doint the form. This would also allow you to encalpsulste stuff like
>
>Where to output to
>A selection criteria
>etc... other stuff...
>
>The report class would handle running the pre procedures, putting up the report dialog, runing the form, etc.
>
>Where would you actually put the procedures? I don't know... I would recomend either set up a class to hold them, or put them as procedures in the database.
>
>BOb

I have a form set up to print the reports from. Right now it calls the code to print the report from a .prg. I was just wondering if it would be better to put the code in the report and just call the report.

Thanks,

-Michelle