Home/ Questions/Q 7042127
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T02:07:50+00:00

I use this function to get a line of text from a rich edit

  • 0

I use this function to get a line of text from a rich edit control. 

CString RichEditCtrlEx::getLine(int charIndex) const
{
CString retval;

int lineIndex = LineFromChar(charIndex);
ASSERT(lineIndex>=0 && lineIndex<GetLineCount());
int sizeOfLine = LineLength(charIndex);

TCHAR* buffer = new TCHAR[sizeOfLine + 148];

ASSERT(buffer);

if (buffer) {

    memset(buffer,0,sizeOfLine + 148);
    *((int *)buffer) = sizeOfLine;

    GetLine(lineIndex, buffer);
    retval = buffer;
    delete[] buffer;
}

return retval;  
}

The function GetLine:

_AFXWIN_INLINE int CEdit::GetLine(_In_ int nIndex, _Out_ LPTSTR lpszBuffer) const
{ ASSERT(::IsWindow(m_hWnd)); return (int)::SendMessage(m_hWnd, EM_GETLINE, nIndex, (LPARAM)lpszBuffer);

For the most part it works perfectly. However if the text in the rich edit control contains special characters (e.g. “拿듬壴竒” ) the characters which are returned are wrong (when using the characters in the example the result is “ÿìôÒ”)

Does the EM_GETLINE message allow these special characters? Or do I need a different approach?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Could you give an example of text for which your code works? The example text you give for failure indicates that the upper 8 bits of the characters is getting zeroed out.

    拿 (U+62FF) -> ÿ (U+00FF)
듬 (U+B4EC) -> ì (U+00EC)
壴 (U+58F4) -> ô (U+00F4)
竒 (U+7AD2) -> Ò (U+00D2)

    If the text that your code ‘works’ for is all in the range U+0000 to U+00FF (which covers characters used in the Americas and Western Europe) then you wouldn’t notice a problem even if you’re doing something wrong. This would indicate that this is probably not a problem with getting text from the control, but instead a problem with something your program does with the text elsewhere.

    Assuming your program defines the UNICODE macros then TCHAR is wchar_t, which is two bytes on Windows. Make sure you’re not mistakenly treating it as a one byte char anywhere, because that could easly truncate the character values the way you describe. Jim Rhodes already pointed out one area where you’re not taking this into account.

    • 0