I am well aware of the need for page breaks. I am also aware of the fact that the ReportListener does not handle them correctly for HTML output. [...]
The reports look great except for the page break issue of which Management immediately complained about. They want it fixed yesterday and you are suggesting that I pour through all the VFP docs (which I have), all the source code, and write a paper on how to handle an issue which, in my opinion, is a bug in the first place?

Well, you don't have to write a paper about it if you don't want to, Jeff. But if I were to put some effort into working up a solution to making an HTML ReportListener class handle page breaks a different way, I'd want to publish the results.

When Management sees an issue like this, they say: "Fix it. Don't use VFP for HTML reports. Buy a third party product if you have to." And we don't want that, do we.

If VFP9 isn't producing the HTML output you need by default, then you have all the tools you need (more than anyone should reasonably expect, in my opinion) to do the necessary work yourself to get it into the desired form.

Or, as Dan suggests, go the 3rd party route. XFRX is an excellent product, and VFP9 by no means renders these 3rd party products irrelevant or unnecessary.

Don't get me wrong. I think all the new reporting features for VFP9 are awesome and we want to use them extensively for MANY things.

However, this page break issue really bugs me because, well, it shouldn't be a complex issue.

I think it is complicated.

(It's maybe less complicated if you can make some assumptions about the kinds of reports that you'll be processing, but of course the VFP9 product can't do that, as I explained previously.)

- Colin