It used to be that 'Events" were acts of God. By that I mean that events were givens – they were just 'there'. If we wanted to add another event, we were out of luck. But since VB 5.0, we now have the ability to raise our own events. We first declare the event 'signature' that we wish to raise. This is Public, and is placed in the General Declarations section of the code module:
Public Event validateRecord(ByVal operation As String, ByRef cancel As Boolean)You can declare event arguments just as you do arguments for procedures. However, there are just a few exceptions. For example, events cannot have named arguments, optional arguments, or ParamArray arguments. Events do not have return values like functions do.
So this declaration will permit us to raise an actual event, called validateRecord, in the form that is hosting our control. Whenever we want to raise this event from within our class, we can simply use the RaiseEvent function. For example, a bit later in the code we raise an event when the user attempts to add a record. We raise the validateRecord event and pass the string "Add" and a Boolean bCancel as parameters:
RaiseEvent validateRecord("Add", bCancel)
When we raise the event, the validateRecord event 'fires' in the form hosting our control. The string literal "Add" is passed to the form so the programmer knows which database operation raised the event. We also pass in bCancel so the user can either permit the add operation to proceed normally, or set bCancel to false to cancel the operation. We pass bCancel to the host form's event ByRef. This means that we pass in the memory location of the variable. This way, from within the form itself, the user can change the actual value of this variable. This way, when the code returns to our class module, we can interrogate the value of bCancel. If it is false, we proceed with the code in the class module. If false, we can abort the Add.
By adding this event, the programmer can place code in the validateRecord event that will now be automatically placed within the form itself. The programmer can place form-specific code to validate the Add operation. If the validation passes, the programmer allows the add to take place. If they wish to disallow the add, the programmer (within the form itself) simply takes evasive action by setting bCancel to false.
Once our control is added to the form, the validateRecord event is automatically added as shown - the programmer can take any action that may be required for that particular form. This way, we can provide a generalized control that gives the programmer total control over it's operation – right from the form! Cool. This screen shot shows how the event shows up in the host form:
The programmer can choose to ignore the event, or do whatever the application requires. In this example, the programmer is looking for when the user presses the Save button on the control array of our control.
While designing the control, we have no idea ahead of time what specific business rules might be required. So we simply turn this over to the programmer to add in the form event. So you can see that the ability to raise events gives us an extra dimension of flexibility that we can add to our control.
Now let's return to increasing the functionality of our control, and set up its methods and properties.