Beginner to User Defined Data Types (Custom Type, UDTs)

[mc84excel]

I've decided to learn custom types (I haven't learnt classes yet so I figured I should learn this first). So far I've read this tutorial http://sourcedaddy.com/ms-excel/crea...ata-types.html

The problem is that I can't see anything exceptionally useful about user defined types *; so in case I am overlooking something big, I thought I'd ask the experts.

So how about it? What are the pros and cons that newbies to UDTs should know?






* (using the example on URL provided) I admit that its neat that you can group related variables together but if you named the variables with similar starting prefixes instead of using a custom type that would achieve almost the same result e.g.

'dummy code
Option Explicit

'method1: not using custom type
Dim strcarMake as String
Dim strcarModel as String
Dim curcarPrice as Currency

'method2: using custom type
Type CarInfo
   Make as String
   Model as String
   Price as Currency
End Type

Sub Test()
Dim myCar as CarInfo

'now depending on what method I used, I can use either strCarModel or myCar.Model. Apart from the pleasing use of logical grouping of related variables as a result of using custom types, what other advantages are there?

End Sub

[mc84excel]

Add 1 Pro = Intellisense is applied when writing code with custom types.

Anything else?

[Kyle123]

tbh I don't usually bother with UDTs, classes are much more useful. However they can be handy when dealing with data with multiple properties and you can pass them around as parameters:

Sub test()
    
    Dim car As CarInfo
    Dim cars(0 To 2) As CarInfo
    
    car.Make = "xyz"
    car.Model = "abc"
    car.Price = 20.66
    
    cars(0) = car
    cars(1).Make = "sa"
    cars(1).Model = "a"
    cars(1).Price = 55.99
    
    Debug.Print ftest(car)
    
End Sub

Function ftest(c As CarInfo)
    ftest = c.Price
End Function

More commonly, you'll see them used a lot in APIs

[mc84excel]

Thanks for the explanation Kyle. +1

they can be handy when dealing with data with multiple properties and you can pass them around as parameters

True. On the other hand, I could use global level variables to pass data around instead of using a UDT could I not? As for the data with multiple properties - instead of using a UDT with 5 properties (or whatever they are called in UDTs), I could use 5 global variables.

tbh I don't usually bother with UDTs, classes are much more useful.

I'm beginning to think of skipping UDTs and jump straight to classes. From what I've read/heard, they are much more useful!

[Kyle123]

On the other hand, I could use global level variables to pass data around instead of using a UDT could I not? As for the data with multiple properties - instead of using a UDT with 5 properties (or whatever they are called in UDTs), I could use 5 global variables.

No, no, and a thousand times no. To take your logic to its natural conclusion, why even have functions at all? You wouldn't need them if everything is a global variable.

Scope should be kept as small as possible, have a read here about scope http://www.vb6.us/tutorials/variable-scope, then here (http://www.xtremevbtalk.com/showthread.php?t=201646) about why global variables (as opposed to constants) are bad, or at least why they should really only be used as a last resort.

I'm beginning to think of skipping UDTs and jump straight to classes. From what I've read/heard, they are much more useful!

I think you should cover the basics first and understand good programming practice, without understanding scope, I think public and private members of classes will completely pass you by.

[mc84excel]

To take your logic to its natural conclusion, why even have functions at all? You wouldn't need them if everything is a global variable..

I'm afraid I'm having trouble following that logic. Functions return a value (usually as a result of a calculation). Variables can only retain a value.

Scope should be kept as small as possible, have a read here about scope http://www.vb6.us/tutorials/variable-scope, then here (http://www.xtremevbtalk.com/showthread.php?t=201646) about why global variables (as opposed to constants) are bad, or at least why they should really only be used as a last resort..I think you should cover the basics first and understand good programming practice, without understanding scope, I think public and private members of classes will completely pass you by.

You don't need to convince me on the coding practice of keeping scopes as small as possible. That is something that I do practice when coding.
Having said that, I do occasionally use global (well project level ) variables when I need to hold values that will be reused in the same WB session.

[Izandol]

if you named the variables with similar starting prefixes instead of using a custom type that would achieve almost the same result

I do not understand what this means. Naming the variables in such a way does not achieve anything. Further if you do not see a difference between a UDT and naming variables I do not think you will like classes.

