VBA - classes and structures videos | Excel VBA Part 34 - Type Declarations

Posted by Andrew Gould on 13 October 2014

The Type statement in VBA allows you to define your own static data structures which you can then use in your variable declarations. This video explains how to declare a type, how to employ the type in variable declarations, how to read to and write from the variable, as well as a couple of fun features such as using enumerations within a type declaration and nesting types.

You can increase the size of the video:

Full screen mode for YouTube

You can view the video in full screen mode as shown on the left, using the icon at the bottom right of the frame.

You can also increase the quality of the video:

Changing resolution

You can improve the resolution of the video using another icon at the bottom right of the frame. This will slow down the connection speed, but increase the display and sound quality. This icon only becomes visible when you start playing the video.

Finally, if nothing happens when you play the video, check that you're not using IE in compatibility view.

This page has 3 threads Add post
18 Aug 19 at 14:33

Hi Andrew

Love the way you teach and the videos, they are always my go to point and have allowed me to do some great things!

My question is on using User Defined Type Declarations with class modules (specifically property statements), I have a large number of private fields in my class module (SupplierASearchString, SupplierAWorksheet, SupplierBSearchString, SupplierBWorkSheet etc etc). I am thinking of trying to simplify this by using User Defined Types (UDT), thus allowing me to have a single Private Field per supplier declared using my UDT.

It would appear that you can not declare property statements for the individual elements of a UDT.  Not all of my elements are set at the same moment in the procedures that i am running, would this mean that UDT are probably not the best approach or am i missing something fundimental with regards to UDTs? 

 

Many thanks 

 

Dave Blake MAAT

19 Aug 19 at 14:02

Hi Dave,

You might it helpful to read this post first https://stackoverflow.com/questions/975982/user-defined-type-udt-as-parameter-in-public-sub-in-class-module-vb6

The TL;DR version is that you can't do what you're attempting.  You could accomplish this using two different class modules.  The first class module will simulate what your type does, call it SupplierType for example:

'SUPPLIER TYPE CLASS MODULE
Option Explicit

Public SupplierASearchString As String
Public SupplierAWorksheet As String
Public SupplierBSearchString As String
Public SupplierBWorksheet As String

You can then use another class module which has a single property whose type is the SupplierType class.  Call this class module SupplierClass for example:

'SUPPLIER CLASS MODULE
Option Explicit

Private pSupplier As SupplierType

Private Sub Class_Initialize()
    Set pSupplier = New SupplierType
End Sub

Public Property Get Supplier() As SupplierType
    Set Supplier = pSupplier
End Property

You can then create a regular module which has code similar to this:

Option Explicit

Sub TestSupplier()

    Dim s As SupplierClass
    
    Set s = New SupplierClass
    
    s.Supplier.SupplierASearchString = "supplier A"
    
End Sub

I hope that helps!

20 Aug 19 at 18:09

Hi Andrew

Many thanks for your response, I don't really need property statements in my current project anyway as it doesn't require any fancy validation, so passing to (& reading from) the field will work fine and the benefits of making my project more readable outway the limitations!

I can see me using UDTs a lot in my projects going forward, especially when combined with enumerations.

Best Regards

Dave

PS: I would love to see a future video around the principles of structuring larger projects, I realise that every project is different but I still can't decide if it is best to have lots of short modules and classes or have fewer but longer modules and classes.  I think I might have a look at the Flappy Owl blogs to see how you structure your projects.

Andrew G  
21 Aug 19 at 07:55

You're welcome!

When it comes to structuring a project I think the length of the modules and classes is mostly determined by the complexity of the entity you're trying to model; form follows function.  You'll find a combination of very short and quite long classes in the Flappy Owl example.  In the interest of getting things done, my advice would be not to worry about it too much, too early (premature optimisation is the root of all evil).  If you find that your classes become unwieldy, you can always refactor later.

01 Jul 19 at 11:29

Thank you, Andrew. Now I see! It was easy. 

01 Jul 19 at 20:09

You're welcome Alexander!

28 Jun 19 at 10:10

Hello, dear Andrew.

I do not understand what is a "correct order" in type declaration? The meaning of it avoids me for some reason. 

Please, 

Help!

Alexander. 

01 Jul 19 at 09:42

Hi Alexander, I'm not quite sure what you mean, is this something I mentioned in the video?  If so please can you let me know where and I'll see if I can remember what I was talking about (this video was posted in 2014 so it's been a while!)

01 Jul 19 at 10:50

Hi Andrew, in the video above "VBA - classes and structures videos | Excel VBA Part 34 - Type Declarations", (13min 27sec) you were saying about "The order of declarations" and what happens when I declare types in defferent order. You changed  the order of declaration of Types (Address and Contact) and sub stoped work. And I wonder what that order of declaration should by. 

Sorry for my stupidity 

and thank you very much!

Alexander. 

Andrew G  
01 Jul 19 at 11:26

Ok, I see what you mean!  In the example shown in the video we declare the Address Type first, followed by the Contact Type.  The Contact Type references the Address Type and so the Address Type must be declared first.

I hope that makes sense!