You cannot call invoke or BeginInvoke on a control until the window handle is created

Close a form today and report an error like "You cannot call invoke or BeginInvoke on a control until the window handle is created." "This doesn't have to be a lot of thinking, it must be that place is not released."
Since we have encountered this problem, we should not say the problem itself, but say something else.
WinForm most common is the DataGridView this control, regardless of rewriting or how, a lot of data operation is to use DataGridView to show, therefore, its asynchronous call is also a more of the class.
Like what:
1 reading large amounts of data from the database (so-called paged reads are not in this category)
2 Operation DataGridView, then change or fill after a period of time Dtagridview
3 DataGridView Some of its own effects, such as rotation delay wait, or other
There is no need to be asynchronous there will be a panic situation, with the asynchronous may also need to pay attention to some situations

A simple example:
A ShowDialog form has a DataGridView, I read the data asynchronously, but I did not read, I closed the form, when the data read, to execute
Datagridview.source=??
At this point, it will be an error, perhaps not. Invoke or BeginInvoke cannot be called on the control until the window handle is created. "This error, but" resources have been released and so on ", let's look at the following methods.
1 This.components This property

<summary>//         Required designer variable.        null;  
Every Designer.cs has this thing, IContainer interface is equivalent to a container, a page All things will be placed in the inside, you drag a button or label will be placed inside, I think this is actually a concept of a container of WPF, You can find every control from root, and IContainer can find the control you want, either active or inactive.
Form is released and components are released

        ///<summary>///Clean up any resources being used.///</summary>///<param name= "disposing" >True if managed resources should be disposed; otherwise, false.</param>ProtectedOverridevoid Dispose (bool disposing) {if (disposing && (components = null)) {components. Dispose (); } base This method is released, so it can be used as a basis for determining whether a form is released, but the author does not recommend 
 2 this. Isdisposed 
 This is a decision whether it has been released, it is better to use this judgment than the components, the specific reason is that components may not be released after the form is closed, and this. The isdisposed form must have been released when the form is in mid mode, because of a thread or other reason, the closing of the form may not release 
 
 3 ishandlecreated 
 Handle is created 
 when the subspace handle is created, Other problems arise if the handle to its parent has not been created or has been freed for other reasons, so this can be done by parent.ishandlecereated to check whether the parent handle exists or has created 
 
 that can be combined with several methods. I judge the time almost with the latter two 
 now talk about these two Invoke and BeginInvoke 
 Control.Invoke: On the thread that owns this control, execute the delegate in FIFO order 
 Control.BeginInvoke: The asynchronous execution of the delegate on owning this control thread, which is probably not sequential, is a bit familiar, and it seems that the 
 
 finally says the workaround: 
 at Invoke (...) Before adding 1 This.components==null 2 this. Isdisposed 3 ishandlecreated to return do not execute invoke can, of course, just what I have encountered for the resolution, may not be suitable for other, but always do not leave the 
    

 set {if (isdisposed | |! this. parent.ishandlecreated) returnthis. Invoke ((system.action) delegate () {});    

You cannot call invoke or BeginInvoke on a control until the window handle is created