>>George:
>>
>>Can you give me some "thoughts" on what you think consitutes an "object based report" ? You mean like "subclassing" ? (I can't say I've ever heard of a Report Writer that allows subclassing ... unless we're simply talking about events).
>>
>>I ask because I've been working on a VFP "class/wrapper" for Crystal Reports and would appreciate other people's thoughts on the subject.
>
>Gerry,
>
>Sure, be happy to give you some feedback. I'll limit myself, however, to just bare bones stuff. Nothing too fancy.
>
>First, you'd want to be able to sub-class the report and use CREATEOBJECT() to instantiate it.
>
>This would allow you to set common headers, layout, footers, summary band and even columns that could be inherited.
>
>Second, you should be able to add properties.
>
>Now, applying this to my own work, this is what this would allow me to do. I've gotten an application that has a series of reports with 14 different data groupings. For the most part, the columnar data is all the same, as is the summary band. Just having this would allow me to create a parent report class, that I could quickly and easily modify and sub-class to generate these 14 different reports.
>
>Now I haven't touched on things, like say a "BeforePrinting" event that would allow dynamic control over say, Bold or Italic as opposed to Normal or controlling the color. Nor have I touched on the possibility of adding a method to serve as a UDF. The two things I've named would be enough for me.
>
>Is this helpful?

Yes, that helps George. Particularly the "columnar" and "summary" aspects.

I can see where subclasses can be used to affect Groupings, Headings, Footings, etc.

I wasn't sure of how much one was expecting from an "object based report"; but if we say that, at a minimum, the "columns" are the same for each subclass, then the problem is more manageable.

That almost implies that only the "base class" needs to be visual, and the subclasses could all simply be based on "dialog parameters"; yes/no ?

I have written reports in the past that had a dialog that would allow one to (for example):

1) suppress on or more columns
2) select historical, current or both (data)
3) print detail, summary or both
4) select by location, project, client, work order, or any combination there of (and/or)
5) sort by location, project, client, etc (each field is optional and can assume any position in the sort order)
6) the reports who automatically "rotate" and/or change Font size, based on the calculated page width and length.

It was mainly a question of sorting and grouping based on "field position" vs "field names" (and a few macros).

The above reports had no "visual design component"; ie. they were done by hand (each different configuration could have been implemented as a class ... though the number of combination/permutations would have made this impractical). It sort of harkens back to the days when most Financial report writers (eg. Accpac), though powerful, were not designed with a GUI. I do not believe this is a disadvantage when one is dealing mainly with "tabular" reports.

So, George, with particular reference to your 14 reports, would you have found a "non-visual (designed)" Report (Writer) that supported subclassing, events, etc. useful .... Or, would a "visual design surface" still have been mandatory ?

Or put another way, do the majority of reports fall within the "simple columnar" category (which does not require a "visual tool"), or do they generally require a "visual designer" in order to be able to lay out fields.

Or can people live with "two" types of Report Writers ? ... ie.

(1) a "PRG" based object-oriented one geared mainly to "columnar" reporting, and
(2) a less capable "visual designer" based one (for custom layouts).