Preface to Text Box Class

By John Colby

This article is the second in a series of articles on Classes by John Colby. For a background on Classes, see last month’s article at http://databaseadvisors.com/newsletters/7602-4wr.asp.

Event handling is a requirement of successful programming in Access. In life, an event is something that happens. The meaning is the same in Access; an event refers to something that happens—usually in controls, forms, and reports. A few examples of events are:

· Clicking (or tabbing to) a control

· Opening or closing a form or report

· Clicking a command button

· Printing a report

· Selecting an item from a combo or list box

All forms, reports, and controls in Access have events. In the example that follows, we are going to build a Class that handles the Enter and Exit events of a text box, and uses a Text box control’s Enter and Exit events to change the control’s background as it loses focus.

We’ll use the Enter event to save the text box’s current background Color property to a private variable and then reset the background Color property to a predefined color value. The Exit event will retrieve the original background Color value from the private variable and return the control’s background Color property to its original value.

Normally we would place the control on the form, and place the code in the form’s event handler in the form. For example:

Private Sub mtxt_Enter()

‘do something here

End Sub

Private Sub mtxt_Exit(Cancel As Integer)

‘do something else here

End Sub

Many--, probably most--, programmers use this method. It works, but it’s difficult to maintain. If the code is at all complex and it contains bugs (and it probably will) you must find and fix the code wherever you’ve put it to use.

On the other hand, you could simply place that code in a library module as follows:

Function TextEnter(frm as form, txtMyCtl as text box)

‘do that same processing here

End function

Function TextExit(frm as form, txtMyCtl as text box, Cancel as integer)

‘do that same other something here

End function

And from the form’s event handler stub call the function as follows:

Private Sub mtxt_Enter()

TextEnter Me, txtMyCtl

End Sub

Private Sub mtxt_Exit(Cancel As Integer)

TextExit Me, txtMyCtl, Cancel

End Sub

All the text boxes on all the forms that call these functions now share a single instance of the code. This is definitely an improvement because:

· The size of the form’s module drops.

· Maintenance is easier, since only a single piece of code needs to be changed to fix a bug.

· Forms open faster, since the code isn’t being loaded over and over.

The only problem with this is that the code for handling the text box may now be scattered around. The event stubs that call the functions are still in the form’s module, but the functions being called are in some module somewhere in a library. This is where WithEvents comes to the rescue. (Unfortunately, many programmers don’t even know about WithEvents.)

First, using the WithEvents keyword, dimension a private variable, in the Class module, that saves a pointer to a text box. For example:

Private WithEvents mtxt As Access.Text box

You can now add event handlers to the Class that will be called when the corresponding event fires for that control. Consequently, the forms’ event procedures aren’t necessary because the code for the text box’s events isn now in the Class module with the rest of the code required to handle processing of this custom text box.

Since the scope of a private variable in a Class can be specific to that Class,. tThis arrangement avoids the conflict between the text boxes on different forms that would occur if they all tried to use a global variable. In addition, there’s no variable to pass around.

In the accompanying article, we’re going to use WithEvents to build a custom text box control that we can use on any form. Setting up all of the required Classes – one for each text box - for the demonstration form is a lot of work. Next month, we’ll look at a more efficient solution.