Reports Information : Other report functions : Enabling objects for reporting
Enabling objects for reporting
If you have other iterable objects that are not derived from Stream, SequenceableCollection, or one of the QueryResultTable classes, you can enable them for reporting by implementing the following protocol.
To implement the protocol successfully, the object must have the following behavior:
Have an attribute that represents the current object in the iteration
Be able to iterate through its contents from an initial state, when iteration will make the first object in the collection the current object
Be able to indicate when iteration is complete
Be capable of resetting its iteration to the initial state
This behavior must be exposed to the Report Iterator by implementing the following instance methods:
Returns a DirectedMessage indicating which object can perform the iteration, which message should be sent to cause the current object to advance to the next object, and which parameters should be passed. The return value of the step message should indicate whether or not the iteration was successful, that is, whether or not there was another object available.
Returns a DirectedMessage describing which object can reset the receiver's iteration, which message should be sent to reset iteration, and which parameters should be passed. The return value of the reset message should indicate whether or not the reset was successful. The reset message will be sent before each report is viewed, previewed, or printed to make sure that all iteration starts again from the beginning.
The following class methods should be implemented to assist quick reporting:
Returns the name of the attribute that is the current feature. This feature will be used to set the body fields of a quick report. The attribute of this feature will be presented in the list of attributes when creating a quick report.
Returns true if the class can be iterated in a report or false if it cannot. This method decides whether a Report Form or Report Iterator should be created when a quick report is requested. If a class implements abtStepMessage, then it is assumed that the class is iterable. If a class returns another object as the recipient of its step message, and is not iterable itself, then it should override abtIsIterable to return false. OrderedCollection, for example, is not directly iterable. It returns a stream as the receiver of abtStepMessage. OrderedCollection, therefore, overrides abtIsIterable to return false.
You can see the VA Smalltalk implementations of these protocols in the PositionableStream class in AbtRunPartsApp or in the Collection classes in AbtRunReportApp. If you have a database feature installed, see the implementation in AbtQueryResultTable in AbtRunDatabaseQueryPartApp.
Last modified date: 01/29/2015