RichEditBox adds new line everytime we use SetText

[CesGan]

Describe the bug
Everytime I use SetText(TextSetOptions.FormatRtf, rtftext) it adds a new line at the end.

Steps to reproduce the bug

Steps to reproduce the behavior:

1. Add a RichEditBox control on a UWP app.
2. Create a method to load a rtf file to the controller using the method RichEditBox.Document.SetText(TextSetOptions.FormatRtf, rtfText)
3. Create another method to get the text on rtf format using RichEditBox.Document.GetText(TextSetOptions.FormatRtf, out result) just to see the final result.

Expected behavior
No new line should be added to the document.

Actual behavior
A new line is added at the end.

Examples
Original RTF Document:

{\rtf1\fbidis\ansi\ansicpg1252\deff0\nouicompat\deflang2070{\fonttbl{\f0\fnil\fcharset0 Segoe UI;}{\f1\fnil Segoe UI;}}
{\colortbl ;\red0\green0\blue0;}
{\*\generator Riched20 10.0.18362}\viewkind4\uc1 
\pard\tx720\cf1\f0\fs21 Text with \b no\b0  bullets\f1\lang2057\par
}

RTF Document after using GetText():

{\rtf1\fbidis\ansi\ansicpg1252\deff0\nouicompat\deflang2070{\fonttbl{\f0\fnil\fcharset0 Segoe UI;}{\f1\fnil Segoe UI;}}
{\colortbl ;\red255\green255\blue255;}
{\*\generator Riched20 10.0.18362}\viewkind4\uc1 
\pard\tx720\cf1\f0\fs21 Text with \b no\b0  bullets\f1\lang2057\par

\pard\tx720\par
}

Version Info

Microsoft.NETCore.UniversalWindowsPlatform v.6.2.9
Microsoft.UI.XAML v.2.3.191211002

Windows 10 version:

• May 2019 Update (18362)

Device form factor:

• Desktop

Example Code

App.xaml

<Page
    x:Class="App2.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:local="using:App2"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    Background="{ThemeResource ApplicationPageBackgroundThemeBrush}">

    <StackPanel>
        <Button Content="Load" Click="Button_Click"/>
        <Button Content="Save" Click="Button_Click_1"/>
        <RichEditBox x:Name="editor">
            
        </RichEditBox>
    </StackPanel>
</Page>

App.xaml.cs

    public sealed partial class MainPage : Page
    {
        public MainPage()
        {
            this.InitializeComponent();
        }

        string rtf = @"{\rtf1\fbidis\ansi\ansicpg1252\deff0\nouicompat\deflang2070{\fonttbl{\f0\fnil\fcharset0 Segoe UI;}{\f1\fnil Segoe UI;}}
{\colortbl ;\red0\green0\blue0;}
{\*\generator Riched20 10.0.18362}\viewkind4\uc1 
\pard\tx720\cf1\f0\fs21 Text with \b no\b0  bullets\f1\lang2057\par
}";

        private void Button_Click(object sender, RoutedEventArgs e)
        {
            editor.Document.SetText(Windows.UI.Text.TextSetOptions.FormatRtf, rtf);
        }

        private void Button_Click_1(object sender, RoutedEventArgs e)
        {
            string result;
            editor.Document.GetText(Windows.UI.Text.TextGetOptions.FormatRtf, out result);
        }
    }

[marcelwgn]

This seems like an issue with the RichEditBox control:

https://stackoverflow.com/questions/52689533/duplicating-uwp-richeditbox-content-adds-extra-lines

Maybe this issue should be moved to WinUI repo ?

[stmoy]

Maybe this issue should be moved to WinUI repo ?

Agreed and done.

[sharpninja]

The worst part is that this is done asynchronously and so SetText finishes before the newline is added, so if you are trying to track modified state of your control then it will get updated out of process and you can not authoritatively set a IsDirty flag to false after calling SetText because it may be changed asynchronously, which triggers a TextChanged which then causes your IsDirty tracking to correctly see that the control is dirty. To avoid this behavior, we actually embed a default RTF file in our application that is loaded from a random access stream instead of using SetText to initialize the RichEditBox for a new document.

There is a similar problem with TextBox where setting the Text with CRLF markers in it will asynchronously replace them with CR markers, again dirtying the control.

[ddalp]

@sharpninja let me understand there are two issues, can you confirm?

1. RichEdit should not append EOP after each SetText call and should not fire text changed event. SetText is actually synchronous but TextChanged event is async.
2. RichEdit should not replace CRLF with CR as it's own EOP.

[sharpninja]

@sharpninja let me understand there are two issues, can you confirm?

1. RichEdit should not append EOP after each SetText call and should not fire text changed event. SetText is actually synchronous but TextChanged event is async.
2. RichEdit should not replace CRLF with CR as it's own EOP.

I think these behaviors should apply to all controls. Instead of manipulating the text to be friendly with the renderers, update the renderers to work with the various line-end formats.

[terrycox]

Is there any more current status regarding this issue?

[terrycox]

This works for me: instead of TextSetOptions.FormatRtf, use combined flags:

 var options = TextSetOptions.FormatRtf | TextSetOptions.ApplyRtfDocumentDefaults;
 rtb.Document.SetText(options, rtb.RtfText);

One thing ApplyRtfDocumentDefaults will alter the RTF control data (the defaults) the first time. But no extra EOP.

[ArchieCoder]

Thank you @terrycox for the hack.

I was going crazy that calling this produced a different text2:

RichEditBox.Document.GetText(TextGetOptions.FormatRtf, out string text);
RichEditBox.Document.SetText(TextSetOptions.FormatRtf, text);
RichEditBox.Document.GetText(TextGetOptions.FormatRtf, out var text2);

All these bugs that will probably never fixed are due to the fact that the WinDev team is so busy recreating the new framework/SDK (WinUI - WinAppSDK)

[gwalschlager]

I'm writing an app with the WinUI3 (WinAppSDK) and I can confirm this problem exists there too. The legacy continues.