Output is not being rendered correctly.
On my laptop, I have LINQpad v7.5.16 (X64) installed as a portable version. I've recently noticed that output in the results window is not being formatted correctly, or often at all.
Running this simple code should show output in the relevant colours:
void Main()
{
Util.WithStyle("This should be in red", $"color: #ff0000;").Dump();
Util.WithStyle("This should be in yellow", $"color: #ffff00;").Dump();
Util.WithStyle("This should be in green", $"color: #00ff00;").Dump();
}
However, on my laptop, it shows the following:
Laptop is Windows 10 21H2 and LINQpad is using the newer Edge / WebView2 rendering engine rather than the older Internet Explorer based engine.
On my main desktop machine (also Windows 10 21H2), I have the exact same version of LINQpad installed (albeit as an actual installed version rather than as a portable version) and the above code works correctly and as expected. I've tried actually installing LINQpad on the laptop using the installer but that hasn't fixed the problem.
Any ideas as to why this occurs?
Comments
Have you customized any styles? (Edit | Preferences > Results, Style sheet for HTML results)
Also, if you right-click the results panel and choose "Inspect" you will be able to see the HTML, which might give you a clue.
I get the same result (with the default style sheet).
It seems to be caused by the space after the colon being encoded.
<span style="color: #ff0000;">This should be in red</span>Removing the space works.
Strangely, the space is not encoded if the color name is used rather than a number, so the following works.
Util.WithStyle("This should be in red", $"color: red;").Dump();@JoeAlbahari I don't have any customized styles set, almost all of my preferences and config are set to default settings (apart from forcing Dark mode theme).
I'm actually getting the exact same problem as stated by @sgmoore above. If I remove the space from between the
color:and the actual hex code and re-run, it starts working correct with coloured text being output. What's even more strange is that if I now re-add the space that was previously removed, it continues to work correctly. Even closing down LINQPad (whilst shelving the query) and re-starting the application, the query remains working correctly. (Possibly some query-specific caching happening?)I've also encounter other strange issues in other LINQPad scripts that I have on this same machine, such as file access failures when shelling out to invoke another executable via a
new Process(). I now realise that this is likely also related to strange character/path encoding issues.I've no idea as to the root cause of this, as both the sample colour rendering script and the other process invocation script work perfectly fine on a different machine.
I think I have discovered the problem which is the 'space' in the original query (which I copied and pasted) is not actually a standard space.
Hex dump shows it as C2 A0 rather than 20.
Which would explain why removing it and replacing by a real space works and why "color: red;" (using a real space) also works.
@sgmoore Hmm. That's really interesting. Thanks for your detective work on this. I think I probably did copy and paste the actual code at some point, probably from something like Notepad++. Moreover the code was probably taken from a git repository that I've cloned when transferring from one machine to another.
And, sure enough, going through my other script that invokes other executables and removing every "space" character and re-typing it, fixes the script so that it works correctly again.
So, it would appear that some application has munged my actual spaces characters (with Hex Code 20) into non-breaking space characters (with Hex Codes C2 A0, which interestingly enough is the UTF-8 representation of a non-breaking space). I'll now have to do some detective work to try to figure out what application that is, but it's fair to say that I think it's not LINQPad's fault (unless there's an argument for LINQPad's editor to interpret a UTF-8 non-breaking space character as an ASCII space).
Thanks again @sgmoore, you've been a really big help!