我有一个基于多个嵌套的中等复杂度的布局TableLayoutPanels。调整窗体大小会导致更深嵌套表内的控件在视觉上滞后于调整大小。首先，这使得它们看起来像是在调整表单大小时四处移动，但更糟糕的是，当它们滞后到足以离开分配的表格单元格时，控件的边缘明显被剪切。
有什么办法可以防止这种情况还是这是最好的TableLayoutPanel can do?
Edit：在尝试了很多程序之后，我得出的结论是，调整大小时的滞后是一个普遍存在的问题。在我看来，似乎每个人都已经接受了这是不可避免的 and 可以接受。当然如果真的是这样的话不可避免的 then 接受这样就容易多了:)
查看您最喜欢的“良好 UI”程序中的滞后的最简单方法：通过按住左边界并观察所有右对齐控件跳转来调整其大小（或者，顶部边界和底部对齐控件，例如状态栏）。四周都坏了。
如果有人能提供充分的理由来解释为什么在使用本机 Windows 控件时这是不可避免的，我会接受这个答案。另外，如果您发现一个使用本机控件的程序不会遇到此问题，请说出来，这可能会有所帮助......
Windows 中本机控件的问题在于每个控件都负责绘制自身，这意味着将位图绘制到屏幕上。当容器控件中的每个控件调整大小时，它所占据的窗口区域将变得无效，因此不仅容器中的每个控件要重新绘制，容器本身也必须重新绘制。此外，调整大小/重绘事件都发生在 UI 线程上，因此它是单线程操作。
自 16 位 Windows 引入以来，本机窗口绘制背后的基本机制一直没有改变。
人们使用许多技巧来尝试解决这个问题，例如双缓冲、离屏渲染或简单地禁用调整大小。
要了解它应该是什么样子，请查看 WPF。 MS 开发它是为了解决这个问题。
如果 WPF 不是一个选项并且您使用的是 Windows 窗体，请查看layout http://msdn.microsoft.com/en-us/library/system.windows.forms.control.layout.aspx微软的相关文档。您可以实现自己的布局引擎，而不是依赖开箱即用的微软产品。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
