It's not unusual for a framework to wrap the REPORT FORM command, but it *is* unusual for the developer of the framework not to have exposed clauses .

You always have to find some room to make room for this. My preference is for the wrapper to allow at least one item that is "unknown by the framework", macro-ized in the REPORT FORM command, so that the user of the wrapper can shoehorn anything necessary in using that item.

For example, if I remember correctly, the _output class in FFC does this via the .cScope property.

_reportListener has something that serves the same purpose (you add reports to a collection via the addReport method, and it internally keeps track of the report names, the clauses you want, and the listeners you want to attach, to each report in the collection).

>L<