确保创建的每个控件在.NET中都有句柄的副作用是什么? [英] What are the side-affects of ensuring every control created has a handle in .NET?

查看:56
本文介绍了确保创建的每个控件在.NET中都有句柄的副作用是什么?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

过去,我遇到了一个冻结问题,这是由于在为控件创建句柄之前,该控件被用于编组UI线程上的调用的结果.(有关详细信息,请参见金格林利的博客).

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

使用此方法-递归实现-确保在我们的应用程序中创建的所有控件在构造时都具有句柄.具体来说,这是在设计人员调用以初始化控件的GUI之后完成的.

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.

我的问题是:

Q-除了性能,还有其他原因不能确保所有控件都具有这种方式的句柄吗?

Q - Aside from performance, are there any other reasons not to ensure all controls have handles in this way?

我问,是因为我们在Infragistics面板和Infragistics Panel中放置了一个Infragistics控件时遇到了问题.当用户修改此面板的大小时,所包含的Infragistics控件的大小即使将其Dock属性设置为Dock.Fill也无法正确调整大小.还存在一个问题,该控件中显示的工具提示不再显示在鼠标旁边.如果容器和包含控件都不能确保它们具有为自己及其所有子控件创建的句柄,则可以解决这两个问题.

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.

我希望这里的人能够回答我的问题.布朗尼(Brownie)指出了任何可以阐明为什么我也可能看到此问题的人!=)但是我认为对于Infragistics团队来说,这个问题会更多.

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.

干杯!

推荐答案

在编组自己的代码时是否遇到了这些问题?还是在某些外部代码上发生了这些问题?

Did you have these issues while marshalling in your own code or did it occur on some external code?

我也遇到过几次这些问题,并切换到使用SynchronizationContext类.此类的肯定专家是,您不需要任何控件在线程之间进行封送.

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.

您需要像这样在要调用的线程(即UI线程)上获取类的实例:

You need to get an instance for the class on the thread you want to be called (ie the UI thread) like this:

private SynchronizationContext m_oSyncContext = SynchronizationContext.Current ?? new SynchronizationContext();

使用该实例,您可以在任何线程中使用Post/Send方法,以(a)将消息同步发送到检索该实例的线程.

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.

这篇关于确保创建的每个控件在.NET中都有句柄的副作用是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