>>7. What about pre and post processing hooks for each report?
>
>What kinds of pre- and post-processing are you thinking of (ideas you have may help us add more hooks).

-Basically to do things that I asked about if not specifically like Prompting for filter values. (generally for date ranges.)
-Also, updating a table that a report was printed... for example, our COBRA module has a correspondence audit table that is updated every time a notification letter of some type is send to a beneficiary.
-Our Checks have a UDF in them that will update the check file with the check number that was printed... Perhaps the report layout could call a report method? I assume you are using the report objects you published in FoxTalk.

>We've tried to make SFReports simple for the end-user (the primary design goal) but also very flexible for the developer. I think we've accomplished that, but look forward to other comments you have to make it even more flexible.
>
>Doug

I see that ... I am always impressed with the products that come out of Stonefield... they always seems to be powerfull yet simple to use at the same time... that is a hard balance to maintain yet you usually hit it.

One other thing... what about batch report definitions? Basically the ability to add a 'batch' report to the library of reports that contains several other reports with the filter for each report contained in the batch defined at the batch level. Running the batch would also force all 'ask at runtimes' to be prompted for all reports so the user can walk away after saying go.

If I think of anything else I will let you know.

BOb