TRichEdit and GetTextRange only with \r and not \r\n

[PatBir]

Hi, I don't know if someone has already got that problem:
1) a random LPSTR contains \r\n at each end of lines
2) I use that data source string as a text in TRichEdit
3) If I use theGetTextRange(TRange&) on a TRichEdit, each end of line is only with a single \r and not \r\n.
4)GetSelection() too return an index position that I can't compare to my source string LPSTR

So why those two datas are not synchro ?
Is it normal for TRichEdit ?
Is there a mode to change for TRichEdit to use \r\n end of line ?

Thanks.
Pat

[Ognyan Chernokozhev]

I haven't worked that much with RichEdit controls, but I can reproduce the behavior you are experiencing.

I searched the web and have not found much helpful information yet. Something related could be these extended edit control styles: https://learn.microsoft.com/en-us/windows/win32/controls/edit-control-window-extended-styles
But I have not been able to see them have any difference with either normal multiline edit controls or richedit controls.

If the behavior of RichEdit control is to always replace \r\n with just \r, maybe you could do that conversion in your source strings and then use the result for the comparisons?

[Ognyan Chernokozhev]

Some more info: The documentation of RichEdit control states that:

Microsoft Rich Edit 1.0 used CR/LF character combinations for paragraph markers. Microsoft Rich Edit 2.0 used only a carriage return character ('\r'). Microsoft Rich Edit 3.0 uses only a carriage return character but can emulate Microsoft Rich Edit 1.0 in this regard.

but I cannot see how exactly to make RichEdit 3 to emulate the 1.0 behavior.
There is also a SES_USECRLF flag in the list of EM_SETEDITSTYLE flags, but it is marked as "Obsolete. Do not use."

[PatBir]

Thanks Ognyan for that quick answer.
So, I will make the conversion.

[Sebastian Ledesma]

Quick info:

In DOS/Windows the text files use \r\n at the end of each line.
In Linux the only contains \n (and in classic Macs text files used \r).

In Windows the C/C++ runtime library translates the \r\n to \r and viceversa when reading /writing (fgets, fputs, etc), but this only happens if you open the file in text mode.
If you open the file in binary mode you will get the full \r\n (of a Windows generated text file).

I've switched to read/write mode in binary time ago when implemented UNICODE support and removed those caracters in my functions.

So perhaps you can create your own load/save functions to ensure that the file contains the format that you want.