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
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.