The output of the XML is designed to give you what you need, and what other formats besides Excel need, by providing the full content of the original report.

How you translate that full and descriptive XML into the target XML depends on the target.

In this case, your target is Excel. That means you have two choices:

1) Export to Excel's Office-dialect XML

2) Export to HTML, which Excel can read.

Both can be done the same way (using XSLT). Obviously, HTMLListener is using this approach already.

The HTML that HTMLListener produces is not well tuned for Excel consumption, it's designed to be as much like the original printed page as possible in a browser. However it wouldn't be hard to create HTML that is more appropriate to Excel if you wanted.

If you take the approach that you want to go from VFP-Report XML to Excel, without using HTML, that is certainly possible as well.

Either way, I'm not sure how generic the result would be. It would certainly be easy to do for simple reports. But the issue is how intelligently you can take a complex report (with potentially-overlaid items, and items staggered in terms of their columnar positions, not to mention staggered in terms of their row positions, as some items float below others that stretch while others do not float because they're off to the side...) and move it into a simple, tabular format.

The point is, once you made the decisions about how you wanted to handle such issues, what limits you would set on what you could handle, etc, the appropriate data is sitting there in the VFP XML to give you the results you want. Everything "known", in terms of the data output and the original report layout from the FRX, is there.

>L<