I have a Unicode rich edit control v4 (based on MSFTEDIT.DLL). I'm using WTL, which I don't believe is interfering. The test OS is Vista x64. The application is 32-bit Unicode.
All text is added programatically, and the control is read only. The user gets to pick the fonts used for inserted text, and those fonts can vary across the text. I add text via combinations such as:
SetSel(length,length) i.e. EM_SETSEL
SetSelectionCharFormat(SCF_SELECTION,format) i.e. EM_SETCHARFORMAT
ReplaceSel(text) i.e. EM_REPLACESEL
The CHARFORMAT2W structure I'm using is first zeroed and then properly filled out, a la:
format.cbSize = sizeof(CHARRFORMAT2W)
format.dwMask = CFM_FACE|CFM_BACKCOLOR|CFM_COLOR|CFM_SIZE
format.szFaceName = L"Courier New"
format.crTextColor = RGB(255,0,0)
format.crBackColor = RGB(0,0,0)
format.yHeight = 12 * 20
I have a default font set on the control. For the purposes of demonstrating the bug, it's set to be Courier New, 80 point.
Formatting, insertion etc. works perfectly well, as expected. The following is the oddity: if I insert just spaces into the control using the above method, and if the default font is larger than their selected font, the line with spaces appears with the height of the default font, not their selected font (so they're 80 point not 12). However, as soon as I add non-space characters to the control after the spaces, the spaces revert to the correct formatting.
The same is true of trailing whitespace; if I insert non-space characters, a carriage return, then spaces, their line height is 80 point. As soon as I append non-space characters, straight back to 12 point.
I can verify using EM_GETCHARFORMAT that the characters do in their have the correct format. They're just not using it.
My workaround is to set the default font to be one pixel high. Then the user can set the fonts we use to whatever height they like, and this effect doesn't manifest.
Still, why does this occur, and how do I prevent it sensibly? The visual height of lines is very important in this application.