[mc84excel]

I do not understand what this means. Naming the variables in such a way does not achieve anything.

Naming the variables in such a way achieves better readability of code.

I've written a better example below.
I would rather work with Sub Example1 instead of Sub Example2. The "Car_" prefix makes the code easier to read and easier to note which variables are directly related to "Car"
Sub Example3 (using UDTs) has a slight advantage over Sub Example1 because of the use of Intellisense when writing the code.

Option Explicit

Type Car
    Make    As String
    Model   As String
    Price   As Currency
    Km      As Long
End Type

Sub Example1()
    Dim strCar_Make     As String
    Dim strCar_Model    As String
    Dim curCar_Price    As Currency
    Dim lngCar_Km       As Long

    Dim varArray()      As Variant
    Dim lngLoop         As Long
    Dim lngEstimate     As Long
    Dim varExample      As Variant


' do something
End Sub


Sub Example2()
    Dim curPrice    As Currency
    Dim lngKm       As Long
    Dim lngLoop     As Long
    Dim lngEstimate As Long
    Dim strMake     As String
    Dim strModel    As String
    Dim varArray()  As Variant
    Dim varExample  As Variant


' do something
End Sub

Sub Example3()
    Dim udtCar          As Car
    Dim varArray()      As Variant
    Dim lngLoop         As Long
    Dim lngEstimate     As Long
    Dim varExample      As Variant

    'use UDTs (defined at top of module)
    'e.g.
    Car.Make = "Unknown"

' do something
End Sub

Further if you do not see a difference between a UDT and naming variables I do not think you will like classes.

I do see a difference between using UDTs variables and global variables. I don't see any major advantage.

Actually I have a feeling I will love classes (once I get round to learning them). Certain features of them sound extremely useful.

[Andy Pope]

The is nothing exceptional about UDTs. Just as there is nothing exceptional about arrays for dealing with multiple items

Dim strItems(1 to 3) as string

dim strItem1 as string
dim strItem2 as string
dim strItem3 as string

Having said that both can make dealing with certain data much more straightforward.

I use them when simply storing information, such as a bunch of parameters. If I need to manipulate values or provide related method/function then obviously I step up to a class object.

[mc84excel]

Thanks for the explanation Andy Pope +1

The is nothing exceptional about UDTs.

That's what I'm coming to!

If I need to manipulate values or provide related method/function then obviously I step up to a class object.

Classes! I must learn Classes!

[Izandol]

If you see the difference then I still do not understand why you say this:

if you named the variables with similar starting prefixes instead of using a custom type that would achieve almost the same result

One thing is not the same as the other. A UDT groups variables into one entity - something like, but not as useful as, a class with just member variables. As Kyle said you can then pass one argument to a routine instead of many. Naming variables with a prefix does not achieve anything like this.

[mc84excel]

A UDT groups variables into one entity - something like, but not as useful as, a class with just member variables.

I agree that the logical grouping is nice. However see my reply to Kyle. I could use 5 global level variables (with a nice naming prefix ) to pass data instead of a UDT containing 5 variables. Using 5 variables instead of a UDT would mean I wouldn't need to declare the UDT in every sub that requires the variables.


The biggest disadvantage that I see to UDTs is that they don't hold their data. If I use global level variables, they (usually) hold their data from sub to sub. With a UDT, I would need to set their values every time before I can use them. Please correct me if I am wrong on this point.


UPDATE: Thanks to demo code provided by Andy Pope, I went back and tested this in a current project. Both assumptions I made in this reply are wrong. My apologies.

[mc84excel]

UPDATE:This summary is outdated. See the last post for the latest version.

I was looking for advantages of UDTs but the more I hear about them, the less I like them.

Disclaimer: I haven't tested all of the below myself. If any assumptions below are incorrect, please let me know so I can update the thread to help other new users to UDTs


DISADVANTAGES:

