Word break in a richedit box

[zapper222]

Visual Studio 2013 Community Edition on windows 7 Ultimate.
Dialog app with two rich edit boxes. The boxes are set to auto vertical scroll true, horizontal auto scroll false.
I am attempting to read from one rich edit box one line at a time and print these lines out to the second rich edit box, one line at a time.
I am using the following code to read the line:

CString Line1;
int nLineLength = 0;

nLineLength = m_RichEditVar.LineLength(1);
m_RichEditVar.GetLine(1, Line1.GetBufferSetLength(nLineLength + 1), nLineLength);

The problem is that LineLength() includes some word wrap characters that are put into the text when it is typed into the first rich edit box. When this line is printed out in the second box, these characters show up. The characters are '\uCDCD' and I tried to use CString::Find to trim the line length that way but Find couldn't locate the characters.

Anyone have any idea how to read or print the line without showing these characters?

[VladimirF]

According to https://msdn.microsoft.com/en-us/library/z0z83tcz.aspx
" nMaxLength
Maximum number of characters that can be copied into lpszBuffer. The second form of GetLine places this value into the first word of the buffer specified by lpszBuffer."

Also, why do you think that '\uCDCD' is "some word wrap characters"?

[zapper222]

That link is not working for me.

I have no difficulty in copying the line, its just that the extra "control" characters show up when I write the line to the second richedit box.
I copied one of the characters from the richedit box into the code to use CString.Find() and thats what the compiler identified it as.

[VladimirF]

I've fixed the link, please try it again.
How do you place that line into the second box?
Please note that Visual Studio writes 0xCD bytes into uninitialized memory - could it be that you are seeing those bytes?

[2kaud]

From your code snippet in post #1, you don't seem to be null terminating the returned string or obtaining the line index. Try

CString Line1;
int nLineLength = 0;

nLineLength = m_RichEditVar.LineLength(m_RichEditVar.LineIndex(i));
m_RichEditVar.GetLine(1, Line1.GetBufferSetLength(nLineLength + 1), nLineLength);
Line1.SetAt(nLineLength, _T('\0')); // null terminate
Line1.ReleaseBuffer(nLineLength + 1);

[zapper222]

Yes I am terminating the string and popping the buffer, I just didn't show it, my bad.
For what its worth, its a unicode project if maybe that has something to do with it.
Here is the code I am using:

CString Line1, Line2;
int nLineLength = 0;

//Get the length of the second line
nLineLength = m_RichEditVar.LineLength(1);
//Get the text from the second line
m_RichEditVar.GetLine(1, Line2.GetBufferSetLength(nLineLength + 1), nLineLength);
//Terminate the string
Line2.SetAt(nLineLength, _T('\0'));
Line2.ReleaseBuffer(nLineLength + 1);

//Print out line to second box
m_RichEdit2Var.SetWindowTextW(Line2);

I posted a pic of what I end up with.

[VladimirF]

Yes I am terminating the string and popping the buffer, I just didn't show it, my bad.
For what its worth, its a unicode project if maybe that has something to do with it.
Here is the code I am using:

Is that the EXACT code that you are using?
1. CString's GetBufferSetLength() *will* place 0xCDCD into allocated buffer in DEBUG build.
2. Your code works for me in UNICODE project.
3. Your manipulation with CString's internal buffer are not as suggested by MSDN:
- If you pass the string's length to ReleaseBuffer() - you don't need to place the terminating 0 yourself;
- if you *do* add that 0 - you should pass -1 as a length.
4. Your symptoms indicate that the terminating 0 was placed too far (passed the end of the string). Could you do additional debugging?
- what is the string length returned by m_RichEditVar.LineLength(1);
- if you look at the CString's internal buffer in the debugger's Memory window at the time you put that terminating 0 and release the buffer - do you see the 0 being written? In the correct place?

[2kaud]

3. Your manipulation with CString's internal buffer are not as suggested by MSDN:
- If you pass the string's length to ReleaseBuffer() - you don't need to place the terminating 0 yourself;
- if you *do* add that 0 - you should pass -1 as a length.

The OP code in post #6 is based upon an example from MSDN. See https://msdn.microsoft.com/en-us/lib...vs.100%29.aspx

[VladimirF]

The OP code in post #6 is based upon an example from MSDN. See https://msdn.microsoft.com/en-us/lib...vs.100%29.aspx

So what does it say about MS documentation?
Haven't you been a part of MS Doc discussion here today already?

[VictorN]

So what does it say about MS documentation?
Haven't you been a part of MS Doc discussion here today already?

Good catch!

[zapper222]

Thanks for your help on this guys!

I ran it thru the debugger and the line length came in at 44 and the CString Line2 was showing the text AND the weird characters. I noticed though that the return value coming from GetLine was showing the correct value of 40.
So as a work around I used that value to terminate the string and that got rid of the weird characters.

@Vlad
Yes that is the exact code I am using.
I am modifying the font when the dialog initiates, that could be the reason I am getting the strange results?

m_RichEditFont->CreateFontW(20, 0, 0, 0, FW_BOLD, true, false,
		0, ANSI_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY,
		FIXED_PITCH | FF_MODERN, _T("Courier New"));
m_RichEditVar.SetFont(m_RichEditFont);

I did do an attempt though without the font change and got the same incorrect results.

[VladimirF]

I ran it thru the debugger and the line length came in at 44 and the CString Line2 was showing the text AND the weird characters. I noticed though that the return value coming from GetLine was showing the correct value of 40.
So as a work around I used that value to terminate the string and that got rid of the weird characters.

@Vlad
Yes that is the exact code I am using.

Wait! Who shows 40 and who - 44? And when?
In your code:

nLineLength = m_RichEditVar.LineLength(1);

is nLineLength 40 or 44? (I've counted 40 characters in your second line, including trailing space).
The GetBufferSetLength() will allocate *AT LEAST* nLineLength + 1 bytes (may be more), filling them with 0xCD. So right after

m_RichEditVar.GetLine(1, Line2.GetBufferSetLength(nLineLength + 1), nLineLength);

you would see those "strage" characters after your text. BUT they should be trimmed by your next line of code:

Line2.SetAt(nLineLength, _T('\0'));

Is that where you still see them?

I am modifying the font when the dialog initiates, that could be the reason I am getting the strange results?

Font should make no difference, except for the number of characters that fit in the line.

[zapper222]

nLineLength from this line equals 44.

nLineLength = m_RichEditVar.LineLength(1);

The return value from this line returns 40:

m_RichEditVar.GetLine(1, Line2.GetBufferSetLength(nLineLength + 1), nLineLength);

[VladimirF]

nLineLength from this line equals 44.

nLineLength = m_RichEditVar.LineLength(1);

See CRichEditCtrl::LineLength():

nLine

Specifies the character index of a character in the line whose length is to be retrieved.

The character # 1 is in the first line, and its length is 44.

Later on that page:

Remarks

Use the LineIndex member function to retrieve a character index for a given line number within this CRichEditCtrl object.

[zapper222]

In the LineLength link you provided, it says:

When LineLength is called for a multiple-line edit control, the return value is the length (in bytes) of the line specified by nLine.

My RichEdit box is multi line....shouldn't LineLength return the length of the line?