Browse DevX
Sign up for e-mail newsletters from DevX


Drag Once DataBinding with Custom Controls : Page 6

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.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Build an AddressBlock Custom Control
Now let's do something a bit more complicated. Or at least Visual Studio 2003 made this idea more complicated. How many times have you built a form that has a set of controls that represent an address? How frustrating is it to have to set the width of each control, name each one, or group the City, State, Zip on the same line? Wouldn't it be cool to just do that in one place, then, just instance the control on all of your forms? I think this was one intention of the UserControl, however, the UserControl wasn't very user friendly when it came to databinding. Ok FoxPro guys, I know you could do this seven years ago. I was one of those guys, and it's always frustrated me about VB and now Windows Forms. I will show you how to create a UserControl with the typical Address controls. Line1-3, City, State, Zip, Country. Now I could go a little further and make the State and Country controls ComboBoxes and load them from a database, but Rod (CoDe's Editor in Chief) has already been gracious enough to extend the deadline to write this article for me. Besides, this is not a book and I'm already running long.

Let's add a UserControl to your Control Library project—the same project you added the PhoneBox control to. Now you could layout your forms from the Toolbox, but what fun would that be? You would have to name and databind each control; that's just so "old school." Let's add the Address object to your control library project using Listing 3. Choose Rebuild Solution, then run through the Data Sources Wizard to add the Address object. It's important to have the Control Library selected when you run through the Data Sources Wizard. Remember, the Data Sources Window shows data sources for the active project. Set the Address DropDown to Details and drag it to your AddressBlock user control. Delete the labels and BindingNavigator and align the controls similar to Figure 5.

Figure 5: AddressBlock control.
You can now add the code behind AddressBlock to expose a public property named Address that you'll use to set to the Address BindingSource.DataSource (see Listing 4). Notice the code also adds the DefaultBindingProperty attribute.

Columbus Was Right...
Long ago, Columbus discovered the world wasn't flat. Neither are your object models. The VS 2003 designers also thought the world was flat. Suffice it to say, the Columbus window, (AKA the Data Sources Window) will display your hierarchical object model. VS 2005 intelligently handles 1:1 and 1:Many objects. You can see examples in Customer.Address or Customer.Orders. To get a feel for this, let's put your Address object to work. 1:1 Objects
Let's create a Customer object that has a few properties, and—of course—the Address object. Listing 5 shows the details of the Customer object. Add this code to your user control project.

Now, rebuild your project and add the Customer object as a data source to your EXE project. At this point, you should see something that looks like Figure 6.

Figure 6: Customer.Address.
Are You Ready Yet? Are You Ready Yet?
Yes SpongeBob®, we're finally ready to add your custom control. You now have a Customer object that has several properties. One of them happens to be an Address object (1:1). If you remember the Tools—>Options dialog box, you'll remember that Address is probably not listed in the Data Types. But, the big 'ol bucket [Other] is.

Let's add your AddressBlock control. Using the shortcut from the Data Sources Window, select Customize. Remember, it doesn't matter where you select it because it's just a shortcut. Now select [Other] as the Data Type and click AddressBlock. This is one example of how we design for the unknown. Good News, Bad News...
Let's start with the bad news. If you're using Beta 1, you're likely wondering why your AddressBlock doesn't show as the DropType for Customer.Address. As with all Betas, not everything is fully baked.

The good news: You've heard from Columbus and he didn't fall off the end of the earth. He's just stopping off at Beta 2 and will be back by RTM to show us his journey. To get this working in Beta 1 isn't difficult. Using the Data Sources Window, change Customer DropType to Details and drag it to your form. Now, using the Toolbox, find your AddressBlock control and drag it to your form. Ahhh, connect the dots, right? Well, no, this doesn't work in Beta 1 either. "Connect the Dots" is the cook on the Santa Maria. So we'll have to just use old faithful, the property grid. Select the AddressBlock control and expand the DataBindings section. You should see Address as a bindable property. Select the DropDown and you can select CustomerDataConnector or CustomerBindingSource, depending on which build of VS you are using, and select Address. Voila! You've got a picture of the earth from space; and yes, its round, it's hierarchical, and it doesn't require lots of designer gooey interfaces.

I could take this further and load the form with a collection of customers where each has an order. However, I really need to finish up here and leave room for some paying advertisers. You can download a more full-featured sample using a link from my team's blog. DataBinding Is Goodness
Hopefully you've seen several more examples of how the VB and Client teams are working hard to make databinding more reliable in your applications. In future articles, I'll write more about our lookup features and the work we're doing to support DBNull and Nullable types.

Please visit our team blog to provide feedback, both good and bad. Also, don't forget the MSDN feedback center to log any bugs you find. As a Microsoft developer, you have new and direct ways to help us build the best development tool there is. Sometimes we name things a little goofily.

Steve Lasker is a Program Manager on the Visual Basic team at Microsoft. His team is responsible for many of the Data Design Time features for building client applications including the Data Sources Window and the DataSet Designer. Prior to joining Microsoft, Steve was a technical architect at a large consulting company building Web, client, and device applications for corporate customers. Steve has an engineering background in the remote broadcasting industry. Give his team some feedback at the VB team blog.
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