Asynchronous Windows Forms Programming

In a simple Windows Forms application (such as the one created by the Visual Studio. NET application wizard), all forms and controls execute on the same thread-the primordial thread used to launch the application by calling Main () -so those forms and controls can freely call each other's methods.

When a Windows Forms window invokes a call asynchronously (using a delegate) that call executes on a worker thread from the thread pool, not the thread that created the window. the completion callback method is also executed on the worker thread. as a result, the completion callback method shocould never update the user interface directly because that wocould be calling a Windows Forms form or control on a different thread from the thread that created it. similarly, progress reports triggered by the worker thread are not allowed to directly update controls such as a progress bar. in all these cases, you must complete al the call from the worker thread to the user interface thread. this is exactly what the interface ISynchronizeInvoke interface, defined in the System. componentModel namespace is designed to do.

I didn't expect that there would be such a good article in IssueVision. I had a thorough analysis of asynchronous processing. in C #1.1, I implemented the C #2.0 function and made a detailed analysis of the internal mechanism.