One of the little-known "deep" changes that had to be made for _REPORTOUTPUT and a separate REPORTOUTPUT.APP to work at all was in the base class reportlistener code. If you're using REPORTOUTPUT.APP to get your reportlistener and you've built in your FRXs and/or images referenced in your FRXs to your APP/EXE, the base class has to be able to see those images to render the report. Our Xbase code also gets to make an extra "hop" in this unique situation, to a certain extent.

It's not infinitely extensible behavior. If you modularize your application and (say) have a master EXE that hands listener references to a reporting APP/EXE, you're going to run into some limitations, no matter what your design.

As I mentioned in that previous post, this is a fact of Xbase life and not specific to reporting at all, but making Xbase code such an integral, seamless part of the base reporting process really pushes this fact into the forefront of our collective Xbase development consciousness.

You can bring reporting back into alignment with the rest of your Xbase code, in this area, by simply removing REPORTOUTPUT.APP from the equation. I cannot stress enough the fact that REPORTOUTPUT.APP was just a leg up to bridge the two syntaxes (SET REPORTBEHAVIOR 80 and object-assisted 90). Please do remove the extra hop and bring the coordination of APP/EXEs under your direct code by eliminating REPORTOUTPUT.APP; you can get the same functionality by simply pointing _REPORTOUTPUT at frxoutput.PRG instead. The FFC _ReportListener.VCX library is identical to the files used in REPORTOUTPUT.APP, by design. The discussion in the docs that introduces this critical point is in the topic Including Report Files for Distribution. The simple method required to build in the necessary components is identical for all three REPORT*.APPs and is covered in the topic How To: Specify and Distribute ReportBuilder.App.