As smart as our data control is, we still must handle data validation for each form. Remember when we raised the validateRecord event from our control whenever the user attempts to Add, Edit, Save, Delete or Undo a database operation? Well, click on the dbCtl1 in the left-hand drop down box in the code window of frmHost. Notice that validateRecord is listed as an event! We have now raised our own events! This is where the user can enter any form-specific data validation. We have provided a handy single routine to handle this.
Let's customize some code for this (now) built-in event.
1. Please enter the following in the form dbCtl1_validateRecord event procedure that will be fired from our ActiveX control:
Private Sub dbCtl1_validateRecord(ByVal operation As String, cancel As Boolean)
Dim msgString As String
Dim iIndx As Integer
If (operation = "Save") Then
If (Len(Text1.Text) < 1) Then
msgString = "Please enter a title." & vbCrLf
msgString = msgString & "The database operation was canceled"
iIndx = MsgBox(msgString, vbCritical, "VB Data Control")
cancel = True
Else
cancel = False
End If
End If
End Sub
Notice that we pass in the current operation. We are testing for when the user tries to Save a record. If the length is <1, then we won't permit the user to save the record. The programmer can test for any of the operations and then handle them as they see fit. For our example, we simply validate the length of the text box whenever the user attempts to save either a new or edited record. When the Save button is pressed, the cmdButton in our control is fired and within our control, the event is raised and fired at the host. The code in the control that does this is:
RaiseEvent validateRecord("Save", bCancel)
If (bCancel = True) Then Exit Sub
The control fires the event and we simply perform our validation within the form routine. The code in our form tests for the operation, which is "Save". If the user is trying to save the record but the length is <1, we display our message box and set cancel = True in our form event procedure.
If (operation = "Save") Then
If (Len(Text1.Text) < 1) Then
If we set cancel = True the save operation is effectively halted. Why? Because back in the control, when the event procedure completes within the form, we test for the value of bCancel. If bCancel is True, it means that our validateRecord found something it didn't like and canceled the operation. So our control simply exits the code and does not permit the save operation to take place.
Here we display our message informing the user what they need to do and cancel the operation. You could make this a bit more fancy by setting focus to the offending text box:
If you have your thinking caps on, you might be wondering how the cancel gets passed back to the control? We just set cancel = True in our form and the control knows about it. How does this work? Good question.
Well, it has to do with the way we created our event within the code. Recall that we defined the event like this:
Public Event validateRecord(ByVal operation as String, ByRef cancel as Boolean)
The ByRef (which is the VB default) is the answer. If we pass in the cancel variable ByVal (by value), then a copy of the variable is sent to the validateRecord event in the form. This is just a copy, so any changes made in our form would be discarded. The original variable would be unaffected.
However, by passing in the variable ByRef (by reference) we are actually passing the memory location of that variable. This means that our event procedure in the form has access to the physical memory location of the 'cancel' variable. So if that variable is changed, we can pick up that change in our control. Why? Because both the form event and the control are now both working with the exact same memory location that is holding the value of the variable cancel.