Hi Sergey,

Thanks for your help. I've been experimenting with Cetin's code, and his code will sometimes add an extra line or two to the end of an "autosized" editbox. The number of extra lines is dependent on the font, fontsize, and editbox width. I've been looking at fontmetric results of the bad font/fontsize scenarios and haven't seen any patterns.

I'm testing on XP SP2, VFP 8 SP 1 on a 1024x768 small font display so I don't think there's anything funky about my setup.

Any other suggestions?

Thank you!
Malcolm

>
>Take a look at Re: Determine number of rows of text in an edit box? Thread #988886 Message #989141
>
>
>>VFP 8, 9: I've been trying to create an autosizing editbox - in other words an editbox that adjusts its height so that it shows the full contents of its Value without the need for a scrollbar and without showing any unnecessary blank lines. The reason I'm looking for an autosizing editbox (and not a label) is that I have text to display that may be longer than the 254 char limit of a label's caption. I also want the user to be able to highlight text within this control for copy to the clipboard.
>>
>>I've tried 3 approaches to calculate the vertical space required to display a wordwrapped line of text:
>>
>>- Win32 API DrawText()/CreateFont()
>>
>>- VFP's old "?" output command in conjunction with fontmetric() and row()
>>
>>- Manually parsing the text to be displayed and using fontmetric(), textwidth() to calculate word/line breaks and manually calculating text height
>>
>>All 3 of the above techniques produce IDENTICAL text height results. Unfortunately, the VFP editbox uses a "mysterious" word wrapping algorithm that wraps text slightly differently than the above techniques.
>>
>>So, is there anyway using the native VFP editbox that I can determine how many lines it needs to fully display a block of text without using scrollbars? Or is there some property I can set that will make the editbox wrap text consistent with one of the above techniques for calculating text height?
>>