ActiveX Control Tutorial - Part 3, Page 3
So you've created your own control with two easy-to-use properties. You've even put those properties to use via a chunk of code in the KeyPress event of the text box.
Now it's time for a nerdy developer to test your control.
You stick him at your desk and 2.4 seconds later he feebly complains, "But how can I read or write stuff inside the text box?"
"Damn", comes your reply. "You noticed"
If using a normal text box, you could retrieve the value by running the code...
... but unfortunately your control doesn't have a text property. However our actual Text Box (txtTextBox) does.
'Cause you're a super-intelligent ActiveX boffin now, you could easily implement such functionality by adding code similar to the following...
Public Property Get Text() As StringText = txtTextBox.TextEnd PropertyPublic Property Let Text(ByVal NewText As String) txtTextBox.Text = NewTextEnd Property
Do you understand what is happening here? You're just passing the Text property of the Text Box around through Property procedures.
But what if users requested all the other usual properties of a Text Box control? Alignment, Appearance, BackColor, BorderStyle, Font and ForeColor - to name just a few.
That's a lot of monotonous coding. And what if they also wanted to respond to certain events, such as the KeyPress and Click events of your Text Box?
Well, we've not really mentioned events yet so let's discuss them now.
Most controls have at least a few events related with them. The Text Box control has a KeyPress event, as we saw earlier today. The Command Button has a Click event. The Scroll Bar has a Change event. And so on.
When the Text Box or Command Button decides it should fire the event well, it does. And that means any code you have written behind the event runs. After your code has finished, control is then returned to the control. Confused? You should be, but please stick with it.
Now, you can create your own custom control events by adding a simple statement to the General Declarations section of your code, like this:
Public Event Click()
Public Event DocumentProcessed(DocumentID as Integer)
Simple enough. And then you could raise the event to the developer using your control by adding a line like this to your code:
Note: Notice how that last event passes an argument, the DocumentID.
Here's a quick diagram showing the course of events (pun most certainly intended):
Not too difficult, eh?
So let's recall our original problem what if our end user wanted to respond to events of the Text Box? Say, the Click event?
Well, we could create our own custom events identical to those of the Text Box. Then, when those Text Box events fire, we could raise our own events to the end user.
Let's see an example of how we'd do this with the Click event:
Public Event Click()Private Sub txtTextBox_Click() RaiseEvent ClickEnd Sub
All we're doing here is every time the Click event of our Text Box fires, we're just passing the message to our end user via our own control's Click event.
But writing all of that code for every single Text Box event would become just as boring and error-prone as it would be to write similar code for every single Text Box property - so boring in fact, that only Train Spotters International ever tried it. Unfortunately they all kicked the bucket before the project was completed. Old age, you know.
So is there an alternative to rid of writing all these monotonous properties, events or even methods? You bet your bottom dollar there is and it's all hidden behind an innocent-looking Microsoft wizard...