Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Drag Once DataBinding with Custom Controls : Page 3

Visual Studio 2005 will ship some great new controls, but suppose you want your own control to play in the Data Sources Window? To do that, you need to set up a new data source using the new binding attributes.

Working with Data Types
Looking back at the Tools-Options (see Figure 2) you can see a couple of elements. You can see a Data Type dropdown list at the top. You can associate this list of data types with specific controls. This list is a fixed list of types. Unfortunately we didn't have the time to make this list extensible, but, we did create a bucket for the things we knew we didn't know about. There is a great saying I like to quote: "I don't know what I don't know." Designing for the unknown is a key element when designing developer tools. By their very nature, developers will come up with scenarios our team just didn't think of when we originally built a given version of the product. To make sure tools don't get in the way, our team tries to incorporate designs that don't box developers into a pattern. We can optimize for a given scenario, but we should never constrain developers with glass ceilings. Visual Studio 2005 uses partial classes to enable a set of unknown extensions to the DataSet Designer. For custom controls, VS 2005 has a similar model. Under the Data Types dropdown in the Tool-Options dialog, you'll see [Other]. This is the big 'ol bucket for any type that VS 2005 doesn't recognize. I'll show you how to use [Other] later when I show you how to create an AddressBlock control.

List Objects and Controls
In addition to [Other] you'll also see [List]. The List item displays controls for list objects within the Data Sources Window. List objects are any object that represents an IList. This includes DataTables as well as Object collections (such as Customer.Orders). In addition, any object displayed in the root of the Data Sources Window is, by default, considered a List. For instance, if you add the Address object defined in Listing 1 to the Data Sources Window it will appear in the root. As a result, you can choose the "Drop Type" for Address as either a DataGridView or a Details control. In Beta 2 you'll be able to choose ComboBox as well. To understand this in more detail, I discussed how the DataConnector can turn a single object into a list in my last article.

In the Tools-Options dialog box, select Boolean and remove RadioButton, ComboBox, TextBox, and Label. Then select Byte Array and select PictureBox. Click the "Set Default" button to make this the default control. Then remove Label, LinkLabel, ComboBox, and ListBox from the Byte Array. Click OK. You've now customized the controls within your Data Source Window. Take a look at your DataTables within the Data Sources Window.

Are These Customizations per Project or per Machine?
So far, you've just changed machine-level settings. All the changes you've made in the Tools-Options dialog box are stored on your computer under Documents and Settings. Since you've changed the Windows Forms controls, they're in WinFormControls.xml. When Devices, Visual Studio Tools for Office, and Reporting Services support customization, they will likely have their own files as well. Per Project Settings
Now that you have your machine defaults established, I'll show you how to make some changes to your specific project. If you look at Employee.Photo, you'll notice it now defaults to a PictureBox control. By choosing the dropdown next to the Photo column, you'll notice that you only have PictureBox and None. At this point you haven't changed any machine defaults within the project.

Since users cannot edit the EmployeeID column, let's change it to a Label by choosing Label from the EmployeeId dropdown in the Data Sources Window. It would be nice to default primary keys to Label, but you can't. Since the EmployeeID is an integer, there isn't a way to differentiate it from other integers, and I doubt you want to make the default control for all integers to be Label. I know the developer in you is saying, "But you have a primary key, why can't you store a hashing of attributes and data types to set different controls and properties." We could have, but we only had so much time, and there are other enhancements we wanted to focus on, like Smart Captions (see sidebar, Smart Captions Are In). It would be nice to default HomePhone to a MaskedEditBox with a specific mask, but you can't. Well, actually you can, sort of. Visual Studio 2005 doesn't have the ability to set properties on a selected control, but you can create your own inherited control. I'll show you how to do that in a little bit. First, let me show you where Visual Studio 2005 will store these changes.

The place Visual Studio 2005 stores the overridden control depends on whether you're using a DataSet, an object, or a Web service. For DataSets, Visual Studio 2005 buries a new file below the DataSet.xsd file. If you press the "Wizard of Oz" button, (Show hidden files), you'll see the files behind the curtain. One of the new files has an .xsc extension. This file contains the control mappings for your dataset. If the file is empty, Visual Studio 2005 will always use the defaults that you configured in the Tools—>Options dialog box. So if you delete the file you will reset the project defaults to your machine settings. Files Behind the Curtain
While you're looking back here, I might as well mention the three other files. The .xss file is where VS 2005 stores the location and size of all the elements on the DataSet Designer. This is the "Make me pretty" file. The DataSet.designer.vb file is the generated code file. VS 2003 would generate directly into the DataSet.vb/DataSet.cs file. In VS 2005 these files are yours to work with. VS 2005 won't clobber over your code. I covered a bit of this partial class support in the last article, but I'll delve into this deeper in a future article.

Object Control Mappings
For objects, VS 2005 stores this information in the .datasource file. If you look behind the My Project node you'll see a Data Sources folder that contains your .datasource files. This directory will only exist if you've added an object data source. Within this file, VS 2005 stores a pointer to the type, and any overridden control types. For XML Web services, VS 2005 uses the same model as objects, but VS 2005 stores them under the Web References folder. You may be wondering: Are all control "Drop Types" stored in these files? No. One of the promises I made to myself when I joined Microsoft was to do what I can to make source code control work better within VS. Let's take another look at the way Visual Studio 2005 displays DropTypes in the Data Sources Window. For each column/property, you'll probably establish a project standard. The EmployeeID will likely always be a label. The HomePhone will likely be a PhoneBox control, (I know, I'm getting ahead of myself). The point is you'll likely establish standards and stick with them for the life of a project. However, let's take a look at the [List] DropTypes. These are the nodes in the root of the Data Sources Window, or any sub-list such as Customer.Orders. Now I'm excluding 1:1 objects such as Customer.Address. I'll discuss these in a minute. In the 1:Many case, you'll likely switch back and forth between creating a Grid and individual controls (Details). We didn't see much value in storing a project default here. It seemed more frustrating that each time someone changed from Grid to Details they'd checkout the .datasource or dataset files and block other members of their team. I had hoped to store this List Drop Type in the proj.user file which doesn't get checked into source control, but we just didn't get the time. VS 2005 will keep your setting in memory, so as long as you keep VS open, it will keep your selection. If you close then open your project, VS 2005 will default to the DataGridView, or whichever control is at the top of the list.

But what about Customer.Address DropTypes? VS 2005 treats these differently. In this example, Address isn't a list. It's simply a sub object that hangs off Customer. VS will store this DropType within the .datasource or .xsc file. So, later on when you create an AddressBlock control, VS can default it to Customer.Address and it will "stick" and be shared with the rest of your project team. We're still trying to figure out how developers will know to check-in the .datasource files under MyProject\DataSources, so keep this in mind as we work through RTM of VS 2005.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date