Traps for closures in C #

In recent projects, I encapsulated a component of an asynchronous execution program. The function of this component is to do some time-consuming background operations (such as the database to read data, or some statistical calculation in the background) do not block the UI, and then play a circle of animation to tell the user is performing background operations. The DoWork method contains three parameters, the first two of which are delegate types, which are time-consuming operations and callback callback after the operation is completed. The third parameter is the pop-up wait animation next to the prompt message, similar to "Looking for data, please later ..." "Text, which is set by the caller. The method code probably looks like this:

 Public Static void string message)        {           //Todo:method body        }

Because this component is designed to be independent of any other form, that is, the component is a separate window instead of being inserted into another form as a control. Any other call in the window is called directly to the static method to pop up a wait window before the calling window, and the call is not blocked anywhere. So the question is, how do I know which window or control is calling in this method? My approach is to use the target property of Doworker to get the currently called window, assign it to the owner of the component, and set the start position of the component to the center of owner. The code is as follows:

this. Owner = Doworker.target as Window;
if (this. Owner = = null)
{
This. Owner = Window.getwindow (doworker.target as Control);

}this. Show ();

Well, it's done. Run is smooth until a piece of code comes up. That is the following piece of code:

var  as DataTable; if NULL return ; Msgwindow.run (()={        dbhepler.update (ordertable);    },null,"  Saving data, please later!);

Msgwindow is the class name of the component I encapsulated. I do not know why, this code calls the clock error, abnormal out of the code in the Run method: this. Owner = Window.getwindow (traget as Control);

Because the calling component might not be a window but a UserControl, this code is UserControl for the caller. The exception to the report is that Window.getwindow parameters cannot be null, that is, doworker.target as control fails, doworker.target is not a window at all, nor is it a control. How is that possible?!! The code is clearly written in a custom control. And there is another one in this control that is called the Run method, the parameters are similar, there is no problem, running smoothly. Why did this call fail?

After the trace debugging, found that the original problem is in place of the call. When the first parameter doworker is passed, the closure is used. External variable ordertable is referenced in this anonymous method. I think about the implementation of the C # closure that I've seen before, actually wrapping the referenced external object in an anonymous class, referencing the external object as a member of the anonymous class. Here, at compile time, the C # compiler silently generates an anonymous class for the ordertable variable, and ordertable is saved as a member of the anonymous class. If this is not the case, before the anonymous method is executed, the ordertable is out of scope and inaccessible.

Once you find the root cause of the problem, the solution becomes apparent. In fact, there is no need to close the package, put ordertable in the anonymous method can be resolved. As follows:

if NULL return ; Msgwindow.run (()={        var as DataTable;        Dbhepler.update (ordertable);    },null," saving data, please later!";    

Traps for closures in C #