Fix bug where losing focus removes color; Closes #144;

[marcelwgn]

Fixed a bug where losing focus and reentering the RichEditBox with dark theme enabled would remove colors previously applied.

Description

Saved the formatted RTF to a string and reapplied it when the user enters the RichEditBox again.

Motivation and Context

Fixes #144.

How Has This Been Tested?

Tested manually by entering text with different colors, clicking outside of the RichEditBox and reentering it again.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

[YuliKl]

There's an undesirable side-effect that appears to be introduced by this change:

1. Type something in the RichEditBox
2. Change color of the text
3. Note that the caret has moved to the beginning of the text rather than remaining at the end.

@chingucoding, any chance you know what might be causing this and how to fix it?

[marcelwgn]

any chance you know what might be causing this

This line is responsible for the shifting of the caret position.
I assume setting the text "confuses" the RichEditBox since the caret might not be able to be at the same position so instead of trying to restore it, it gets set to the start.

how to fix it?

What we could try is to restore the caret position to where it was before the color was changed.

[marcelwgn]

Everything should now work as exspected.

[YuliKl]

Everything is working great... unless I put focus into the "Enter search text" box. For some reason, clicking on that text box doesn't have the same behavior as clicking on other RichEditBoxes on this page.

And one more request: can you please update the sample code that shows up underneath the "custom editor" to reflect all the code changes you're making? (If it's easier, the sample update can wait until after all the functional code is working correctly.) Thank you!

[marcelwgn]

As it seems now reentering the rich edit box does not restore the colors that were applied before the color was lost :/

Regarding the behavior of the text search box: It seems like setting the background explicetly messes with the restoration of the string, however I have absolutely no idea why.

Having a RichEditBox with text colorization and text search highlight seems way more complicated than anticipated when the app is running using dark theme ...

I will look further into this tomorrow since it is already 2 am here 😅

[marcelwgn]

Everything should work now and the code sample are up to date.
@YuliKl While working on this I wondered if this behavior is actually wanted and makes sense to maintain for component. Since the component essentially resets the style on dark theme everytime it gains focus, maybe the internal behaviour should change. Should we create an issue over at WinUI?

[YuliKl]

@YuliKl While working on this I wondered if this behavior is actually wanted and makes sense to maintain for component. Since the component essentially resets the style on dark theme everytime it gains focus, maybe the internal behaviour should change. Should we create an issue over at WinUI?

I think this WinUI issue captures some of the spirit of the challenges you've noticed. So I don't think a new issue is necessary but definitely chime in on the existing one.