确保创建的每个控件在 .NET 中都有句柄会产生哪些副作用？
过去，我遇到过冻结问题，这是由于在为该控件创建句柄之前使用该控件对 UI 线程上的调用进行编组而导致的。 （有关详细信息，请参阅Kim Greenlee 的博客）。
使用这种方法（递归实现），我确保在应用程序中创建的所有控件在构造时都有句柄。具体来说，这是在设计者调用初始化控件的 GUI 之后完成的。
我的问题是：
问 - 除了性能之外，是否还有其他原因不确保所有控件都以这种方式具有句柄？
我问这个问题是因为我们遇到了放置在基础设施面板内的基础设施控件的问题。当用户修改此面板的大小时，所包含的 Infragistics 控件的大小不会正确调整大小，即使它的 Dock 属性设置为 Dock.Fill。还有一个问题是，此控件中出现的工具提示不再显示在鼠标旁边。如果容器和包含控件都不能确保它们具有为自己及其所有子控件创建的句柄，那么这两个问题都可以得到解决。
我希望这里有人能够回答我的问题。为任何能够解释为什么我也可能会看到这个问题的人提供布朗尼积分！ =) 但我认为这个问题更适合 Infragistics 团队。
干杯!
In the past, I've suffered from a freezing issue that was the result of a Control being used to marshall calls on the UI thread before a handle has been created for that control. (See Kim Greenlee's blog for more info).
Using this method - implemented recursively - I ensure all controls that are created in our application have handles when they are constructed. Specifically, this is done after the designer call to initialise the GUI for the control.
My question is:
Q - Aside from performance, are there any other reasons not to ensure all controls have handles in this way?
I ask as we're experiencing an issue with an Infragistics control which is placed inside and Infragistics Panel. When the user modifies the size of this panel the size of the contained Infragistics control does not resize correctly even though it's Dock property is set to Dock.Fill. There is also an issue by which the tooltips that appear in this Control are no longer displayed next to the mouse. Both these issues are resolved if both the container and containing controls do not ensure they have handles created for themselves and all their child controls.
I hope someone here will be able to answer my question. Brownie points for anyone who can shed some light on to why I may be seeing this issue too! =) But I think this question would be more for the Infragistics team.
Cheers!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您在自己的代码中编组时是否遇到这些问题，或者是否在某些外部代码上发生过？
我也遇到过几次这些问题，并转而使用 SynchronizationContext 类。此类的明确优点是您不需要任何控件来在线程之间进行编组。
您需要在要调用的线程（即 UI 线程）上获取该类的实例，如下所示：
使用此实例，您可以使用任何线程中的 Post/Send 方法来 (a) 同步向该线程发送消息检索该实例的位置。
这样做的缺点是您必须确保在正确的线程上检索实例，我建议像上面的示例一样进行操作。如果您在当前实例已经存在的情况下创建实例，则可能会产生一些令人讨厌的副作用。
Did you have these issues while marshalling in your own code or did it occur on some external code?
I had these issues a couple of times too and switched to using the SynchronizationContext class. Definite pro for this class is you don't need any controls to marshal between threads.
You need to get an instance for the class on the thread you want to be called (ie the UI thread) like this:
Using this instance you can use the Post/Send methods from any thread to (a)synchronously send messages to the thread on which that instance was retrieved.
Drawback of this is you have to make sure you retrieve the instance on the correct thread and I would recommend doing it just like above sample. If you create an instance while there's already a current instance you can get some nasty side effects.
好的，我已经解决了我遇到的具体问题。这不是基础设施组件的问题。我只是在错误的时间强制创建句柄...
我在每个自定义控件/窗体的构造中强制创建句柄 - 在 InitializeComponent() 调用之后。这对于表单来说很好，但是在此阶段控件很可能尚未放置在父控件/表单中。当 Control 没有父级来“保留”它时，强制创建句柄显然是不好的。
因此，我将实现此操作的经验法则更改为：
因此，我认为如果您确保正确使用此功能，唯一的缺点是潜在的性能问题（老实说我还没有真正注意到）。
我欢迎对使用此功能的缺点进行正式描述，并欢迎对如何在将控件放入其父控件之前强制创建控件句柄会导致问题进行更技术性的描述，因为我的描述有点简短。 。
罗
Okay, I've solved the specific issue I was having. It was not an issue with the Infragistics components. I was simply forcing the creation of the handles at the incorrect time...
I was forcing the handle creating in the construct of each custom Control/Form - after the InitializeComponent() call. This is fine for Forms, but a Control will most likely not have been placed in a parent Control/Form by this stage. It is obviously bad to be forcing the creation of a handle when the Control has no parent to "hold on" to it.
So I've changed my rule of thumb for implementing this to:
So I presume if you ensure you use this functionality correctly, the only drawback is a potential performance issue (which I haven't really noticed to be honest).
I'd welcome a formal description of the cons of using this functionality, and a more technical description of how forcing the creation of handles for a Control before it is placed in it's parent Control causes problems, as my description is a bit brief...
Roo