Visual Basic supports Property procedures to implement properties in your own CLS and FRM modules. However, it turns out that you can use Property procedures even within BAS code modules.

How can this improve your programming skills? In many a way, as I will demonstrate. Say your program includes a global Integer variable named ThisMonth, which is supposed to contain a value in the range 1 to 12:

Public ThisMonth As Integer

How can you be sure that this variable is never assigned a value outside that range? The answer is to turn the actual variable into a Private member of the module, and use a pair of Property procedures:

' within a BAS modulePrivate m_ThisMonth As IntegerPublic Property Get ThisMonth() As Integer    ThisMonth = m_ThisMonthEnd PropertyPublic Property Let ThisMonth(newValue As Integer)    If newValue < 1 Or newValue > 12 Then        Err.Raise 999, "BAS module", "Invalid value for ThisMonth"    End If    m_ThisMonth = newValueEnd Property

A benefit of this approach is that the new Property ThisName has the same name as the original global variable, therefore you don’t need to modify one single line elsewhere in the source code. Once you complete the test of the application, you can delete the two Property procedures and restore the old global variable, again with no change to the rest of the program.

Another advantage of Property procedures within BAS modules is that you can expose the same value under different forms. For instance you could add this new read-only property, that exposes ThisMonth in the form of a string:

Public Property ThisMonthName() As String    ThisMonthName = Choose(m_ThisMonth, "Jan", "Feb", "Mar", "Apr", "May", _        "Jun", "Jul", "Agu", "Sep", "Oct", "Nov", "Dec")End Property

You can use Property procedures in BAS modules also to implement more flexible symbolic constants. Since you cannot using neither string concatenation nor Chr$() functions within Const statements, you are prevented from declaring string constants that embed control (unprintable) character. For instance, the following line raises a compile-time error:

' this statement is invalid !Const EscapeChar = Chr$(27)

However, you can simulate such a string constant by using a Property Get procedure within a BAS module, as follows:

Public Property Get EscapeChar() As String    EscapeChar = Chr$(27)End Property

Please note that this is a bit less efficient than a “true” symbolic constant, since the value is evaluated each time the “constant” is used from elsewhere in the program. On the other hand, this approach is safer than using a Public variable initialized in your Main procedure, because the value returned by the DoubleCRLF property cannot by accidentally modified elsewhere in the program.

Of course, The same effect can be reached using a Function instead of a Property Get procedure, but Property procedures are in general more flexible. For instance, you can easily implement “constants” whose value is set at runtime, as in:

Private m_Password As String Public Property Get Password() As String    Password = m_PasswordEnd PropertyPublic Property Let Password(newValue As String)    If m_Password = "" Then        m_Password = newValue    Else        Err.Raise 1001, "BAS module", "Password already assigned"    End IfEnd Property

UPDATE: Davod Parvin correctly suggests that you don’t even need to manually change the implementation of the property when switching from the debug phase to the final compiled program, because you can use compiler directives, as in:

#Const Debug = -1#If Debug = 0 ThenPublic Password As String#ElsePrivate m_Password As String Public Property Get Password() As String    Password = m_PasswordEnd PropertyPublic Property Let Password(newValue As String)    If m_Password = "" Then        m_Password = newValue    Else        Err.Raise 1001, "BAS module", "Password already assigned"    End IfEnd Property#End If

Update: The original tip uncorrectly stated that the “&” operator in a Const statement was illegal. It was in some previous version of VB, but at least in VB6 it works perfectly. Thanks to Rich M. who spotted the error and let us correct it.