---
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?

[...]

---


Heavens, no, we wouldn't suggest that you pour through the docs, although the HTML Listener docs are extremely clear on this point.

But if you want to be an expert, and if you expect Management to think you are an expert, then you have new things to learn <s>. If HTML is critical to your users, and if you are interested in their priorities, roll up your sleeves.



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

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.

---



It *isn't* a bug and it *is* a complex issue. And I personally have no problem with your using a third-party product, I don't know why you would think otherwise. In fact XFRX (mentioned on this thread) is capable of making great use of the XML output, same as HTML Listener does, for important new capabilities in the product. You can do that too. What you've been given is an opportunity, not a final answer to everything.

You can get whatever type of HTML output you really want out of the XML, but it is not something that can be done the same way for every-report-there-is.

>L<