[Bug] Text line beyond 12,078-th line become invisible

[qqkookie]

trafficstars

Describe the bug Text in the lines beyond 12,078-th line become invisible line.

To Reproduce

• Start Notepads App. Turn off word wrap option.
• Open text file with more than 13,000 lines.
• Go to 12,100-th line
• The lines beyond 12,078th line are invisible to the end of file. Text on the invisible lines is not lost, but just become invisible.

Expected behavior The text of lines beyond 12,078 should be visible.

Screenshots

Desktop (please complete the following information):

• OS: Windows 11 (22H2 OS Build 25357.1) [Version 10.0.25357.1]
• Version : v1.4.9.0 from MS Store.

Additional context

• I experimented with small file (about 30K text with 15,000 line), same result.
• This bug has nothing to do with text file size or individual line length.
• The text data in the invisible lines are preserved. Total number of lines is correct to the end of file. Invisible texts on the invisible lines can be successfully selected and copied to other editor.( See screenshot above) The text data in invisible lines are preserved when saved as file. Just text become invisible.
• The last visible line is always12,078-th line if word wrap is off, regardless of file size, line length or text contents. But if word wrap for long line is turned on and reducing editor window width, the last visible line number can be smaller like 10,583-th line. (variable)
• You can see some garbled characters in 12,078 line in screenshot.

[FrozenAssassine]

This issue seems to be related to a problem with the RichEditBox itself rather than Notepads.

The underlying problem lies with the ScrollViewer in the RichEditBox, which has a maximum content length limitation. When this length is reached, the RichEditBox displays invisible lines.

For a more detailed explanation, I recommend checking out this StackOverflow answer: https://stackoverflow.com/questions/44608549/uwp-textbox-maximum-lines-limitation

[qqkookie]

This issue seems to be related to a problem with the RichEditBox itself rather than Notepads.

The underlying problem lies with the ScrollViewer in the RichEditBox, which has a maximum content length limitation. When this length is reached, the RichEditBox displays invisible lines.

For a more detailed explanation, I recommend checking out this StackOverflow answer: https://stackoverflow.com/questions/44608549/uwp-textbox-maximum-lines-limitation

I have tested very simple text editor (a DIY-Notepad clone)[https://github.com/qqkookie/XPAccApps/tree/master/notepad] with RichEdit control ("Msftedit.dll") It is multi-tabbed and has vertical scrollbar, but without horizontal scroll bar or line number column. It does not have such line limit problem and display text beyond the 13,000 lines without invisible line or performance problem. It does not use any special workaround to avoid the 13,000 lines limit. So, it is not fundamental limit of RichEdit control itself. There may be some workaround to avoid using the culprit, ScrollViewer control.

[FrozenAssassine]

Yes, you are correct. This is not a limit of the RichEditBox itself, but rather the scroll viewer. Both UWP and WinUI platforms share the same problem, with their textbox/RichEditBox being slow due to this. The only workaround I have currently found here was to create a textbox from scratch. The new Notepad in Windows 11 also does not use the UWP/WinUI textbox. I believe they are also utilizing the textbox from Msftedit.dll. However, as far as I know, there is no official and easy way of hosting Win32 controls in a UWP app.

[0x7c13]

More to add:

It is not about 13,000 lines issue, it is about the virtual drawing canvas size limit set in the RickEdit/ScrollViewer component in WinRT. If you change text to a smaller font, it can fit more than 13,000 lines. But you got the idea.

You can blame MSFT, but since no one cares about UWP or Windows app development anymore so there is no urgent need for improving it anyway.

I wish I could use an internal build of the latest RichEdit control that Windows Notepad uses to make it better but sadly it is closed source (for a reason).