我有一个包含System.Windows.Forms.TrackBar控制。我被它的最大值设置为〜200,000,000。当我这样做，控制所需的内存800MB。减少至2,000,000使用存储器的更合理量的最大值。

  // trackBar.Maximum = 210554060; //所使用的内存〜800MB
trackBar.Maximum = 1000000; //使用少量的内存
 

这是在Windows控制一个错误？还是我要求的TrackBar做一些不合理的？

更新： 我创建了一个新的Windows窗体项目，不过在窗体上的TrackBar。我的最大值设置为200,000,000。我设置了TickFrequency和变化，以便有没有数以百万计的刻度，改变步骤。

当我这样做，应用程序使用了800MB内存。我使用的.NET Framework 4。

。

更新 我发现这个问题的解释有点：http://www.tech-archive.net/Archive/DotNet/microsoft.public.dotnet.framework.windowsforms.controls/2006-12/msg00015.html

添加链接测试项目 https://www.dropbox.com/s/nh6jsymw05feoqn/testingTrackbar.zip?m

这是在Windows控制一个错误？

是的，我想你可以称之为一个错误。在64位操作系统与平台目标设置为值为anycpu特别讨厌的，所以没有合理上限的内存分配。我的机器完全死了交换的死亡与鼠标和按Ctrl + Alt + Del键反应迟钝，我硬启动它找回来。谢谢你。

实际上是两个错误。它开始与本地滑块控件没有把一个合理的上限对蜱的数量。您可以通过正确的顺序分配的属性生存，在设计模式。但它是通过在的TrackBar类包装缺陷复合，前的分配最大属性的初始化时，在​​运行时的本地控制的TickFrequency财产。因此，对于一个短暂的瞬间它仍然有一个极大蜱。那么，它是不是介绍它时为2十亿人，像我不知不觉尝试。

这没有简单的解决这个错误是不会得到修复。用合理的值，你可以随时通过乘法映射。

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.