Dim KindaForm As New Collection Const pHeight As String = "1" Const pWidth As String = "2" Const pName As String = "3" ' ... With KindaForm .Add Key:=pHeight, Item:=Me.Height .Add Key:=pWidth, Item:=Me.Width .Add Key:=pName, Item:=Me.Name End With ' ... With KindaForm Print .Item(pHeight) Print .Item(pWidth) Print .Item(pName) End With
Here we have an object named KindaForm that has the "properties" pHeight, pWidth, and pName. In other words, an existing Visual Basic type (with both properties and method) is being used to create a generic state-only object. If you're using classes to do this, you might want to consider using Collection objects as shown here instead.
You can add functional members to a Collection object with just one level of indirection by adding an object variable to the collection that is set to point to an object that has the necessary functionality defined in it. Such methods can act on the state in the other members of the collection.
So what's the difference between using a collection and creating a user-defined type (UDT)? Well, a collection is more flexible (not always an advantage) and has support for constructs such as For Each:
For Each v In KindaForm Print v Next
The advantage of UDTs is that they have a known mapping. For example, they can be used as parameters to APIs, sent around a network and passed between mainframe and PC systems-they are just byte arrays. (See Chapter 4 for more on UDTs-they're one of Jon Burns's favorite things!) Obviously, a state-only Collection object doesn't mean much to a mainframe system, and passing KindaForm as "the thing" itself will result in your only passing an object pointer to a system that cannot interpret it. (Even if it could, the object would not be available because it's not transmitted with its address.)