Setting the Maximum value on a Trackbar to a very large number results in excessive memory usage

• .NET Core Version: 3.0 Preview1
• Have you experienced this same bug with .NET Framework?: Yes

Problem description:
Setting the MaxValue on the Trackbar control to a very high number results in excessive ram usage (in the gigabytes for a very large number).

This appears to be because on initialization of the underlying windows control, the maximum is set before the tick mark frequency, resulting in it initializing excessive amounts of tickmarks, although I do not have the build configuration to verify this theory myself at this time as if I did, I would just verify and submit this as a PR. https://github.com/dotnet/winforms/blob/01eef03d8e0a6630076716b6cb08ed0a9def611a/src/System.Windows.Forms/src/System/Windows/Forms/TrackBar.cs#L893-L894

Actual behavior: Excessive ram is used (multiple gigabytes if compiled in x64)

Expected behavior: A reasonable amount of ram is used (assuming you set tickmarks to a reasonable number).

Minimal repro:
Within a form

TrackBar tb = new TrackBar();
tb.TickFrequency = 0; //Ensure no tickmarks should be drawn
tb.Maximum = 1000000000;
this.Controls.Add(tb);

[RussKie]

Maybe we need to tell the trackbar to repaint after setting the ticks.

If required, this can be done with Invalidate() call.

[JeremyKuhne]

As @RussKie mentioned, there is little chance that Windows will change anything here.

I took a quick look at the sources:

TBM_SETTICFREQ, TBM_SETRANGE, TBM_SETRANGEMIN, and TBM_SETRANGEMAX all set up an array with a DWORD entry for Max - Min - 1. It always reallocates on these messages if TBS_AUTOTICKS is set. The tick frequency has nothing to do with the size of the allocated array.

One could mitigate this slightly by combining MIN/MAX into RANGE, but you are kind of stuck outside of that. We should document that using the auto-tick setting shouldn’t be used with large max values. We can consider adding a feature for “user specified auto-ticks” in our control using the messages.

What I’d suggest is creating a derived control that manually draws and link or put the prototype here. We can look at what that entails and judge whether or not we want to try and merge that behavior in based on complexity and additional user feedback. Updating the docs is much easier and lower maintenance, and probably addresses the situation though.

I had hoped originally that the COMCTL implementation was smarter or gameable, but sadly that doesn’t seem to be the case.