UDTs Are Not Self-Describing

One seemingly trivial difference between the two examples is that with the UDT case, you would need to have had the definition of Point visible to your code, either in that module or as a Public Type in another module. The class, on the other hand, comes as part of the Automation framework, which means you need only have a reference to the binary implementation of the class for it to work. The accompanying type library will describe to the calling code that the Point class has two properties, X and Y.

Suppose you were developing a library of code that handles point manipulation:

Using a Class	Using a User-Defined Type
Calling function needs a reference to the library. Built-in type library enables calling function to use Point class.	Need to ship a BAS file, which the calling function must include in its source code to understand Point UDT.

Automation is concerned with binary integration of components, not source code integration. Out-of-process and Remote Automation components interact with one another through the same mechanism as does code utilizing classes within a single program. It is clear that UDTs do not fit into this approach because of their inability to describe themselves at a binary level.

This explains why the newer features of Visual Basic tend not to support UDTs. For example, Visual Basic 5 will not let you do the following:

Have a UDT as a public property of a class or a form
Pass a UDT as a ByVal parmeter to a subroutine or a function
Have a UDT as a parameter to a public method of a class or a form
Have a UDT as the return type of a public method of a class or a form
Place a UDT into a Variant

However, you can do all these things with classes. For this reason alone, you should use classes instead of UDTs.