I was saying that you could easily subclass DebugListener to do what you need, because it has only one method (with one "verbose" switch) that you need to handle to provide output for all events, so that's the only place you would need to add a line of code doing the timing.

However, you will do just as well using something like this:

SET COVERAGE TO x.log
REPORT FORM ? ;
  OBJECT NEWOBJECT("debuglistener",HOME()+ "ffc\_reportlistener")
DO (_COVERAGE)
* now set Coverage to show you profiling times...

Since DebugListener implements EvaluateContents, that's really good enough -- use the coverage log results to analyze what happens.


What you *can't* see using DebugListener is how much faster a report with *no* EvaluateContents code is.

You could easily write something similar to DebugListener that *didn'* implement EvaluateContents and AdjustObjectSize. Then compare the results of the two listeners against the same reports.

That's the critical thing. Remember that the time differentials between one report and another report with EvaluateContents are quite different. It's not just that "report listeners without EvaluateContents are faster than those that don't have code in EvaluateContents".

The primary factors will be:

• how many text boxes does it have to be called for?
  
• most significantly, how long are the strings? It will be a lot slower for stretching memo fields than small, label-like expressions.
  

You will not see explicit timing results published (or shouldn't), because they will misleading. But you *will* see something similar to information above included in the docs so you can run your own tests <s>.

Meanwhile, my own impression is: in your situation, it's fine to use EvaluateContents. You can still go the GDI+ route if you want much greater control of the results, though!

In general, labels instead of expressions don't buy you much of anything, especially now that you can add DesignTime Captions to make Expressions look friendlier for end-users in Protected mode!

>L<