Thanks for your feedback. I am always in favor of simpler solutions but I can't always see them. :-D

I'll have to think through your suggestion. Another complicating factor that I realized after I posted my original message is that each line item has a comment field that may be blank (in which case the line doesn't print) or may be a big huge memo.

I was just getting into using a report variable to sum the txtwidth(memo) + some factor for chr(13)'s to figure out how big each detail actually is. Not simple for sure!

Some had previsously suggested (was it you?) printing one report at a time (to get the terms and conditions with each PO). Maybe that approach would help here as well. The purchase order is something customers can be particular about and it would be wise to design to allow flexibility--printing one at a time gives that.

I just walked down the hall to talk with the buyer--she doesn't need variable length comments on the line item--two lines will be the most she ever uses--so I think I can see the light at the end of the tunnel. Thanks again!

>I'm not claiming that this solution is better for performance, or anything but ease of maintenance. I find it better to do complicated setup work in the code which calls the report form, and keep the report form as simple as possible. (I hate debugging someone else's report when there are complicated formulas hidden in report variables and so forth.)
>
>That said, if it were my problem, I'd try setting up the cursor that the report runs from so that there are enough blank records inserted into P.O. detail to give the correct size for that area in each P.O. Then you still have a fairly "normal" looking detail band which just has Qty, Descr, Price, and Total (or whatever you do specifically) on a single line, with an numbers set to show spaces rather than zeroes. And of course you put a single line under the single items in this simple detail band.
>
>Of course, there may be better solutions!
>
>HTH,
>Rich.
>
>>The customer wants the band that prints their purchase order line items to always be the same height, irregardless of the number of line items.
>>
>>They also want vertical separator lines that run through the line item "box" and connect the header and footer boxes.
>>
>>Here's the approach I'm going to try. Any alternative suggestions are most welcome:
>>1. Define a report variable to count the number of line items.
>>2. Call a UDF in the detail band On Exit expression and pass the line count and another variable by reference.
>>3. In a text box in a footer below the detail band put a text box that streches. Bind it to the second parameter in step 2. Add vertical lines that strech to fill the footer band.
>>4. The UDF will load the second parameter with the number of carraige return characters required to pad the "detail" section to the constant height.
>>
>>TIA.
>>
>>Frustrated in LA,