email article printer friendly get the code more resources

Enhance UI Performance in WinForms
You can improve your UI in several ways, using the .NET Framework's built-in multithreading and asynchronous execution mechanisms.
by Jason Beres

Posted April 9, 2004

Technology Toolbox: VB.NET, SQL Server 2000

You should give your apps UIs that users enjoy. Unhappy users make for unhappy programmers—and sometimes out-of-work programmers. You need to make your UIs attractive, easy to use, and responsive. Fortunately, you can do a lot to give your user interface a responsive feel without detracting from its other qualities.

You can improve your UI in three ways, using the .NET Framework's built-in multithreading and asynchronous execution mechanisms. First, you can raise events from a non-UI thread to update the controls on the UI thread. Second, you can create a simple background thread to load a DataSet, then load the DataSet into a DataGrid. Third, you can use a simple delegate to make any method asynchronous.

I've developed an application that demonstrates these three techniques. I call it DataExplorer (see Figure 1). It's a database access application—probably like most of the ones you write—and you can adapt its code for your own purposes (download the sample code here). I'll discuss the theory and practice behind DataExplorer's UI performance tricks here, starting with multithreading.

Now I won't lie and claim that multithreading's easy. However, I believe you can get up to speed on multithreading in Windows Forms apps if you absorb a little theory about processes, application domains, and the Common Language Runtime (CLR), then see how they work together in a sample app.

A "process" in Win32 refers to an executing instance of an application. Each executing app creates a new main thread that lasts the lifetime of that application instance. Each app is a process, so each instance of an app must have process isolation.

For example, each instance of Microsoft Word acts independently. When you click on Spelling and Grammar, InstanceA of Word doesn't decide to spellcheck a document running in InstanceB. Even if InstanceA tried to pass a memory pointer to InstanceB, InstanceB wouldn't know what to do with it or even where to look for it, because memory pointers only relate to the process in which they're running.

.NET Framework application domains provide security and application isolation for managed code. Several application domains can run on a single process, or thread, with the same protection apps would have running on multiple processes. Application domains reduce overhead, because you don't have to marshal calls across process boundaries if the apps need to share data. Conversely, a single application domain can run across multiple threads.