问题
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!
回答1:
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:
private SynchronizationContext m_oSyncContext = SynchronizationContext.Current ?? new SynchronizationContext();
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.
回答2:
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:
- For Forms, force creation of handles after ALL child controls have been added, for the Form itself and any child Controls. I typically continue to do this in the Construct of the Form after the InitializeComponent() call.
- For Controls, force creation of handles after the Control has been constructed and added to it's parent Contol/Form, for the new Control and all its child Controls (if any).
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
来源：https://stackoverflow.com/questions/4375750/what-are-the-side-affects-of-ensuring-every-control-created-has-a-handle-in-net