1. Can't hold values after sub ends (Unlike global variables) (PROVEN FALSE See post #12)
2. Need to declare the UDT in every sub that makes use of the UDTs elements (PROVEN FALSE See post #12)
3. Can't declare new instances of a Type (Unlike Redim Preserve on Arrays) (FALSE. See posts #12 & #18)
4. Speed/Performance impact (TRUE. But.... Minor overhead. Nothing to worry about. See post #18 for demonstration)
5. Difficult to use in an Add-In? (e.g. http://stackoverflow.com/questions/1...-from-an-addin )
6. Difficult to pass in Arrays? (e.g. http://www.vbaexpress.com/forum/show...r-Defined-Type)
7. Difficult to determine whether value assigned to UDT element or not (TRUE. But.... No more than a variable of any other type)
8. No control over values assigned to elements of a Type (TRUE Use Classes instead)
9. Can only hold variables, can't process code (TRUE. But... But neither can standard variables)

ADVANTAGES:

1. Can logically group variables together
2. Can have multiple elements passed by one variable (Arrays do too. But it's easier to read Car.Make instead of varArray(5))
3. Intellisense when writing code

[Andy Pope]

Disadvantage 1. UDT can be public just like any other variable. You just need to scope them in the correct place.

Public Type Car
    Make    As String
    Model   As String
    Price   As Currency
    Km      As Long
End Type

Public g_udtMyCar As Car

Sub Example3()
    'use UDTs (defined at top of module)
    'e.g.
    g_udtMyCar.Make = "Unknown"

' do something
End Sub

Disadvantage 2. Again depends on your scope definition

Disadvantage 3. Incorrect, you can redim and redim preserve

Option Explicit

Public Type Car
    Make    As String
    Model   As String
    Price   As Currency
    Km      As Long
End Type

Public g_udtMyCars() As Car
Sub Example4()
    
    ReDim g_udtMyCars(1 To 3)
    
    g_udtMyCars(1).Make = "Ford"
    g_udtMyCars(2).Make = "Audi"
    g_udtMyCars(3).Make = "BMW"
    
End Sub
Sub Example5()
    
    ReDim Preserve g_udtMyCars(1 To 5)
    
    g_udtMyCars(4).Make = "Mercedes"
    g_udtMyCars(5).Make = "VW"
    
End Sub
Sub Test()
    
    Dim lngIndex As Long
    
    Example4
    Example5
    
    For lngIndex = LBound(g_udtMyCars) To UBound(g_udtMyCars)
        Debug.Print lngIndex, g_udtMyCars(lngIndex).Make
    Next
    
End Sub

Disadvantage 4. I don't see the use of udt against normal variables having a performance hit. Do you have any evidence of this?

Disadvantage 5. Don't see why, you need to clarify your statement about why they are hard to use in addin.

Disadvantage 6. No they are not.

extends previous code example.

Sub Test()
    
    Dim lngIndex As Long
    
    Example4
    Example5
    
    For lngIndex = LBound(g_udtMyCars) To UBound(g_udtMyCars)
        Debug.Print lngIndex, g_udtMyCars(lngIndex).Make
    Next
    
    Example6 g_udtMyCars(2)
    Example7 g_udtMyCars
    
    Debug.Print GetCar(g_udtMyCars, "Ford").Price
    
End Sub
Sub Example6(MyCar As Car)
    Debug.Print MyCar.Make
End Sub


Sub Example7(Cars() As Car)

    Dim lngIndex As Long
    
    For lngIndex = LBound(Cars) To UBound(Cars)
        Cars(lngIndex).Price = Int((50000 - 15000 + 1) * Rnd + 15000)
Debug.Print Cars(lngIndex).Make, Cars(lngIndex).Price
    Next

End Sub
Function GetCar(Cars() As Car, Name As String) As Car
    Dim lngIndex As Long
    
    For lngIndex = LBound(Cars) To UBound(Cars)
        If StrComp(Cars(lngIndex).Make, Name, vbTextCompare) = 0 Then
            GetCar = Cars(lngIndex)
            Exit Function
        End If
    Next
End Function

Disadvantage 7. no more than stanadard variables

[mc84excel]

...

Appreciate your detailed myth busting of UDTs disadvantages. +1
At this rate, I may end up using them after all!

1. (Tests code provided). :eep: Whoa. It's now working! Now why didn't it work in my current project? Will go back, test and report back.
2. As above
3. (dazed) That's incredible. Then what did Chip Pearson mean? See: http://www.cpearson.com/excel/classes.aspx (1/3 down the page - where he describes 3 disadvantages to Type)
4. I was reading about UDTs having a slight impact on code performance. It involved a test that used LenB in Immediate window to measure the size of variables. But I can't remember where I read it and a quick google can't find it again
5. This? http://stackoverflow.com/questions/1...-from-an-addin
6. I have come across a few web pages re UDTs and arrays. Here's one: http://www.vbaexpress.com/forum/show...r-Defined-Type
7. I concur.

UPDATE: 1 & 2 tested in current project. Working fine now. (No idea why it played up previously)

[Izandol]

Alas I think you are still confused.

UDT = User Defined Type

A UDT is not a variable, although a variable can be declared as a UDT. You should compare a UDT with String, Long, Double and so on and not with variables. A variable that is declared as a UDT can have the same scope as any other variable. It is difficult to answer your points regarding disadvantages since you do not provide a comparison but I may say the following:

1. & 2. I have just discussed
3. I do not know what you mean by this statement?
4. Why have you declared this a disadvantage? What do you think the performance impact to be?
5. Why is a UDT hard to use in an add-in?
6. You may pass UDTs in array as any other data type.
7. I do not think this any more difficult than testing a variable
8 & 9 I may agree with.

[mc84excel]

Alas I think you are still confused.

I think I am too Which is why I started this thread.

Re the points - I have updated post #11.

[Andy Pope]

There will be a hit in memory allocation

Public Type Car
    Make    As String
    Model   As String
    Price   As Currency
    Km      As Long
End Type
Sub Test()
    Dim udtCar As Car
    Dim Make    As String
    Dim Model   As String
    Dim Price   As Currency
    Dim Km      As Long
    
    Debug.Print "UDT", LenB(udtCar)
    Debug.Print , "KM", LenB(udtCar.Km)
    Debug.Print , "MAKE", LenB(udtCar.Make)
    Debug.Print , "MODEL", LenB(udtCar.Model)
    Debug.Print , "PRICE", LenB(udtCar.Price)
    Debug.Print ""
    Debug.Print , "KM", LenB(Km)
    Debug.Print , "MAKE", LenB(Make)
    Debug.Print , "MODEL", LenB(Model)
    Debug.Print , "PRICE", LenB(Price)
End Sub

reports

UDT 20
KM 4
MAKE 0
MODEL 0
PRICE 8

KM 4
MAKE 0
MODEL 0
PRICE 8

I read the following as being unless you dimension prior to run time you will have to ReDim which in itself has a performance hit. Not that you can not do it.

You must declare all the variables you'll need at design time or you need a dynamic array that is resized with Redim Preserve, an awkward and expensive operation.

The other 2 points stand. because you are only assigning values you can not control what values are used or perform additional operations on the value.

[mc84excel]

...

Thanks for testing I have updated post #11 to record this.

[Izandol]

Why do you update an earlier post and remove the logic flow of this question? It is like programming with many Goto statements now.

[mc84excel]

Why do you update an earlier post and remove the logic flow of this question? It is like programming with many Goto statements now.

I did consider doing a new post to record an updated list of advantages & disadvantages - removing the points now proven false - but if I did that, it would throw out the current numbering used throughout the replies in this thread. This would be more confusing for the reader then simply updating the same post (post #11) with new information.

Once disadvantage #5 & 6 have been solved one way or the other, I will do one last post which will summarise the advantages/disadvantages to using UDTs and then close the thread.

[mc84excel]

Most of the disadvantages of UDTs (post #11) have now been proven false (Thanks to Andy Pope). At this point, I'm now convinced of the usefulness of UDTs.

I won't close this thread yet as there are two "disadvantages" that have not been proven either way. (Disadvantage #5 & #6) I'd be interested if anyone can prove/disprove these.

[Izandol]

It would be simple to provide the updated #11 as a new post rather than change the original. I do not know what your actual questions are for points 5 and 6 or maybe I must Goto another forum to figure this out? (perhaps I Resume Next question instead)

[mc84excel]

It would be simple to provide the updated #11 as a new post rather than change the original. I do not know what your actual questions are for points 5 and 6 or maybe I must Goto another forum to figure this out? (perhaps I Resume Next question instead)

LOL

(I prefer thinking of the post references as calls to other subs rather than GoTos! )

[mc84excel]

UPDATE:This summary is outdated. See the last post for the latest version.

Updated summary below. As requested by Izandol.


DISADVANTAGES:

1. Can't hold values after sub ends (FALSE)
2. Need to declare the UDT in every sub that makes use of the UDTs elements (FALSE)
3. Can't declare new instances of a Type (Unlike Redim Preserve on Arrays) (FALSE)
4. Speed/Performance impact (TRUE. But.... Minor overhead. Nothing to worry about)
5. Difficult to use in an Add-In? (e.g. see http://stackoverflow.com/questions/1...-from-an-addin )
6. Difficult to pass in Arrays? (e.g. see http://www.vbaexpress.com/forum/show...r-Defined-Type)
7. Difficult to determine whether value assigned to UDT element or not (TRUE. But.... No more than a variable of any other type)
8. No control over values assigned to elements of a Type (TRUE Use Classes instead)
9. Can only hold variables, can't process code (TRUE. But... But neither can standard variables)

ADVANTAGES:

1. Can logically group variables together
2. Can have multiple elements passed by one variable (Arrays do too. But it's easier to read Car.Make instead of varArray(5))
3. Intellisense when writing code

[Kyle123]

6. False, It's nothing to do with arrays particularly, the message means what it says on the tin, you can't coerce a UDT into a Variant datatype like that, consider:

Public Type Car
    Make    As String
    Model   As String
    Price   As Currency
    Km      As Long
End Type

Sub test()
Dim g As Variant
Dim s As Car
g = s
End Sub

The biggest disadvantage here is that you can't put a variable of type UDT into a collection, this is the killer for me.

Re using arrays, you can always just use an enum to make it more readable and easier to manage:

Public Enum e_Car
    Make = 1
    Model = 2
    Price = 3
    Km = 4
End Enum

Sub test()
Dim cars As Collection: Set cars = New Collection
Dim x As Long
Dim Car(1 To 4) As Variant

    For x = 1 To 3
        Car(e_Car.Model) = "Fiesta"
        Car(e_Car.Make) = "Ford"
        Car(e_Car.Price) = x * 5
        Car(e_Car.Km) = x * 100
        cars.Add Car
    Next x
    
    Debug.Print cars(1)(e_Car.Price)
    Debug.Print cars(2)(e_Car.Price)
End Sub

To be honest though, I'd normally just use a class since they're easy to manage, can be stuffed in a collection and give you more control

[Kyle123]

Very simple (and lazy) example using classes:

Class Car:

Public Make As String
Public Model As String
Public Price As Currency
Public KM As Long

Class Cars:

Private cCars As Collection

Private Sub Class_Initialize()
    Set cCars = New Collection
End Sub

Public Function Index(i As Long) As Car
    Set Index = cCars(i)
End Function

Public Function Add(Make As String, Model As String, KM As Long, Price As Currency) As Car
    Dim c As Car
    Set c = New Car
    
    c.Make = Make
    c.Model = Model
    c.KM = KM
    c.Price = Price
    
    cCars.Add c
    
    Set Add = c
    
End Function

Normal Module:

Sub test()
Dim c As Cars
Set c = New Cars

c.Add "Ford", "Fiesta", 55, 22
Debug.Print c.Index(1).Model
Debug.Print c.Index(1).Make

End Sub

[mc84excel]

Updated summary below. Only Disadvantage #1 is not proved/disproved.


ADVANTAGES:

1. Can logically group variables together
2. Can have multiple elements passed by one variable (Arrays do too. But it's easier to read Car.Make instead of varArray(5))
3. Intellisense when writing code

DISADVANTAGES:

1. Difficult to use in an Add-In? (e.g. see http://stackoverflow.com/questions/1...-from-an-addin )
2. Speed/Performance impact (TRUE. But.... Minor overhead. Nothing to worry about)
3. Difficult to determine whether value assigned to UDT element or not (TRUE. But.... No more than a variable of any other type)
4. Can only hold variables, can't process code (TRUE. But... But neither can standard variables)
5. No control over values assigned to elements of a Type (TRUE Use Classes instead)

MYTHS:

1. Can't hold values after sub ends (FALSE)
2. Need to declare the UDT in every sub that makes use of the UDTs elements (FALSE)
3. Can't declare new instances of a Type (Unlike Redim Preserve on Arrays) (FALSE)
4. Difficult to pass in Arrays? (FALSE)