-
Notifications
You must be signed in to change notification settings - Fork 628
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix bug where losing focus removes color; Closes #144; #157
Fix bug where losing focus removes color; Closes #144; #157
Conversation
0430140
to
89f33e7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's an undesirable side-effect that appears to be introduced by this change:
- Type something in the RichEditBox
- Change color of the text
- 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?
This line is responsible for the shifting of the caret position.
What we could try is to restore the caret position to where it was before the color was changed. |
Everything should now work as exspected. |
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! |
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 😅 |
Everything should work now and the code sample are up to date. |
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. |
* Revert PR #157 * Fix samples * Switch default to green
* Revert PR #157 * Fix samples * Switch default to green
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