DotNetReflection Concepts

Full article

Introduction

There are two concepts of learning. They are Deep and Surface. Deep learning focuses on "what is signified"; surface focuses on "signs". This article is trying to find the answer for signified questions like what, how, etc. It is intended for this audience.

Updating the UI from a Secondary Thread

[Full article]In my January 2004 column I discussed the use of delegates to execute a method asynchronously. I showed you that it's relatively easy to call BeginInvoke on a delegate object from the code behind a Windows® Form in order to dispatch an asynchronous method call. You also saw how to set up a callback method that fires automatically when the asynchronous method call completes its execution. However, I stopped short of talking about how you should update the UI to tell the user that the work is complete.
Updating user interface elements from a secondary thread in Windows Forms is tricky because a secondary thread is not allowed to read or write property values directly from a form or any of its child controls. This restriction exists because form objects and control objects in Windows Forms are not thread-safe. The only thread that's allowed to directly access a property value of a form or one of its controls is the primary UI thread. You must learn how to update the user interface without breaking this rule.
The technique you're going to learn here involves writing code to switch control to the primary UI thread from the secondary thread where it's executing—a process known as marshaling. This will allow you to update the UI safely and reliably. Once you switch control from a secondary thread to the primary UI thread, you are free to change any property values of a form and its child controls.

Asynchronous method execution using delegates

[Full article]This month I'll discuss the use of delegates to execute a method in an asynchronous fashion. I'll assume that you already know the fundamentals of programming with delegates, but if not, you should read the December 2002 and January 2003 Basic Instincts columns.
There are a number of scenarios in which asynchronous execution can be a valuable design technique. For example, you should use asynchronous execution in a Windows® Forms application when you want to execute a long-running command without blocking the responsiveness of the user interface. As you will see, programming with delegates makes it relatively easy to run a command asynchronously on a secondary thread. That means you can build a Windows Forms application that executes long-running calls across the network without freezing the user interface.
Executing methods asynchronously can also serve as a useful technique for a server-side application. Imagine you are writing the code behind an ASP.NET page to service a client request. What should you do if your code needs to execute two or more time-consuming calls across a network? For example, imagine you are required to write an ASP.NET page that must run a query against a remote database and also must execute a SOAP method on a remote Web Service to complete its work. If you don't use asynchronous method execution, you can only make one call across the network at a time. This means you can't start the second network call until the first network call returns. Asynchronous method execution using delegates lets you execute two or more network calls at the same time. This can significantly reduce the time it takes to process a server-side ASP.NET request, increasing the responsiveness of your application from the user's perspective.

C# docking panel suit

http://sourceforge.net/projects/dockpanelsuite/