Hi lisa and colin,

First of all, I'd like to thank you both for the very informative demonstration in Arnhem about the new report writer. Without it it would have take much more time to figure it out, by just reading the help. It was unfortunate I had to leave early because of private circumstances, so I don't know what was discussed after I've left. And I felt it would have been usefull to actually do some examples ourselves, but the time ran out unfortunately.

There was not enough time to dicuss some matters, so I thought maybe through the UT would be a good place to discuss those.

Since I've been using VFP (as succesor of FPW and FPD) I've not use the VFP report writer a lot. I did do quite a lot of it in FPW 2.6, even with hacking the FRX for adding and deleteing objects at runtime. In VFP I quickly discovered Crystal Reports and do all my reporting in there for most of my products. Now with VFP9 I have to reconsider my standpoint on what to use in what cases. So I want to get a comprehensive picture of both products' characteristics.

VFP9.
It became clear to me that about the whole builder part is written in xBase code and can be replaced by your own. This is esspecially usefull for us dutch which are able to translate all dialogs related to VFP reporting. The protection features are also very usefull in situations where you allow users to make certain changes, but want to protect the report to changes that might ruin the idea of the report itself. The cusomizability of also the report preview and output to XML, HTML and potentially all outputs are stunning. Also the usage of GDI functions to directly draw on the report surface is powerfull, but not something the everage VFP programmer would do very often I'd think. In fact those enhancements make it possible to create your own application specific reportwriter. Your classes really look to me like an example of a report writer framework, and your implementation was really powerfull and comprehensive.

Of course this was not possible of MS did not give us the powerfull hooks into the events throught the reportlistener. There is virtually nothing that prevents use to use this as a base to build our own reportwriter framework on it.

So far all credits to you, colin and the VFP team for the enhancements.

However if I look at the reportengine itself (Design view), the only stunning thing I could remember was the usage of mutliple detail bands. Of course the use of multiple language fonts is important for a few of us, but most of use don't have much use of that.

And though I've asked you the question directly, I did not get a clear answer. Why was choosen for multiple detail band as oposed to subreports found in Crystal Reports? Is this because of complexity? or was there another reason? IOW, is it usefull to ask this in a feature request to VFP10 or not. Subreports have an advantage that they might be present in any band of the report, so even within a detail or grouping band that might be handy for certain one to many relations.

Then I did ask the question about dynamical grouping. This is a thing I practise within crystal reports frequently. While the preview has been loaded you can change the grouping and get a different presentation of the same data, where summarizations are recalculated. You said that this was possible since FP1, but this is not quite true though, that though you can base groupings on expressions or variables, you'll have to take care of the ordering of the data in that case. You'll have to provide some code ubloading the current preview, sorting the data and repreview the report. In crystal Reports that is taken care of rather automatically.

I recognize that this might be fully possible as the preview window is not anymore bound to the report itself, but just graphical output. IOW you can still show the preview while you modify the report itself. So when you change the grouping, you can change the FRX (or better, a copy of it) to change the grouping field or set other variables, change the ordering of the cursor which drives the report, rerun it and display the new output to reflect the changes.

VFP9's reportwriter still seems to use one pass mechanism. Unlike in Crystal Reports it is not possible to place summaries of a group in the group header. In your demonstration you used the first band to pre calculate data for use in subsequent bands. Though certainly a usefull strategy, it still seems like a kludge for overcomming a 'one pass' stragey and is becomming increasingly complex when allowing the dynamic grouping as described before.

One thing that definately would be a wish for VFP10 is the integration of charts. What is reporting of large amounts of data without the use of (complex) charts?

Crystal Reports
Crystal reports is one of the leading report writers currently out there. It is a very flexible report writer that can be integrated in a lot of developement environments through a variaty of methods. It also allows you to create web based report.

In VFP you'd integrate this with the RDC com object and the ActiveX CrViewer. The activeX is placed on a form which you can then use as a preview form.

Crystal Reports cannot run on VFP data directly but you can use (amongst others) XML, OLEDB, or FOX2X tables. Personally I use FOX2X tables. As I said you can use subreports in any band of the report writer. There are many features you won't find within VFP9:
- A Group tree
- SubReports (which eleminates the need of multiple bands)
- Charts directly bound to the data on the report
- Summarizing data of a group on the group header (because of multipass)
- Cross tabs
- Maps
- Native exports to a large number of formats (e.g. word, Excell, Pdf, Html, etc) and applications
- Export the report file with its contents to a new report (usefull as use as a document)
- Many objects can be formated dynamically depending on expressions.
- Formatting of objects tends to be far more flexible and easy than with the VFP report writer.
- Multiple horizontal pages (caused by cross tabs)
- Use as a web report system

Though an impressive lists, there are also some very significant disadvantages:
- Initial purchasing costs (developer edition)
- A lot of DLLS that have to be installed on the workstation
- CR 10 (and probably all later versions) does only run on Win2K and WinXP. Win9X is not supported unless you use CR9 and earlier.
- You'll have invest quite a bit of time to create your classes to implement it in VFP and to fit your needs
- For letting the users create their own reports within your applications each user has to pay for an additional license.
- It does not handle with VFP data directly (see above)
- The dialogs are in english and are opposed to a VFP9 solution not modifyable. If you want to create a dutch or modified version, you're out of luck.
- For some type of reports it seems to be slower (because of multipass), though for simple reports it does not have to be that way, and I'm wondering what all the xBase code in the VFP9 report classes does to performance as well.
- Hanlding pictures in general fields, binary memos and blobs are not supported. You can implement hanlding pictures by storing a path to the picture, but this is not an easy thing to do and requires subclassing the format event.



Anything to add ? correct ?

Thanks,

Walter,