什么编程实践影响窗口句柄的数量？

概述什么编程实践影响窗口句柄的数量？

我得到运行时错误“错误创build窗口句柄”。 从我的研究中，我知道这个错误通常表明一个应用程序已经超过了windows的10,000个句柄限制，我应该通过确保句柄不被不必要地创build并妥善处置来解决错误。

但是，我无法find任何有关创build窗口句柄的文档。 每次我实例化一个窗体时创build一个窗口句柄？ 每次我实例化一个控件？ 每次我实例化一个类？ 或者是什么？

对于轻型UI应用来说，是不是应该特别关心所使用的句柄的数量，而对于具有许多graphics元素的应用程序，程序员必须采取措施来限制窗口句柄的数量？ 那“无窗控制”和“轻量级控制”是关于什么的？ 还有其他相关的概念我应该知道吗？

到现在为止，我还没有想到我的应用程序特别是UI密集型。 但是，它确实显示了一个图表网格，其中每个图表是由多个组件控件组成的用户控件。 对于大型分析，控制的总数可能会达到成千上万。 假设我想保留这个网格，有什么具体的技术可以用来保持处理倒计数？ 例如，有没有办法“渲染”一个控件，使其仍然可见，但不再需要窗口句柄？

UNIX和windows开发之间的区别

C＃ – 如何获得鼠标点击命令行EXE不使用WINFORM

持续集成是否消除了对大型Visual Studio解决scheme的需求？

C＃/。NET定时器和Win32睡眠function都是不精确的

获取每个用户的SpecialFolder.Mydocuments文件夹

-TC

C＃中的“Movefile”function（重启后删除文件）

支持阿拉伯字符从右到左

使用POST将安全数据从.NET发送到linux服务器？

使用windows用户帐户凭证login

任何人都可以解释WMI到旧的SNMP章？

但是，我无法找到任何有关创建窗口句柄的文档。

这可能是因为.net是一个抽象。

在Win32的“真实”世界中，一个窗口句柄由类型HWND表示，几乎被赋予所有的东西。 每个按钮，菜单等都可以有一个HWND 。

事实上，这不是真的。 您可以创建的对象的每个类 （在C windows API中）都有一个句柄。 每个类通常只绘制整个控件 – 但是，一些控件可能会绘制更复杂的控件，如额外的按钮。 要么他们可以创建另一个窗口（控制），或者他们可以使用GDI来绘制它。

所以，不是你看到的所有东西都会产生一个HWND – 但是大多数情况都是这样

有趣的是，你可能想知道在C / Win32中使用CreateWindow()创建一个控件。 一切都是一个窗口 。

所以现在回到你的.net APP。 如果您所依赖的控件通过基础的CreateWindow调用创建大量对象，那么您将发出大量的HWND变量，并最终耗尽唯一的标识符。

马克Russinovich涵盖了他推动windows的限制 ，他故意试图用尽他的应用程序的分配的实际限制。

那么什么编程实践导致了这个？ 创建太多的窗口对象。 这在应用程序窗口的意义上可能不符合实际的windows – 而是对应于控件的数量。 避免这种情况的唯一方法是少用一些，或者如果第三方根据您可以一次显示的实际限制来设计您的应用程序，那么这个问题就会被设计出来。

另一种方法是产生你自己的控制，而不是使用子控制来代替它们。 但是，这可能是很多工作。

简而言之，窗口句柄被赋予每个交互式的UI元素。 每个真实的窗口，每个文本框，网格单元格，按钮，菜单等等。 尽管非交互式控件不需要窗口句柄，但如果编写不正确，它们仍可能使用它们。

通常很难达到窗口限制。 如果发生这种情况，并且您的应用程序不是特别用户界面密集型的，通常意味着您正在泄漏手柄 如果您使用的书写不好的可视化组件库时，会发生这种情况，因为它不应该释放资源。 窗口句柄是一个非托管资源，当不再需要时，必须小心地释放它。 如果你碰巧使用一个库，并观察处理泄漏，最好是改变图书馆。 它通常比听起来难，所以作为一个坏的解决办法，你可以尝试强制垃圾收集器收集对象，并希望所有非托管资源在终结器/析构函数中释放。

GC.Collect();

不能保证这会有帮助，因为如果你正在使用的控件写得不好，他们可能不会释放手柄，即使在他们的终结者。 再次，这是不好的做法，但如果你没有其他选择，可能会有所帮助。

如果只使用标准的.NET控件，请确保在使用后Close()每个表单，而不是隐藏它。 这将处理一个非对话形式和所有的控制，如果他们是标准的控制，将不会泄漏。 对话框表单需要用代码处理。 详细的文档在这里 。

总结

以上是内存溢出为你收集整理的什么编程实践影响窗口句柄的数量？全部内容，希望文章能够帮你解决什么编程实践影响窗口句柄的数量？所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。