Hi Bob.

>1. I didn't see any thing about grouping... any support for that?

Yes. In the New/Edit Report Wizard, you can select a field, then choose the Field Properties button to display a Field Properties dialog. This dialog allows you to define a number of things about the field, but one of them is to define grouping.

>2. Is there support for calculated report/group totals or do you have to create calculated fields for that?

That's in the Field Properties dialog too.

>3. What about parent/child/multiple file reports?
>4. Support for summary/detail reports?

For reports defined by the user, we only support row and column style reports. However, these reports can include fields from any table, so the user could, for example, define a report with a parent field as a group and child fields as the details. For more complex reports, see the next point.

>5. Are all report layouts generated by the Wizard or can you build the report layout yourself and just use the Wizard for filter/sort selection.

The latter. All reports are defined in a reports table. The New Report Wizard creates records in there, but since it's just a table, you can add reports you've created to this table (we call them "standard" reports because they're usually part of the app rather than ad-hoc reports the user creates) and use the Report Wizard as a report "manager" (select, filter, sort, and run).

>6. What about suport for runtime prompting... for example... if you print a employee profile prompting for an EE name... or even providing a pick list.

SFQuery 6 (which I'm also currently working on) will support "ask a runtime" queries. SFReports will work with both SFQuery 5.1 and 6, so when you upgrade to SFQuery 6, "ask at runtime" will magically kick in [g].

>7. What about pre and post processing hooks for each report?

That can be handled in several ways. Each report can have its own report class behind it, so you can subclass SFReport (the base class for a report "object") and put code into the RunReport method, such as wrapping DODEFAULT() with some additional behavior. An easier approach is to put code into the DOQUERY memo field in the reports table; this code is executed as the cursor is created, just before running the report.

What kinds of pre- and post-processing are you thinking of (ideas you have may help us add more hooks).

>8. How about Field Level security perhaps based on a security name (a la VFE)

That's easily handled -- all fields are defined in a field collection, so you simply subclass the field collection and do one of two things: override the IsFieldInSet method (which returns .T. if the current field should be added to the collection) to test for security, or let the FillCollection method (which fills the entire collection with all fields) do its thing and then go through the collection and remove fields the current user isn't allowed to see.

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