To change the formatting you really should make the thing an expression rather than a label, then.

You could also go the GDI+ route if you wanted, IOW just put shapes on the report where you wanted the labels to be and draw them yourself. You'd have *lots* of flexibility in formatting that way -- and if you don't need to change the size you don't need to do it in EvaluateContents or AdjustObjectSize -- you can do it in Render.

You can get some general timing information from UpdateListener, the little guy that does the progress bar for preview and print. Obviously the display of the bar is going to add in -- as is just about anything you would add to attempt to capture the times -- but as long as UpdateListener was going to be capturing some of this information it seemed reasonable to have it stick around after the run.

You could also get more interesting timings by adapting something like DebugListener to give it to you. Plus, for the first time, you can actually use coverage logs with reports <g>. You've got times there if you want them.

But, are you asking this question because of what I said about EvaluateContents? No, there isn't anything in the way of hard and fast rules I can give you about this but there will be a lot of explanation of how it works in the docs, and that will help. As a general statement: for short text, such as labels, EvaluateContents isn't such a big hit (and AdjustObjectSize isn't much of one at all. But you have to remember that the base class won't call these methods at all if there is no code in them, it investigates this at the beginning of the run. And this can be a substantial savings.

>L<