It is not "Object Oriented". It is "Object Assisted". Here's what this means:


* -- the report engine itself is not an object and the layout controls on a report design layout are not objects; but

* -- the rendering code for output has been moved into an object. Which, yes you can subclass, inherit from, and do all kinds of stuff that you want to do with other objects.

* -- the report engine defers to the reportListener object throughout the report output process, from before-the-beginning until after-the-end. As a result you have an opportunity to use a reportlistener or other helper objects of your choice to, yes, make the changes you want as you go and to re-use this code from report to report.

So far, we're talking about code you write yourself, subclassing a new baseclass, that uses thoroughly OO syntax and design/architecture to enable reporting enhancements.

* -- the report engine also defers to an Xbase piece for previewing. So, when we're talking about this particular part of the output process, you have the opportunity to use standard Fox classes, subclass, embellish and inherit, as you're used to doing with other forms and toolbars (or whatever).

But your opportunities to associate objects with a report form go beyond the attachment of reportlistener and reportpreview objects to the REPORT FORM command to support additional needs to attach objects to the non-object elements stored in an FRX <s>.

Some such additional helper objects will occur to you naturally. for example you might want to use a DataEnvironment object used for other VFP scenarios in a report or you might want to use a textbox object to inform your report layout of its formatting requirements.

At design time there is ReportBuilder support for including "template objects" in the FRX (through a reporting variant of the memberdata XML schema). The shipping ReportBuilder only makes use of this in the DE scenario but you can make use of these template classes at both design and runtime.

This part is "object ASSISTANCE" not object BASEd or object ORIENTed, because, yes, the layout controls are still not objects and the DE records in an FRX are still not a DE object and associated cursor and relation objects.

They are *templated* from objects, and at both runtime and design time you have the opportunity to trigger methods of the real objects to make changes in the templated objects. Your opportunities to do so are different, depending on whether we're talking design or run time, and they are also different, depending on what type of objects you're interested in -- but they're pretty darn wide and deep <g>.

HTH,

>L<