When you create a class module, you establish a number of features for that class.
You can create out and out values that can be read or changed just as any variable would be. Putting the following in the declarations section of the class module would establish a string called sName of just that sort:
Code:
Public sName As String
Now, I had told you elewhere that a class module is just a blueprint for creating objects. If you had the above statement (and nothing else) in a class module named clsOne, you could create objects from that class module, each of which would have one settable value called sName.
Code:
Dim One As New cslOne
Dim Two As New cslOne
One.sName = "Hello"
Two.sName = "GoodBye"
The class module clsOne does nothing in your project unless there is at least one instantiation of an object using that class. If you do not do at least that, the presence of that class module in your project will not change the final product at all. The module merely has instructions as to what an object of that type will be—if one is ever created.
When you create an object of that type, it has all of the features laid out in clsOne. It conforms to the blueprint.
(Creating something like I have described above is not very good programming though. If a collection of values is all you need, a Type is a better choice.)
When a class is to have settable or readable values, a property is a better choice. With a property, the actual variable holding the value is shielded “encapsulated,” and the class can be made to control what is permissable with respect to the value. If a value should be something that can be read, but should not be written to, you can use the property paradigm to make it read only, for instance. To do so you would just not provide a Property Let procedure.
Property Let and Get statements are written usually in pairs, with each having the same name. Which procedure is used is handled by
VB in accordance with whether you are reading the value or setting it.
Inside the actual property procedure, you can examine the value being sent, examine other values within the class or the project that might bear on whether the current operation is to be permitted, and so on. This kind of “fine-grained” behavior is not possible with a simple exposed variable.
So:
Code:
Option Explicit
Private sName As String
Private bCanChange As Boolean
Private bCanRead As Boolean
Public Property Let ChangeNameOK(Value As Boolean)
bCanChange = Value
End Property
Public Property Get ChangeNameOK() As Boolean
ChangeNameOK = bCanChange
End Property
Public Property Let ReadNameOK(Value As Boolean)
bCanRead = Value
End Property
Public Property Get ReadNameOK() As Boolean
ReadNameOK = bCanRead
End Property
Public Property Let Name(Value As String)
If bCanChange Then
If Value = "" Then
msgbox "Name cannot be zero length"
ElseIf InStr(Value, " ") <> 0
msgbox "Names cannot have spaces in them
Else
sName = Value
End If
Else
msgbox "Changing the name is not permitted at this time"
End If
End Property
Public Property Get Name() As String
If bCanRead = False Then
Err.Raise "clsMyThing", _
vbObjectError + 1, _
"Illegal Preperty Read"
End If
Name = sName
End Property
Hopefully you get the idea. Close scrutiny of values can be implemented, you can send messages or raise errors, and so on.
Finally, classes can have methods (which can be either Subs or Functions) which either do or do not take arguments, and which do things. They can perform calculations, change control properties, save data to files or open files—whatever.
So classes have simple variables that are exposed, properties, and methods. Each instantiation of a class’s blueprint as an object will have a full collection of the features of that class, yet will be distinct from every other instantiation of that class as an object.
But all of this is contained in even the most basic books about
VB. You should get yourself a beginner's
VB book, and read up on this. It would clarify a lot for you.
property
Linear Mode
