End of longest lines cut off horizontally

[jorgebv]

The readme mentions an issue with long lines but I'm not sure I'm hitting that GDI issue.

The end of the longest visible line always has a few characters cut off. If I let a longer line be visible (via disabling filters), then the scrollbar will extend to match the width and I'll get to read the end of my interesting line. If I hide the line numbers, I get a little closer to seeing the end of the line, but am still missing a character or two.

I had used an older TextAnalysisTool release in the past without issue, so I went through the releases to find a version that worked for me. Version 2016-01-08 displays the full lines, but 2016-06-16 begins having the issue.

[DavidAnson]

Is there an example file (maybe on GitHub) we can try?

[jorgebv]

Sure. This gist has three lines: https://gist.github.com/jorgebv/f8f224d1f0eb7e2d4e32c1173365463e The lines begin with 123, 456, and 789 respectively.

When I open the file, I can see the end of line 1 and 2, but not line 3 (too long). If I create and enable a filter for "123", I can't see the end of the first line anymore. If I create and enable a filter for "456", I can see the end of the first line, but not the second. If I create and enable a filter for "789", I can see the end of the first and second lines, but not the third.

In version Version 2016-01-08 I can see the end of all lines regardless of filters.

[vincec-msft]

First, nice report. Thanks for the details.

Sadly, this does not repro for me so we need a little more info.

Does this happen on more than one machine? Do you have a high dpi screen or some other setting that might be different between your machine and others?

[jorgebv]

I hadn't really tried anything other than my work machine, but just tried it on my personal machines as well.

Work machine with 1920x1200 monitor: repros Personal machine 1 with 1080p monitor connected: repros Personal machine 1 with 1600x900 laptop screen: repros Personal machine 2 with 1920x1200 monitor: repros

I don't generally do fancy things with my monitors or machines so I'm stumped as to why it doesn't repro for you. If I think of anything or manage to coax another result from any of my machines I'll update here.

[vincec-msft]

I’ll poke at it, too. Thanks.

[DavidAnson]

Do you maybe run Windows at 150 or 200% using the first example here: https://support.microsoft.com/en-us/help/4028566/windows-10-change-the-size-of-text

Is your default language or font non-Latin (ex: Chinese, Japanese, Arabic)?

[vincec-msft]

I got a repro on an old version. Narrowing things down.

[jorgebv]

My font settings are default 100% and my only language is English on all machines.

I have a couple other machines with clean installations of recent Windows 10 insider builds with no settings changes that also reproduced the issue.

Machine 3 with 1680x1050 monitor Machine 4 with 2560x1440 laptop screen. This one probably does qualify as high DPI and the recommended/default font scaling on this one is 150%. But it exhibits the same symptoms as the rest.

I find it interesting that it repro'd on a different version for you vincec, but I'm glad you were able to repro.

[vincec-msft]

MeasureString is underreporting the size needed to render the line so we set the listbox's HorizontalExtent too small.

This is related to the font size. I can repro this if my font is Consolas 9pt, but not if I set the font to Consolas 9.25pt. For some reason one of my machines was using 9.25pt so I couldn't repro but another was using 9pt so I could repro.

This does relate to the GDI and font size weirdness noted in the readme.

As a work-around you can adjust the font size to be 0.25pt larger. I'll fight with these APIs a little more.

[jorgebv]

I see. I had assumed that the GDI rendering issues had more to do with some kind of max length limit, so I thought I was hitting something else. I'm not much of a C# guy, but a few searches for MeasureString related problems do certainly make it seem like a non-trivial and annoying problem.

Thanks for the workaround. I had tried a few different font size, but I must have gotten unlucky with the ones I tried.

The default on all my downloaded versions seems to be courier new 8pt (though, when I go in the preferences and reset the defaults, it goes to 10pt). When I look at the "working" 2016-01-08 version, it does appear to have a different font size. But, since it doesn't have the preferences, I can't tell exactly what it is. If the issue can't reasonably be addressed, perhaps the default font size and/or family can be changed to one that happens to work a litter more nicely?

[x-projs]

Maybe we can use a little bigger font size when we invoke MeasureString(), change

graphics.MeasureString(text, this.Font)

to

graphics.MeasureString(text, new Font(this.Font.FontFamily, this.Font.Size + 0.25)).

[DavidAnson]

This should be fixed in the 2020-12-17 release (thanks, Vince Curley!).