The following was found in Embarcardero RAD Studio 10.2. I have not looked at other versions.
If you have a TRichEdit
on your form that contains existing text (more than 1021 characters), and change the WordWrap
(or any other recreate window) property, then the component will sometimes insert additional blank lines in the middle of your existing text. It appears to depend on where the CR/LF characters land.
To demonstrate the problem, paste the following text into the Lines
property of a TRichEdit
on a form in Delphi:
01xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx78
02xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
03xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
04xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
05xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
06xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
07xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
08xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
09xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
10xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
11x456789012345678901234567890123456789012345678901234567890123456789012345678
12xxxxxxx1xxxxxxxxx2xxxxxxxxx3xxxxxxxxx4xxxxxxxxx5xxxxxxxxx6xxxxxxxxx7xxxxxxxx
13x4567890123456789012345678901234567890123456789012345678901
x
The purpose of the sample text above is to have 1024 characters (counting the CR/LF at the end of the preceding lines) when you get to the last line (the 'x' on its own). What comes after does not matter.
Now, with the above text in your TRichEdit
, and still in design mode, toggle the WordWrap
property a few times. (The same thing should happen if you set up your form to do it at runtime.) If your Delphi does the same as mine, the last line (the 'x' on its own) will start to separate from the earlier lines as new lines are inserted.
If you change the length of the 13th line - add or remove just one character - the problem seems to go away.
I say "seems to go away" because the 1022/1023 position for CR/LF is not the only sensitive positions. I found more further on (when playing with larger text), but not always on the 1k borders (I think, not studied in detail).
I found the problem with WordWrap
, but it happens with any of the properties that recreate the window handle (I think) - certainly BorderStyle
does the same thing.
Has anyone else seen this? Is it too much to ask if someone could try the above test in Delphi 10.3 to see if it's fixed?
Probably the only reliable fix (if 10.3 doesn't fix it) is to avoid using TRichEdit
, or - and this is my next step for testing the problem - to create and use a derivation that inserts code to save and restore content during handle recreation. Any other ideas?
UPDATE At runtime the problem only happens if the PlainText
property is true. At designtime it happens whether that property is true or not.