>>Well, I AM doing it all - it defaults to your global font settings (try the VPasns and try out changing the fonts, and look at what Alert() displays look like), and I AM using the TxtWidth method of this form (though not word by word - I'm using MemLines() and Mline() function to chop it into lines), it's just the number of lines in the editbox getting near to unpredictable if you try to determine its height calculating from its number of lines, so I either end up with last line getting chopped off, or having too many blank lines at the bottom.
>>
>>I think the next incarnation of Alert() will use an array of textboxes, one per line. At least, it will be easier to control.
>
>I still think the only way that would work is the word-by-word approach to determine line length so you can get a more accurate number of lines. The MLINES function doesn't take into account the font size when determining lines, it's merely looking for the # of characters (MEMOWIDTH) or a < CR > character to determine a new line.

Ummm... I wasn't too clear in the first reply. I don't mind using the number of characters instead of pixel width - chopping it into lines with MLine() has the advantage of respecting the embedded CRs in the message string - and I chop it first, and then measure the lengths in pixels. It also doesn't matter if one line is longer than another - it's not a right justified text, it's just a replacement for a message box. I've just had this problem that I used a read only editbox to display the message, and it's size was pretty (ugly?) unpredictable.

BTW, I've made it in the meantime, using an array of labels, and it works (and looks) much nicer - margins are easier to calculate, works fine with any font name/size combination I tried it with. I'll post it here in Files as soon as I translate comments into English and supply some demonstration prg. And... as soon as I learn how's the new way of uploading actually working.