BY CATEGORY▼
VBA CATEGORIES▼
VBA - CLASSES AND STRUCTURES VIDEOS▼
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:
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:
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.
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
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!
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.
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.
Thank you, Andrew. Now I see! It was easy.
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.
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!)
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.
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!