Maybe Fabio will see this thread and jump in. He's solely responsible for current and future enhancements to the class as, being an MS employee, it's difficult for me to support and maintain freeware.

That being said, initially, figuring out the Word calls was not that hard. I had just worked on a contract management app and I had Word automation pretty down. Duplicating the sometimes quirky behavior of the report engine and figuring out how everything works in the FRX was a bitch (I have an article in the Aug 2000 issue of FoxTalk about how the FRX's work for further info).

Fortunately, Markus Egger had figured out a LOT of what was in the FRX when he worked on GenRepoX and was kind enough to have his FRX notes on his website. This gave me a huge headstart and simplified the test matrix to figure out the remaining undocumented FRX stuff.

What Fabio did, though, was to turbocharge the Word stuff by doing some brilliant use of templates and global settings; work that he continues to refine.


>
>It's really a generous & brilliant thing you & Fabio have done.
>
>I understand your desire to render a native report as precisely as possible & I think it makes a lot of sense. However by aptly restructuring the code, it would be easy to retain the functionality that it has -- of rendering a report just as it would be in in VFP -- while adding the subreport capability.
>
>The important thing is to split the code into 3 methods:
>
>1. OpenDoc() would create & setup the Word document & performance enhancing defaults.
>
>2. InsertReport() opens the frx, sets up a new private datasession if required by the frx, and inserts a report into the doc. The trick is, InsertReport calls itself recursively (1 level only I suppose) when it comes across, say, a caption "%frx2Word% SUBREPORT=whatever.FRX DETAIL=invoices". InsertReport also closes the datasession it opened and returns to the datasession, alias & record it left off at so as to be a well-behaved recursive thingie.
>
>3. CloseDoc() would close the document and restore defaults.
>
>All these methods called by ReportForm of course, which itself gets to be rather empty.
>
>...This restructuring wouldn't affect the formatting at all for a report that doesn't put in a magic caption. But when I tried to restructure the code this way I realized how much work you two did to figure out all the calls to Word, not to mention interpreting the frx! And I realized how long, how very long, it would take me to catch up...