System.Windows.Forms.TrackBar memory use with a large maximum value

Question

I have a control that contains a System.Windows.Forms.TrackBar. I was setting its maximum value to ~200,000,000. When I did this, the control required 800MB of memory. Reducing the maximum value to 2,000,000 used a more reasonable amount of memory.

//trackBar.Maximum = 210554060;  // uses ~800MB of memory
trackBar.Maximum = 1000000;      // uses a small amount of memory

Is this a bug in the Windows control? Or am I asking the trackbar to do something unreasonable?

Update: I've created a new Windows Form project with nothing but a trackbar on the form. I set the maximum value to 200,000,000. I set the TickFrequency and changes so that there are not millions of ticks and change steps.

When I do this, the application uses over 800MB of memory. I am using .NET Framework 4.

.

Update I found somewhat of an explanation for this problem: http://www.tech-archive.net/Archive/DotNet/microsoft.public.dotnet.framework.windowsforms.controls/2006-12/msg00015.html

Adding link to test project https://www.dropbox.com/s/nh6jsymw05feoqn/testingTrackbar.zip?m

Answer 1

Is this a bug in the Windows control?

Yes, I think you can call that a bug. Particularly nasty on a 64-bit operating system with the platform target set to AnyCPU so there's no reasonable upper-bound on the memory allocation. My machine completely died a swapping death with mouse and Ctrl+Alt+Del unresponsive, I hard-booted it to get it back. Thanks.

Two bugs actually. It starts with the native track bar control not putting a reasonable upper limit on the number of ticks. You can survive that in design mode by assigning the properties in the right order. But it is compounded by a flaw in the TrackBar class wrapper, it assigns the Maximum property before the TickFrequency property when it initializes the native control at runtime. So for a brief moment it still has a gazillion ticks. Well, it is not brief when it is 2 billion of them, like I unwittingly tried.

No simple fix for this and this bug isn't going to get fixed. Use reasonable values, you can always map them by multiplication.