MS-Access / Getting Started

---

Exploring property-value persistence

At this point, you know that properties can be read/write, read-only, or write-only. What hasn't been explained is where the property persists the value when the property is written, and where the property gets its value when the property is read.

In a VBA project, property-value persistence is mediated through private variables contained within the class module. Generally speaking, each property is accompanied by a private variable that is the same data type as the property. This means that a property that reads or writes a string value will be accompanied by a private string variable, and each date property will be accompanied by a private date variable.

As you saw in the previous section, the property variables are either assigned or returned by the property procedures. A property variable should be given a name that indicates which property owns the variable. In the examples accompanying this tutorial, each property variable has exactly the same name as its property, and is tagged with an m_ prefix. For example, the property variable for the CustomerID property is named m_CustomerID. Furthermore, because the CustomerID property is a string, m_CustomerID is also a string.

There are cases, of course, where a property is not accompanied by a variable. For example, a readonly property may extract the value from a database file or retrieve it from the operating system. Or, the property might be write-only, in which case the property may act immediately on the value passed to the property procedure, and no storage is necessary.

Heeding property procedure rules

Two rules apply to property procedures:

• The name assigned to a property procedure is the name of the property. Therefore, you should use a descriptive, helpful name for all your properties. Typically, a developer using objects created from a class you create doesn't have access to the VBA code in the class and has to rely on the names you've assigned to its properties and methods for guidance.
• The data type of the Property Let, Property Get, and the private variable must coincide. For example, if the property is defined as a string, the private variable must be a string. Figure below illustrates this concept.

Note the following points in Figure below:

• The property variable is declared as some data type (labeled "A" in Figure below).
• The argument to the Property Let procedure is the same data type as the property variable ("B" in Figure below).
• The property variable is assigned its value in the body of the Property Let ("C" in Figure below).
• The Property Get procedure returns the same data type as the property variable ("D" in Figure below).
• The Property Get is assigned the value of the property variable ("E" in Figure below).

You'll get the following error if the data type assigned by the property procedures does not coincide:

Definitions of property procedures for the same property are inconsistent, or property procedure has an optional parameter, a ParamArray, or an invalid Set final parameter.

The property variable data type must coincide with the property's data type.

Caution Although you can use an incorrectly typed private variable for your property procedures, you'll encounter side-effect bugs if the variable doesn't match the data type used for the property procedures.