Items disappear from the ListView when the user scrolls up/down

[SergeySmirnov-Akvelon]

.NET Core Version:

• 3.0

Have you experienced this same bug with .NET Framework?:

• No

Repro steps:

1. Create a ListView in virtual mode with 1 million items (or use NET5 project from VirtualListView.zip).
2. Add Application.SetHighDpiMode(HighDpiMode.SystemAware) line to Program.cs
3. Start scrolling up/down

Actual behavior: Items disappear:

Expected behavior: Items should be displayed

[kirsan31]

• No (looks like a regression after Allow set application-wide default font #4911)

I'm worried how it can be if target is NET5 and application-wide default font is NET6 feature?

[RussKie]

I've removed the ref to #4911, since the issue is reported against .NET 5, and the default font feature is introduced in .NET 6.0 Preview 5.

[SergeySmirnov-Akvelon]

Hi @RussKie, @dreddy-work. I have investigated this issue again and found that it started to reproduce in .NET Core 3.0. One of the conditions for the reproduction of the bug is the next line: Application.SetHighDpiMode(HighDpiMode.SystemAware)

Unfortunately, during the first investigation, I did not know that the presence of the code above is an important condition. During testing .NET Framework 4.8, I removed this line as it was not supported. And during testing .NET Core 3.0 and .NET Core 3.1, I used the code from .NET Framework 4.8, and as a result, this bug was not reproduced there either.

[dreddy-work]

Thanks @SergeySmirnov-Akvelon for the update. When need to find why adding Application.SetHighDpiMode(HighDpiMode.SystemAware) is causing this. Did you see any first chance exceptions in your investigation?

[SergeySmirnov-Akvelon]

Hi @dreddy-work. No. When I investigated the bug for the first time, I made a mistake when clarifying the affect version, so I was trying to find a commit where we could potentially break it. It turned out that in the commit I found above, we added Application.SetHighDpiMode(HighDpiMode.PerMonitorV2); a method to the WinformsControlsTest project. This is the reason why the bug started to reproduce in the test application, but it is not the reason of the bug.

[kirsan31]

All a bit more complicated ( or simple )?

1. Another prerequisite for reproduction is that the system's DPI should be more than 100. On 100% DPI all work fine.
2. If your make net4 app DPI aware:

   <System.Windows.Forms.ApplicationConfigurationSection>
   <add key="DpiAwareness" value="true" />
   </System.Windows.Forms.ApplicationConfigurationSection>

   and change font of the app to system font like this:

public Form1()
{
    Font = SystemFonts.MessageBoxFont;
    InitializeComponent();
...
}

then this issue will repro even on net472:

https://user-images.githubusercontent.com/17767561/128871299-b3201c0a-19cb-4f48-9534-8c3cc9096a4d.mp4

So, strictly speaking this is not a regression, this is DPI scaling problem that exist even in net framework, but become more easy discoverable in .Net due to default font change.

@dreddy-work your can safely add this to area: HDPI ;)

[dreddy-work]

Thanks @kirsan31 for the details. Removed regression tag and slated for next release.