>>Personally, I'd like to see object based reports. However, it occurs to me that the reason we may not have seen them may be that they can't be implemented without greatly increasing the memory footprint for the resultant applications and/or implemented without breaking existing applications.
>
>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?