Date: 05.25.18 - 6:52pm
Early on in my coding life I started playing with vb6 user defined types. To C users they are known as structs.
They provide a way to group together a bunch of settings into one container . They really seem simple and easy. Their use also marks a certain stage of progression in a vb6 coders development.
public type myUDT field1 as byte integer1 as integer buffer() as byte end typeOn the surface they look great. You can define them easily and include multiple structures all in one module. They are compact and you know exactly how much memory they take up.
The problem is that VB6's language support for UDTs is not great. They come with scoping limitations. If you declare a private UDT, you can only use it in that one code module and not return it from any public function. Next thing you know many of your types must be public in a module and you have to search your code to find where they are used and defined. You can never port this code into an ActiveX dll.
UDTs can not be stored in a collection or variant type. You can only store them in individual variables or arrays pre defined to that specific type.
dim mu as myUDT dim mua() as myUDTArrays get annoying quickly with having to call redim preserve ubound + 1 all the time to add new elements Arrays can also be empty in which case Ubound() throws an annoying error that you have to trap. Removing elements from arrays is also sucky leaving either blank spots to fill (which in the case of a udt you have to zero out and mark a flag) or you have to compact the array which is equally annoying.
If you create a addElement type function to wrap dynamic UDT adding..you have to create a new function for each UDT type..because remember they cant be held as variants.
I do not consider UDTs to be generally useful for everyday programming. There is a much better technique to use for VB6, namely classes.
With a class you can still define public variable types and they are all still grouped together in one container. It is a little annoying that each container requires its own text file. This seems bloated and annoying for a small group of settings, but you get used to it. The advantages are great and out weight this annoyance.
You can pass a class around and return it from a function anywhere in your project. You can also easily transfer portions of your project over to an ActiveX dll easily in the future once they are stable and unchanging. Also you can always find the class definition since its a distinct file and has its own node in the project treeview.
Class variables can be held in variant type variables so you can pass different classes to functions and the function can respond differently based on what input type its given. This can be powerful for similar but different classes.
Classes can also be added to a collection. This allows simple key based lookup (arrays do not). Collections also allow you to use for each to walk the elements which is nice and compact and automatically handles the case of an empty collection without throwing an error. Collections also allow you to easily add and remove elements with a single call.
Another benefit to classes over UDTs is that your class can contain a series of related methods that function on the data contained within that class. This logical grouping and inherant access to the class private variables allows these member functions clean design and reduces the number of variables being passed in.
Imagine the class has a public .value as long. Your function prototype can be as simple as isBitSet(bit) instead of a generic isBitSet(value,bit). In a class you can also protect certain values from user manipulation and validate changes to the value to take other actions when one value is set. In this scenario you use a private m_Value and public properties named Value to get and set the real value. Now you can sanity check how its used or ensure read only access to it.
VB6 UDTs do have a place in the language though. There are two places they are great (and even mandatory). Actually I would say these are the two places they were specifically designed for.
The first is for use in windows API and interacting with C Structs. They were a must have here. The second is for serializing data to disk in a binary structure. The UDT packing and unpacking routines when dumping to disk were specially constructed for this task. (Get and Put have special handlers for UDT that are complex and powerful).
I really think these are the two specific use cases UDTs were designed for. While they can be used for general data storage, they dont perform well in this role compared to classes.
Everyone can have their own opinion on the matter, but thats my insight and description of why after working with vb6 for the last 20 years.