>This bug is huge as far as I'm concerned. There is a workaround, but it requires applying the "fix" to each and every report which is not practical in many applications. We have hundreds of reports and it would take forever to go through each and every one.

Because you can "hot swap" a report in VFP9 SP2, using the CommandClause.File property of the ReportListener, couldn't you apply the fix to each report as it ran? Not ideal, but could help get around the issue.

Your technique is very clever, there may be a way of accomplishing the same workaround using a custom property on a ReportListener, instead of a report variable. Then no modification of the report would be needed.

I'd like to see it fixed too, but my fear is that everytime the report engine is modified, something else breaks. At least we have a workaround for this problem. If another issue is introduced, we may not have a workaround. I have reverse engineered part of the report engine and it is "cause and effect" to the nth degree. You can't change one thing without effecting many other areas.