Data Binding

Database-centric applications are fully supported in WinForms. To get started, you can use Server Explorer to add connections to whatever databases you'd like. For example, Figure 1.18 shows Server Explorer and the tables in a database maintained on a popular Windows developer resource site.

Figure 1.18. A Database Connection in Server Explorer

Dragging a table from Server Explorer onto a Designer surface creates two components : a connection to connect to the database, and an adapter to shuttle data back and forth across the connection. Right-clicking on the adapter in the Designer and choosing Generate Dataset allows you to create a new data set , a DataSet-derived class specially generated to hold data for the table you originally dragged from Server Explorer. The default General Dataset options will also create an instance of the new data set for you to associate with controls.

Associating a source of data, such as a data set, with one or more controls is known as data binding . Binding a control to a data source provides for bidirectional communication between the control and the data source so that when the data is modified in one place, it's propagated to the other. Several data bound controls are provided with WinForms, including ListBox and ComboBox, but of all of them, the DataGrid control is the most flexible. Figure 1.19 shows a form with a data grid bound to the data set that's already been created.

Figure 1.19. A DataGrid Bound to a Data Set

When there's a data set on the form, it's easy to bind the data grid to it. You set the data grid's DataSource property in the Property Browser and fill the data set when the form is loaded. To do this, you use the data adapter:

Sub DownloadsForm_Load(sender As Object, e As EventArgs) _
      Handles DownloadsForm.Load
  SqlDataAdapter1.Fill(downloadsDataSet1)
End Sub

This is only a scratch on the surface of what can be done with data binding in general and the data grid specifically . For more, read Chapter 12: Data Sets and Designer Support, and Chapter 13: Data Binding and Data Grids.

Multithreaded User Interfaces

Because the Designer provides so much functionality via drag and drop and the Property Browser, it won't be long before you get to the meat of your programming chores. And when that happens, you're bound to run into a task that takes long enough to annoy your users if you make them wait while it completes ”for example, printing or calculating the last digit of pi.

It's especially annoying if your application freezes while an operation takes place on the UI thread, showing a blank square where the main form used to be and leaving your users time to consider your competitors . To build applications that remain responsive in the face of long-running operations, you need threads. And even though WinForms doesn't provide threading support, .NET provides many threading options that WinForms integrates well with, once you're familiar with how to do it appropriately. To explore your threading options, read Chapter 14: Multithreaded User Interfaces.

Deployment

When you've got your application just how you like it, all arranged and responsive and fancy, you'll want to share it. You have several options. You can create an archive of your files and send them as an e-mail to your friends and family, from which they can extract the files into the folder of their choice and run your application. Or, if you like, you can use the VS.NET Setup Project template to create a project that produces a Microsoft Setup Information (MSI) file containing your application's files. Recipients can use this MSI file to install the application into the folder of their choice.

Of course, the problem with both of these techniques is that as soon as you share your application, that's when you find the crushing bug that, when the moon is full and the sun is in the house of Orion, causes bad, bad things to happen. When problems come up, you need to remember who received your application so that you can let them know to install the new version before the existing version formats C: or resets your boss's Minesweeper high scores. Of course, all of this explains why your IT department mandates that all internal applications be Web applications.

The Web application deployment model is so simple, there is no deployment. Instead, whenever users surf to the Web application in the morning, they get the version that the IT department uploaded to the server the night before. That deployment model has never been available out of the box for Windows applications. Until now.

At this point, you should stop reading and try the following:

Using the Windows Application project template, create a project called DeploymentFun.
Drag and drop some controls from the Toolbox, and compile your application.
In the shell explorer, navigate to your DeploymentFun\bin folder and right-click on the Debug folder, choosing Properties.
Choose Web Sharing and turn it on, using DeploymentFun as the name of the share.
Using Start Run, enter the following URL: http://localhost/DeploymentFun/DeploymentFun.exe.

You've just used the no-touch deployment ( NTD ) feature of .NET to deploy your WinForms application like a Web application, except that it's a real Windows application complete with full user control over the frame, the toolbar, the menu bar, the status bar, shortcut keys, and so on. Any libraries that are required to make your application run, such as custom or third-party controls, will be downloaded from the same virtual directory that the application came from. And, just like a Web application, by default your WinForms application is running in a security sandbox. In the case of no-touch deployment applications, the sandbox is provided by .NET Code Access Security , which dictates that the permissions of your code are limited according to where the code came from, such as across the intranet. This is in contrast to classic Windows security, where code is awarded permissions based on who launched the application, an approach that doesn't work very well when everyone seems to run as Administrator.

For the details of deploying WinForms applications and controls over the Webincluding hosting WinForms controls on a Web page, application deployment, versioning, caching, and most importantly, securityturn to Chapter 15: Web Deployment.

Buy on amazon.com >>

Sells C., Gehtland J.

<< Previous page

Table of contents

Next page >>