以下是在 Embarcardero RAD Studio 10.2 中找到的。我没有看过其他版本。
如果您TRichEdit的表单上有一个包含现有文本（超过 1021 个字符），并更改WordWrap（或任何其他重新创建窗口）属性，则组件有时会在现有文本的中间插入额外的空白行。它似乎取决于 CR/LF 字符的位置。
为了演示该问题，请将以下文本粘贴到Delphi 中窗体Lines的 a 属性中：TRichEdit
01xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx78
02xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
03xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
04xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
05xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
06xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
07xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
08xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
09xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
10xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
11x456789012345678901234567890123456789012345678901234567890123456789012345678
12xxxxxxx1xxxxxxxxx2xxxxxxxxx3xxxxxxxxx4xxxxxxxxx5xxxxxxxxx6xxxxxxxxx7xxxxxxxx
13x4567890123456789012345678901234567890123456789012345678901
x
上面示例文本的目的是在您到达最后一行（“x”本身）时有 1024 个字符（计算前几行末尾的 CR/LF）。之后发生的事情并不重要。
现在，在您的 中使用上述文本TRichEdit，并且仍处于设计模式，切换WordWrap属性几次。（如果您将表单设置为在运行时执行，也会发生同样的事情。）如果您的 Delphi 和我的一样，最后一行（“x”本身）将开始与前面的行分开作为新行行被插入。
如果您更改第 13 行的长度 - 添加或删除一个字符 - 问题似乎消失了。
我说“似乎消失了”，因为 CR/LF 的 1022/1023 位置不是唯一的敏感位置。我发现了更多（在玩更大的文本时），但并不总是在 1k 边界上（我认为，没有详细研究）。
我发现了问题WordWrap，但它发生在任何重新创建窗口句柄的属性上（我认为）——当然BorderStyle也有同样的作用。
有没有其他人看过这个？是否有人可以在 Delphi 10.3 中尝试上述测试以查看它是否已修复，这是否太过分了？
可能唯一可靠的修复（如果 10.3 没有修复它）是避免使用TRichEdit，或者 - 这是我测试问题的下一步 - 创建和使用插入代码的派生，以在句柄重新创建期间保存和恢复内容。还有其他想法吗？
更新在运行时，只有当PlainText属性为真时才会出现问题。在设计时，无论该属性是否为真都会发生。