>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<
Sure, you and I know that's how a framework is _supposed_ to work. Try and convince this developer of that. Almost every framework I've seen starts with giving you all VFP has to offer, and tries to wrap various functionality to make it more usable. This guy takes the approach that "you can only do what I give you tools for". It really gets frustrating. Anyway, I don't work on this project nearly as much as I used to, and when I get the new external report functionality working, I won't be limited at all.
