As you may recall from
Chapter
8, many controls provide
DataField and
DataSource properties, so you can bind them to a particular field provided
in the Recordset of a Data Control.
You can implement these fields and other data-bound fields as well with ActiveX
custom controls. The following sections discuss how you can do this.
Providing DataSource and DataField Properties with the Procedure Attributes
Dialog Box
A bound control must have a DataSource property
to indicate the Data Control to bind to and a DataField property
to indicate which field to bind from the DataSource's
Recordset.
In addition, a moment's thought will tell you there is also a third property
involved in this arrangement: a property that actually reflects the contents of
the bound field. For a TextBox, this is the
Text property, and for a Label, on the other
hand, it's the Caption.
You can give your control DataField and
DataSource properties and indicate a third property that will reflect the
bound data by following these steps:
STEP BY STEP
13.3 Giving Your Control DataField and DataSource Properties
-
Change the UserControl's
DataBindingBehavior property's value to 1-vbSimpleBound.
Make sure your text cursor is in the code window for your UserControl,
preferably in one of the Property procedures of the property you wish
to reflect the bound data.
Choose the Tools, Procedure Attributes option from the VB menu (see Figure 13.7).
FIGURE 13.7 Specifying a property to bind to the DataField
On the resulting dialog box, make sure the property that will reflect the bound
data is chosen in the Names field.
Click the Advanced button.
In the Data Binding section at the bottom of the dialog, check that the box labeled
Property is data bound, and then check that the box labeled
This property binds to DataField.
If you follow these steps, then developers using your control will see the
DataField and DataSource properties in the properties window of
each instance of your control. If the developer points the DataSource and
DataField properties to a valid Data Control and a valid field in the Data Control's
Recordset, then the custom property you specified in step 3 above will reflect the contents of
the underlying data field in the designated property.
The custom property's Property Let procedure will fire every
time the underlying data in the specified field changes. To be completely safe in the
Property Let procedure, you should call the CanPropertyChange method,
as described in the following section.
Calling the CanPropertyChange Method Before Allowing a Property Value to Change
You may wonder what will happen if you implement a data-bound property as described
in the previous section only to have a developer bind your property to a field in a read-only
data source. Obviously, there will be a problem when there is an attempt to update the contents
of the property and, therefore, the underlying data.
You therefore need to take precautions to ensure that an attempt to update your property
won't cause some sort of runtime error if the underlying data it's bound to can't
be updated.
The CanPropertyChange method is supposed to return a Boolean
value indicating whether it's safe to attempt to update a property's value.
If CanPropertyChange returns False, then it's not safe to update the
data underlying the property. You can use CanPropertyChange in the
Property Let procedure. Only if it returns True will you perform the actions needed to
update the property's value, as illustrated in Listing 13.16.
LISTING 13.16
CALLING THE CANPROPERTYCHANGE METHOD IN A PROPERTY LET PROCEDURE
Public Property Let LastName(ctrVal As String)
If CanPropertyChange("LastName") Then
m_LastName = ctrVal
PropertyChanged "LastName"
End If
End Property
NOTE - CanPropertyChange
Doesn't Do Anything in Current Versions—Use Only for Future Compatability
: Note that we said that CanPropertyChange is
supposed to return a result indicating whether it's safe to update a property.
As of Version 6 of VB, VB's CanPropertyChange method
always returns True. Microsoft still recommends that you use it, however, as you
may want it in place for future compatibility.
So how does VB currently handle an attempt to update a read-only data field if
the CanPropertyChange method always says it's OK to
update? VB raises no runtime errors and simply ignores the request to update the
field.
