The data repeater is specifically designed for use with ADO. Essentially the data repeater control acts as a data-bound container for any user control you create. So if you create an ActiveX control, the repeater can host it for you. At run time, the data repeater displays several instances of your user control - each in its own row. After you compile the control into an .OCX, the data repeater control's RepeatedControlName property is set to your new user control. The data repeater is then bound to a data source, in our case the ADO data control, which sets up a connection between your control and the Publishers database. Amazingly, each is bound to a different record in the database. I know that the explanation above sounds like a mouth full, but don't worry. We will take each part step by step. So that you have an idea of what the control looks like in action, here's a preview:
As you can see, the data repeater control can display several records simultaneously. This is pretty cool, I think you will agree. By just scrolling on the data repeater, you can look at any and all records that you select. We are going to use the data repeater control to create a data bound ActiveX control from our Publishers table.
In the next exercise, we will create another ActiveX control. This control will then show up as an icon in your tool palette, just like the other tools at your disposal.
1. The first thing we want to do is start a new project of type ActiveX Control:
When you select the ActiveX Control type of project, a new control project will be created as shown in the Project Explorer. Notice that the icon is that of a control. This is a visual cue that we are now building a control:
2. First of all, name the project controlPrj and the control pubCtl.ctl. We want to name these with a descriptive name because we will be using a feature that was added in VB 5.0 – the project group. As you know, an ActiveX control is worse than useless if there is not a host to run it in. A control can't have a life of it's own - it needs a host to care for it and feed it.
Essentially, in a project group, one executable project (the Standard EXE project in our case) serves as the startup project. When you have a project group open and select Start from the Run menu, the startup project is executed.
In the Professional or Enterprise editions, you can use the project group to create and debug multiple component applications. If you don't have the Professional version then, alas, you will have to run two instances of VB 6.0, but you can accomplish the same thing but with a few more keystrokes.
3. Let's draw the control. Click on the control from the Project Explorer and you will notice the 'control designer' appear. Again, you draw the interface to an ActiveX control just as you would create a standard form. Add three textboxes and three labels to the control as shown and then resize the form so there will be no wasted space. Try to get it close to the example shown. That is because the control, when complete, will be as large - or as small - as the form you have drawn it on:
4. We have three text boxes. Give them the following names:
| Control | Name property |
Text1 |
txtName |
Text2 |
txtCompany |
Text3 |
txtPubID |
5. Now add the following code to the control as shown in the listings. We drew intrinsic controls - text boxes and labels - on our new control. So the text boxes have the Change event procedure built in. For the three text boxes, add the following line of code. We are calling the built-in PropertyChanged method and passing it the parameter of the variable name we wish to save. By providing the name of the variable in quotes, VB handles saving any data in the text boxes whenever the normal Change event is fired.
Add this code to the Change events of the respective text boxes:
Private Sub txtCompany_Change()
PropertyChanged "Company" 'automatically makes this persistent
End SubPrivate Sub txtName_Change()
PropertyChanged "Name"
End SubPrivate Sub txtPubID_Change()
PropertyChanged "PubID"
End Sub
You may remember when we were discussing ActiveX controls in the earlier chapters that the host (a.k.a. the form) is responsible for saving the properties of the controls. Well, our control is no exception. There is a built-in mechanism that automatically saves any properties we choose. By simply calling PropertyChanged and the name of the variable, VB 6.0 takes care of saving that value in the host for us. We don't need to worry about the details. So we can save the values for the three variables by simply calling PropertyChanged and passing the variable in quotation marks.
As you know, the Get property reads the value of the text box while the Let property updates the text box with the new value. These values will be read directly from the database. From the outside of our control, when an assignment to a property is made, we handle it as any other property for any other object, using the syntax:
myControl.myProperty = newValue
Well, under the hood when an assignment is made, VB knows this and automatically fires the Let event for that particular property. Likewise, when we need to read a value, it is done by reversing the items on either side of the equal sign:
NewValue = myControl.myProperty
Again, VB recognizes that we want to retrieve a value from our control, so it automatically invokes the Get procedure for the property. So when we see a Get something, we are returning a value. When we see a Let myProperty, we are assigning an internal private ActiveX control variable with a new value. When the user of our control wants to read the value of an internal ActiveX control variable, the Get myProperty is fired. So you can see that the Get does not take a parameter, because we are just reading and returning the value of a variable. However, Let does take a parameter. The parameter will be the value we want to change the internal variable to.