Unicode chars makes script output into something else

[quote="jon"]The log display is a sub-classed RichEdit control, which doesn't have a 32K limit as far as I know.

However I do think this is probably caused by a bug in the RichEdit control. If you look at Leo's screenshot you can see that after the first appearance of the Asian characters, the font in the control has changed. The second and subsequent "FileName" strings are obviously in a different font to the first one.

When the control is created Opus sets its font to Courier New, but after that we don't change the font at all, so this font change is something the control is doing itself when it sees the Asian characters. If you copy the text out of the log and paste it into WordPad, at least on my system the second font is shown as "nSimSun". So I guess the bug here is that, while it's fine for the control to switch the font, it's not switching it back again afterwards.

I get the same result as Leo in that the backslashes remain as backslashes so my only guess is that either on Windows 10 the "nSimSun" font has a proper backslash character at that codepoint, or it's something the richedit control knows how to do.[/quote]
I tested it just now, and I could get it to print 176KB so it doesn't seem to have that limit, at least now.
I'm not sure what caused it, but when I posted this 32K seemed to be the limit.

Btw, the short script in that post still does the same in 11.15.2 (today it displayed the column-text for 10273 of 17354 files).

Yes, considering it works in W10, its probably been fixed in the later versions.
That bug doesn't really affect me much as I'm just testing my lib with those characters, but I still thought I should report it.