Hi Bob.

>I hope your not working too slowly.

It's one of those "so many things to do, so little time" issues right now [g]. Currently, we're working really hard to get SFReports done, then I'll be finishing SFQuery 6, then on to SDT 6.

>Gee, I think with SDT, SFQuery and perhaps SFReports then VFE you and Mike will have written more code for my ap than I have. <g>

[rofl]

>Anyway... with SFReports be at or above the level of FF?

FoxFire is a great reporting tool that can create some very complex reports. However, one of the downsides of a feature-rich tool is a steep learning curve for the typical end-user (I think my Dad uses about 0.5% of the feature set of Word [g]). The primary design goal for SFReports was very easy for the end-user to use. That's why we chose a wizard interface -- it leads them through the tasks of running an existing report or designing a new report one step at a time. It also doesn't provide some of the complex report types that FoxFire does, so the user has fewer things to do when they define a new report.

Another design goal was flexibility. SFReports was designed from the ground up in VFP and uses a rich object model. The user interface, data engine, and reporting engine are all separate components that can be individually replaced. For example, you can run a report from, say, a form without using the wizard at all by instantiating the report engine class, setting some properties and calling some methods. You can swap out the data engine so you can report against Access or SQL Server rather than VFP data. Sample forms that come with SFReports show how to do all of this.

So, SFReports and FoxFire are kind of different tools. Although they're both report manager/writers, they have different goals for what they're supposed to accomplish.

Doug