Have you ever thought about the main purpose of Visual Basic for Applications?
In Excel VBA Programming for Dummies, Excel authority John Walkenbach provides the following interesting answer to this question:
VBA's main purpose is to manipulate data.
For purposes of this VBA tutorial, the key term within the above statement is “data”. If the main purpose of Visual Basic for Applications is to manipulate data, having a good understanding of what are the different VBA data types is essential for mastering VBA.
My purpose with this post is to help you understand VBA data types and how to work with them. In this guide, I cover and thoroughly explain the most relevant aspects of the different VBA data types, including the following:
Table of Contents
In this particular post, I don't cover the topic of variable declaration in detail. This is covered in this blog post about variable declaration.
How Data Is Stored And Why VBA Data Types Are Important
Data is generally stored in the computer's memory. If you have a basic understanding of computers, you're probably familiar with how this works.
However, for VBA purposes, there is an important distinction to be made between objects and variables. As Walkenbach explains in Excel VBA Programming for Dummies:
- Some data is stored in objects.
- Other data is stored in variables.
I explain what “objects” and “variables” are in this VBA Tutorial for Beginners. To summarize:
- An object is what is manipulated by Visual Basic for Applications.
Some examples of objects are Excel workbooks, worksheets, cell ranges and cells.
- A variable is a storage location paired with a name. You generally use variables to represent a particular value. In other words, variables act as placeholders for values.
You can create variables in Visual Basic for Applications by declaring them. You determine the name and characteristics of any variable you create. One of the characteristics that you can determine is the VBA data type.
The ability to determine the characteristics of the variables you create in VBA is probably the main reason why understanding VBA data types is important. Let's see why this is the case:
VBA data types determine the way in which data is stored in the memory.
There are several VBA data types. These data types have different nominal allocation requirements. This means that different types use a different amount of bytes.
The general rule that you should apply when determining which data type to use is set forth by John Walkenbach in Excel VBA Programming for Dummies:
In general, choose the data type that uses the smallest number of bytes but can still handle all the data you want to store (…).
The reason for this is that there is an inverse relation between execution speed and the amount of bytes used by the relevant data. In other words, the more bytes your data uses, the slower your VBA application runs.
As this makes it clear, in order to be able to make appropriate decisions about the VBA data types that you want to use, you must understand the basic characteristics of each of the main types. Mastering this topic is very important, particularly as you start creating and developing more complex VBA applications. The main reason for this is that inadequate choices of VBA data types can result in slower execution of those applications and, in general, an inefficient use of the memory.
Introduction To Why You Shouldn't Always Allow VBA To Handle Data Types Automatically
Programming languages are usually classified as strongly typed or weakly typed.
Strongly typed languages usually require that you define the data type for every variable that you use. Visual Basic for Applications isn't one of these languages. Therefore, VBA is able to handle the details related to data types automatically.
More precisely, if you don't declare the VBA data type for a particular variable, Visual Basic for Applications uses the default type. The default VBA data type is called Variant, and I explain it below.
The question is:
Should you allow Visual Basic for Applications to automatically set the VBA data types for the variables you use?
Generally, no. You should get used to declaring the VBA data types of the variables you create always.
However, the answer to the question isn't as straightforward as the statement above may make it seem.
Allowing Visual Basic for Application to automatically deal with VBA data types for variables has advantages. The main advantage is, evidently, that by allowing VBA to handle data types, you don't have to do it yourself. This may sound more convenient, but wait…
As I mentioned above, inappropriate choices of VBA data types can result in problems down the road, including slower application execution. More precisely, if you always rely on the default Variant data type, you'll likely start noticing that your VBA applications run relatively slow and require more memory than necessary. I explain the reason for this below.
Therefore, if you're committed to becoming a powerful VBA user, you must have a good grasp of VBA data types and, when required, be able to choose the most appropriate one.
So, should you always deal with VBA data types yourself?
Generally, declaring the variables that you use in order to determine their VBA data type explicitly is a good practice. However, if you don't want to do this, you can carry out your own cost-benefit analysis considering the following criteria:
- As explained in Excel VBA Programming for Dummies, “letting VBA handle your data typing results in slower execution and inefficient memory use.”
- Despite the above, Microsoft explains how using the Variant data type allows you to handle data more flexibly.
- How noticeable are the issues of slower execution and inefficient memory use generally depends on the size and complexity of the relevant VBA application. Therefore, in small applications or applications that don't use many variables, allowing Visual Basic for Applications to handle the VBA data types directly shouldn't generate big issues.
- However, when you're working with big and/or complex applications, letting VBA deal with data types automatically isn't very advisable. In these cases, you want to conserve as much memory as possible. A good knowledge of VBA data types is essential in achieving an efficient use of memory when developing VBA applications.
In the words of John Walkenbach:
Letting VBA handle data types may seem like an easy way out – but remember that you sacrifice speed and memory.
In addition to the above, as explained in Mastering VBA for Microsoft Office 2013, not declaring the variables makes your VBA code harder to read and debug.
There are additional reasons to always declare your variables when working with Visual Basic for Applications. Let's take a look at 2 further reasons, explained by Walkenbach in Excel 2013 Power Programming with VBA and Excel VBA Programming for Dummies.
Reason #1: Possible Misinterpretation Of Intended VBA Data Type When Using Variant VBA Data Type
According to Mastering VBA for Microsoft Office 2013, one of the disadvantages of using the Variant VBA data type is that VBA can misinterpret the data sub-type that you intended. This can lead to “rather obscure bugs”.
Let's take a look at a very simple example, involving strings and numbers, to illustrate this point.
Take a look at the following piece of very simple VBA code.
This Excel VBA Data Types Tutorial is accompanied by an Excel workbook containing the data and macros I use (including the Variant_Concatenation macro above). You can get immediate free access to this example workbook by subscribing to the Power Spreadsheets Newsletter.
The 3 main statements of the Variant_Concatenation macro above carry out the following actions:
- “ExVar = “1”” assigns 1 to the variable ExVar. Since ExVar hasn't been declared, it is of the Variant VBA data type.
- “ExVar = ExVar + ExVar + ExVar” performs an operation. The + operator is applied to the variable ExVar.
- “MsgBox ExVar” displays a dialog box with the expression that is currently stored by the variable ExVar.
The question is, what is the value displayed in the message that appears within the dialog box at the end of the Variant_Concatenation macro?
At first glance, it may appear that the dialog box should display the number 3. After all, the second line seems to be adding ExVar three times, and ExVar has previously been assigned 1. 1 + 1 + 1 = 3, right?
Even though the reasoning above makes sense, the rules that apply in Visual Basic for Applications can be slightly different to what we're used to. Let's take a look at the actual dialog box that is displayed when I run the Variant_Concatenation macro:
111? Where's the 3 that we were expecting?
If you're familiar with VBA, you may have noticed some of the issues that the piece of VBA code that appears above has. Note how, when assigning 1 to the variable ExVar, the number 1 is enclosed in quotation marks (“”).
This means that the number 1 is actually a string instead of a number. When you're working with variables that contain strings and you use the + operator, Visual Basic for Applications concatenates all the strings.
Therefore, if “1” is a string, “1 + 1 + 1” is not equal to 3. The correct answer, in that case, is the one that appears in the dialog box above: 111.
Microsoft explains this particular characteristic of the Variant VBA data type by stating that, when a Variant variable contains digits, the interpretation depends on the context. Therefore, depending on such context, those digits may be interpreted as either a string (as in the example above) or the actual value.
This particular problem is not caused exclusively by the use of the Variant VBA data type. The assignment of the variable could've probably been better structured. Nonetheless, this is a further reason to avoid relying on the Variant data type always.
If you still want to rely on the Variant VBA data type, there are ways to determine the VBA data sub-type of any Variant variable. I show how you can apply these methods to the Variant_Concatenation macro in a section below.
Reason #2: Shortcut For Inserting Variables In VBA Code When Working With Declared Variables
Let's take a look at the following piece of VBA code. The purpose of this macro is to delete blank rows in Excel. Notice how the variable iCounter is properly declared.
Imagine that you're creating the first version of this macro. And you're typing at the following point:
Theoretically, you must type the whole name of the variable: “iCounter”. However, since the variable has been declared at the beginning of the Sub procedure, you can use the keyboard shortcut “Ctrl + Spacebar” once you've written the first couple of characters (usually 2 or 3 are enough). When you do this, the Visual Basic Editor does one of the following:
- If it knows exactly to what particular word (this applies to variables, reserved words or functions) you're referring to, it completes the entry.
This is what happens in the case above. The following image shows what happens once I use the “Ctrl + Spacebar” shortcut:
- If it isn't sure about what word you're referring to, it displays a list of possible words from which you can select.
For example, let's assume for a second that the Delete_Empty_Rows macro that appears above has 2 declared variables: iCounter and iCounter1. In that case, the Visual Basic Editor looks as follows:
How To Remind Yourself To Declare VBA Data Types
You may be convinced that it is a good idea to always declare VBA data types when creating variables. However…
We all forget things sometimes.
Therefore, it's not surprising that, from time to time and despite our best efforts to the contrary, we forget to determine the VBA data type of a variable. Additionally, since Visual Basic for Applications is able to handle VBA data types automatically, you may not even notice this happening.
Fortunately, you can force yourself to declare all the variables that you use. To do this, you simply need to use the Option Explicit statement.
When enabled, the Option Explicit statement requires that you explicitly define all the variables in the VBA module where that particular statement appears.
How do you enable the Option Explicit statement?
Easy, simply type “Option Explicit” at the top (before any other code) of the relevant VBA module. You only need to do this once per module. However, you'll need to include the statement in any separate modules to which you want the Option Explicit option to apply.
If you want to take it a step further, you can have the Visual Basic Editor automatically insert the Option Explicit statement at the beginning of any future VBA modules. You can do this by customizing the code settings of the VBE in order to enable the Require Variable Declaration option. I explain how to do this in this VBE tutorial.
If the Option Explicit statement is enabled, you'll simply not be able to run VBA code that contains undeclared variables.
Enabling the Option Explicit statement has an additional advantage: it helps you to spot typos or misspellings that, otherwise, might have been difficult to see. Let's see how this works in practice by checking a macro that deletes empty rows.
For this example, I'll use the macro whose VBA code appears in the image below, named Delete_Empty_Rows_2. I explain this macro in detail (and show how it works in practice) in this post.
In this particular macro, 2 variables are declared at the beginning: aRow and BlankRows. Both variables are of the Range VBA data type.
Now, let's focus on the BlankRows variable. The image below shows how this particular variable is used several times in this particular Sub procedure.
Imagine that, while typing the VBA code, a typo somehow manages to squeeze in (just one). Instead of typing “BlankRows” (the appropriate name), you type “BlamkRows” (similar, but not the same).
As you may imagine, such typos may be difficult to spot in some situations. If you don't notice the mistake, the macro may not work as originally intended.
However, if you have enabled the Option Explicit statement, Visual Basic for Applications displays a prominent warning. Take a look at the screenshot below and notice how easy is to notice that “BlankRows” is misspelled.
Variant VBA Data Type
Variant is the default VBA data type. In other words, this is the data type that Visual Basic for Applications uses when you don't determine the type yourself at the moment of declaring a variable. You can, however, also declare a Variant variable explicitly.
In Excel VBA Programming for Dummies, John Walkenbach likens the Variant VBA data type with a chameleon. In other words, data that is of the Variant type “changes type depending on what you do with it.” This allows you to work with data more flexibly.
This sounds great! Who wouldn't want this?
Not having to worry about VBA data types sounds great in theory but isn't as simple in practice. Variant is, as a general rule, not the most efficient data type. This inefficiency is caused, funnily enough, by its chameleon-like characteristics.
More precisely, in order for Variant to behave like a chameleon and change of type depending on the context, Visual Basic for Applications must carry out certain checks for determining like which type should Variant behave. As you can imagine, carrying out these checks repeatedly requires more time and memory.
As explained in Mastering VBA for Microsoft Office 2013, the Variant VBA data type requires more memory than any of the other data types, excluding very long strings. More precisely:
- Variant variables with numbers require 16 bytes of memory.
- Variables of the Variant data type with characters usually require 22 bytes of memory plus the memory required by the string.
And this is one of the reasons why I generally suggest that you get used to declaring the VBA data type of your variables and use other VBA data types different from Variant. When you do this, Visual Basic for Applications doesn't need to be constantly carrying checks (as it does with Variant). This usually results in faster, snappier and better VBA applications, and more efficient memory management.
Let's take a look at a few additional characteristics of the Variant VBA data type:
- When it comes to numeric data, you can store numbers within the following ranges:
For negative numbers: -1.797693134862315E308 to -4.94066E-324.
For positive numbers: 4.94066E-324 to 1.797693134862315E308.
- Variant's ability to handle different types of VBA data isn't absolute. In particular, Variant variables can't contain fixed-length string data.
I explain what fixed-length string data is below. In that same section, I also explain the String data type, which is the one you'll have to use in such cases.
- Variables of the Variant VBA data type can contain 4 additional special values:
Value #1: Empty, meaning that no value has been assigned to the variable. You can see an example of this below.
Value #2: Error, which is used for purposes of indicating errors in the relevant procedure.
Value #3: Nothing, which you can use when disassociating a variable from an object it was previously associated to.
Value #4: Null, which indicates that the variable contains no valid data.
Byte VBA Data Type
The Byte VBA data type is the one that requires less memory: only 1 byte.
Variables whose VBA data type is Byte can be used to store numbers between 0 and 255.
Boolean VBA Data Type
If you've ever studied Boolean algebra, you may remember that the states of the variables are TRUE and FALSE.
The Boolean VBA Data Type follows this logic. In other words, variables whose VBA data type is Boolean can only be set to one of the following 2 values:
In general Boolean algebra, TRUE and FALSE are usually denoted by 1 and 0 respectively. However, in Visual Basic for Applications, conversions between Booleans and numeric VBA data types work slightly different:
- When converting a Boolean variable to a numeric VBA data type, TRUE becomes –1 and FALSE becomes 0.
- When converting a numeric VBA data type into a Boolean, 0 becomes FALSE and all other values (regardless of whether they're negative or positive) become TRUE.
Boolean variables require 2 bytes of memory.
Currency VBA Data Type
As you'd expect, the Currency VBA data type is generally used in connection with monetary matters. However, as I explain below, you can use it for other purposes as well.
The Currency VBA data type is exact. The Single and Double data types that I explain below are rounded.
Currency variables can be used to store both positive and negative numbers. They're stored as numbers in an integer format that is scaled by 10,000. As a consequence, these variables give fixed-point numbers whose length is up to:
- 15 digits to the left side of the decimal point.
- 4 digits to the right side of the decimal point.
As a consequence of the above, this data type allows for a range of values between -922,337,203,685,477.5808 and 922,337,203,685,477.5807.
Due to the fact that the Currency VBA data type is exact and these variables give fixed-point numbers, Currency is particularly useful for monetary calculations or fixed-point calculations where accuracy is very important.
The Currency data type takes up 8 bytes of memory.
Date VBA Data Type
This is another VBA data type whose name is self-explanatory.
Indeed, you won't be surprised to confirm that Date variables can be used to store values that represent dates, times or both.
However, if you've been working with Excel for a while, you may have noticed that the way Excel and Visual Basic for Applications work with numbers isn't necessarily the easiest to understand. Therefore, I provide a short introduction to this topic below.
As explained in Mastering VBA for Microsoft Office 2013, “VBA works with dates and times as floating-point numbers”. Let's take a quick look at what this means:
Introduction To Floating-Point And Fixed-Point Numbers
Floating-point is a way of representing numbers. Under this formula, a number is represented in an approximate way to a certain number of significant digits. This is then scaled using an exponent.
However, the most critical point to understand is that the reason why this formula is called “floating-point” is due to the fact that the decimal point “floats”.
Computers can also store numbers as fixed-point numbers. You can see an example of this in the Currency VBA data type explained above. In the case of fixed-point numbers, the decimal points doesn't “float”. It remains fixed in a certain location and, therefore, the number has always a fixed number of digits after or before the decimal point.
Working with floating-point numbers, generally, demands more computational resources. Therefore, the suggestion made in Mastering VBA for Microsoft Office 2013 is to use fixed-point numbers “whenever practical”.
Now that you have a basic understanding of floating-point and fixed-point numbers, let's take a closer look at what the Date VBA data type can do.
In general terms, Date variables can store values representing:
- Dates between January 1, 100 and December 31, 9999.
- Times between midnight (00:00:00) and 23:59:59.
These values are stored as floating-point numbers, as follows:
- The date appears to the left of the decimal point.
- The time appears to the right of the decimal point.
The following are examples of how variables of numeric VBA data types are converted to the Date type:
- 0 represents midnight.
- 0.5 is midday.
- Negative integers are dates before December 30, 1899.
Date VBA variables require 8 bytes of memory.
Decimal VBA Data Type
Decimal is one of VBA's numeric data types.
More precisely, the Decimal VBA data type can be used to store integers scaled by a power of 10. This scaling factor varies depending on how many digits there are to the right side of the decimal point. The maximum number of these digits that a Decimal variable can hold is 28.
Considering the above, the following are the largest and smallest values for a Decimal variable:
- If there are no decimal places at all: +/-79,228,162,514,264,337,593,543,950,335.
- With the maximum number of decimal places (28), the largest value is +/-7.9228162514264337593543950335 and the smallest (excluding 0) is +/-0.0000000000000000000000000001.
In other words, the Decimal VBA data type gives you the largest amount of digits in order to represent a particular number. Therefore, it's more appropriate for cases where you are performing calculations with large numbers that need to be very precise and can't be subject to rounding errors.
The precision of the Decimal data type, comes at a cost in the form of a large memory requirement. The Decimal VBA data type requires 12 bytes, which is larger than the other numeric data types.
As explained by Microsoft, you can't declare the Decimal VBA data type directly (just as you do with the other data types). Strictly speaking, Decimal is a sub-type of Variant. Therefore, in order to use Decimal, you must use the CDec conversion function.
Double VBA Data Type
The Double VBA data type is one of the non-integer numeric data types. This means that, just as decimal, it can be used to hold both integers and fractions.
More precisely, you can use Double to store floating-point numbers within the following ranges:
- For negative numbers: -1.79769313486231E308 to -4.94065645841247E-324.
- For positive numbers: 4.94065645841247E-324 to 1.79769313486232E308.
I provide a brief introduction to floating-point numbers above. You may however be wondering, why is this type of VBA data called double?
“Double” stands for “double-precision floating-point”. This makes reference to the number format which determines how the computer handles the number. There is also a Single VBA data type (explained below).
Double VBA variables require 8 bytes of memory.
Integer VBA Data Type
You can use the Integer VBA data type for storing integers between -32,768 to 32,767.
Integer variables only require 2 bytes. Due to its low memory requirements, the Integer VBA data type is usually the most efficient and better performing option for purposes of storing integers that fall within its range.
As explained by Microsoft, you can also use the Integer data type for purposes of representing enumerated values. Enumerated values:
- Usually contain a finite set of unique natural numbers. Each of these numbers has a particular meaning.
- Are commonly used for purposes of selecting among different options.
Long VBA Data Type
“Long” makes reference to “Long Integer”. As implied by its name, you can use the Long VBA data type for storing integer values that are within a “longer” range than the range of the Integer data type.
More precisely, by using the Long VBA data type you can store numbers between -2,147,483,648 and 2,147,483,647. If this range is still not enough for your purposes, you may want to use the Double VBA data type.
Long variables require 4 bytes of memory. As you'd expect, this is more than Integer variables (2), but less than Double variables (8).
Object VBA Data Type
You can use the Object VBA data type for purposes of storing addresses that refer to objects. In general, Object variables are a convenient way to refer to objects.
Variables of the Object type take up 4 bytes of memory.
Single VBA Data Type
I anticipated the existence of the Single VBA data type when introducing the Double type above. “Single” refers to “single-precision floating-point”, the number format that determines how the computer handles the number.
You can use the Single VBA data type for storing numbers within the following ranges:
- For negative values: -3.402823E38 to -1.401298E-45.
- For positive values: 1.401298E-45 to 3.402823E38.
Single variables require 4 bytes, half of those required by the Double VBA data type (8).
String VBA Data Type
For purposes of programming, a string is generally defined as a sequence of characters that represents the characters themselves (not a numeric value or other similar thing). Within Visual Basic for Applications, the String VBA data type is generally used to store text. However, this doesn't mean that you should only use letters within String variables. In addition to letters, String variables can contain numbers, spaces, punctuation and special characters.
There are 2 different kinds of Strings. The amount of characters and memory required varies depending on the type.
Type #1: Variable-Length Strings
Variable-length String variables can contain anything from 0 up to approximately 2 billion characters. They take up 10 bytes of memory plus the memory that is required for the string itself.
Type #2: Fixed-Length Strings
Fixed-length String variables can contain between 1 and approximately 64,000 characters. These particular String variables require the amount of memory required by the string.
According to Mastering VBA for Microsoft Office 2013, fixed-length String variables “are rarely used in most programming”. The main exception is when managing databases where a rule specifying a maximum string length applies.
You may wonder what happens if the data that is assigned to a fixed-length String variable is different from the fixed length. Visual Basic for Applications handles this matter differently depending on whether the data assigned is shorter or longer than the fixed length:
- If the data assigned is shorter, VBA adds trailing spaces in order to reach the fixed length.
- If the assigned data is longer, Visual Basic for Applications truncates the data after the fixed length is reached. For these purposes, characters are counted from left to right.
For example, if you assign the string “Tutorial” to a fixed-length String variable with a length of 3 characters, Visual Basic for Applications only stores “Tut”.
Other VBA Data Types
The above sections explain the most common VBA data types. From time to time, you may encounter some other data types, such as the ones I briefly introduce below.
LongLong VBA Data Type
The LongLong VBA data type is only valid on 64-bit platforms. This makes reference to how your computer is handling information.
According to tech website TweakTown, 92.8% of new Windows computers utilize 64-bit operating systems. You can find more information about the 32-bit and 64-bit versions of Windows here, including how to check which version your computer is running.
You can use the LongLong VBA data type to store numbers between -9,223,372,036,854,775,808 and 9,223,372,036,854,775,807.
LongLong variables require 8 bytes of memory.
LongPtr VBA Data Type
LongPtr isn't (strictly speaking) a VBA data type. More precisely, the way LongPtr behaves depends on which platform is the relevant procedure running.
- In 32-bit platforms, LongPtr becomes Long.
- In 64-bit platforms, LongPtr becomes LongLong.
Both the range of values that can be stored using a LongPtr variable and the memory requirements vary accordingly.
As explained by Microsoft, one of the main uses of LongPtr is for pointers and handlers.
User-Defined VBA Data Types
Visual Basic for Applications allows you to create your own VBA data types. As you'd expect, these data types are known as user-defined data types.
In order to create a user-defined data type, you use the Type statement. These data types can contain 1 or more elements from the following:
- Data types.
- User-defined data types that have been defined previously.
User-defined VBA data types are highly dependent on their different components. For example:
- The number of bytes required by a particular user-defined VBA data type depends on its elements.
- The range of each of those elements is the one that applies to the relevant data type.
I may explain further details of user-defined VBA data types in future VBA tutorials. Please make sure to enter your email address below if you want to join the Power Spreadsheets Newsletter and be notified whenever I publish new material.
How To Decide Which VBA Data Type To Use
Now that you know about the main different VBA data types, you may be wondering…
How do I decide which VBA data type to use for a particular variable?
You already know the basic rule for choosing data types proposed by John Walkenbach. Under this general rule, your choice of data type is determined by the answers to the following 2 questions:
- Which VBA data type(s) is(are) able to handle the data that you want to store?
- Out of the VBA data type(s) that can handle the data you want to store, which data type uses the smallest number of bytes?
These guidelines may still feel a little bit general. Therefore, below are some general suggestions provided by Richard Mansfield in Mastering VBA for Microsoft Office 2013:
- If the relevant variable will only contain logical values (TRUE and FALSE), use the Boolean VBA data type.
- If the variable will always contain a string, use the String VBA data type.
- If the variable will contain an integer use either the Integer or the Long VBA data type. The choice between Integer and Long depends on how big the relevant numbers are.
Remember that neither Integer nor Long variables can be used to store fractions. Which takes us to the following point…
- If the variable you're declaring may contain fractions, use the Single or Double VBA data types. The decision to choose one or the other depends on the range of values the variable may store.
- If you'll be using the variable in operations where you can't have rounding errors (you require no-rounding fractions), use the Currency or Decimal VBA data types. As in the previous cases, the exact choice of variable depends on the size of the exact numbers you'll be storing.
You'll notice that, in several of the above cases, which data type you should use depends on the range of values that you want the variable to be able to handle. Learning how to choose the appropriate VBA data type (considering factors such as the range) is critical and, as computers become more powerful and VBA develops, there may be further changes to the available data types.
For example, loop counters used to be declared using the Integer VBA data type, which can't be larger than 32,767. Recent versions of Microsoft Excel can have 1,048,576 rows. This clearly exceeds the range that Integer variables can handle. Therefore, a more appropriate choice is using the Long VBA data type.
As you practice with Visual Basic for Applications, you'll start becoming better and more comfortable deciding which VBA data type to use.
However, if you're still not sure how these rules apply to a particular situation, this is a case where the Variant VBA data type may be of help. Let's take a look at…
How To Find Out The VBA Data Sub-Type Of A Variant Variable
Remember that the Variant VBA data type behaves like a chameleon. Variant changes its sub-type depending on what particular action you're carrying out with it.
Despite the downsides of relying on the Variant VBA data type that I have explained throughout this VBA tutorial, Variant can be quite helpful for purposes of testing a particular variable and determining what is the most appropriate data type to use.
Let's take a look at 3 ways you can do this. In all examples, I use the Variant_Concatenation macro that I used above to illustrate how the Variant data type may result in possible misinterpretations of your intended VBA data type.
This Excel VBA Data Types Tutorial is accompanied by an Excel workbook containing the data and macros I use. You can get immediate free access to this example workbook by subscribing to the Power Spreadsheets Newsletter.
Testing A Variable Using The Variant VBA Data Type
I may cover the topic of debugging in future VBA tutorials. In this section I simply show you how to use the Locals Window and the Step Into command for purposes of determining which particular data type to use.
You can do this in the following 6 simple steps, as explained in Mastering VBA for Microsoft Office 2013.
Step #1: Display The Locals Window
For purposes of this process, the Locals Window of the Visual Basic Editor must be visible. This window displays all the variables in the relevant procedure, as well as their values.
You can usually see the Locals Window at the bottom of the VBE.
If you can't see the Locals Window in your VBE, you can ask the Visual Basic Editor to display it by clicking on “Locals Window” within the View menu.
Step #2: Step Into The Relevant VBA Sub Procedure
You can step into a procedure by using the “F8” keyboard shortcut or by choosing “Step Into” in the Debug menu of the Visual Basic Editor.
Once you've stepped into the procedure, the Visual Basic Editor takes you to the first line of code in the macro.
Step #3: Step Through Procedure And Find Out Variant Sub-type of Variable
Every time you click the Step into command or the “F8” keyboard shortcut, the Visual Basic Editor executes a line of code and steps into the next. Do this for purposes of stepping through the VBA Sub procedure and finding out what is the Variant VBA sub-type that Visual Basic for Applications automatically assigns to the relevant variable.
The following 2 screenshots show how this works in the case of the Variant_Concatenation macro that's been used as example:
- Notice how, initially, the ExVar variable contains the special value Empty. This means that the variable hasn't been initialized.
- In the following screenshot you can see how the ExVar variable is of the String sub-type just one step later.
Bear in mind that just because a variable of the Variant VBA data type is behaving in a certain way, it doesn't mean that this is the most appropriate data type to use. Remember that one of the possible downsides of using this particular data type is that the Visual Basic Editor may misinterpret your intended VBA data type.
Step #4: Test The Procedure
Step a couple of times into the procedure following the steps I described above. Your purpose is to determine that the variable is being assigned the same VBA data sub-type in a consistent manner. Once you've determined that this is the case, you can proceed to the step #5.
Step #5: Declare Variable With VBA Data Type
Once you've determined that the relevant variable is behaving appropriately and that it is being assigned the same data sub-type in a consistent manner, declare the variable using the VBA data type you've found.
Step #6: Test VBA Code
Once you've determined the VBA data type that you consider appropriate for the variable, test your VBA code in order to make sure that the data type is the right one.
Finding Out The VBA Data Sub-Type Of A Variant Variable Using The TypeName Function
Visual Basic for Applications allows you to determine the VBA data type of a variable by using the TypeName function. When applied, the TypeName function returns a string displaying the VBA data sub-type information of a particular Variant variable.
Let's see how you can apply the TypeName function to the Variant_Concatenation macro.
For these purposes, I start with the VBA code of the original macro that I use in the previous examples:
And I add several message boxes that display the VBA data type of the ExVar variable at different stages of execution of the macro. The new macro is called “Variant_Concatenation_TypeName”. The relevant statements (which are highlighted in the image below) are of the form “MsgBox TypeName (varname)”, where:
- “MsgBox” makes reference to the MsgBox function.
- “varname” is the Variant variable whose VBA data sub-type you want to find out (in this case ExVar).
You already know that, since the ExVar variable isn't declared, its VBA data type is Variant. Additionally, based on the previous section where we used the Step Into command for purposes of testing the variable, you know that the ExVar variable is not initialized at first (is Empty) and, after the assignment is made, it behaves like a string variable.
The expectations described above match what the message boxes display once the Variant_Concatenation_TypeName variable is executed. More precisely:
- The first message box to appear returns Empty, as expected.
- The second and third message boxes confirm that (now) the ExVar variable is of the String VBA data sub-type.
Finding Out The VBA Data Sub-Type Of A Variant Variable Using The VarType Function
You can also use the VarType function for purposes of finding out the VBA data type of a particular variable.
The way VarType works is very similar to the way the TypeName function works. More precisely, the VarType function returns an integer that indicates what is the VBA sub-type of a Variant variable. The following are the values that can be returned by VarType:
- 0: Empty.
- 1: Null.
- 2: Integer.
- 3: Long.
- 4: Single.
- 5: Double.
- 6: Currency.
- 7: Date.
- 8: String.
- 9: Object.
- 10: Error.
- 11: Boolean.
- 12: Variant. This particular value is only used with arrays.
- 13: Data access object.
- 14: Decimal.
- 17: Byte.
- 36: Variant containing user-defined types.
- 8192: Array.
The syntax of VarType is also very similar to that of TypeName. More precisely, the syntax of VarType is “VarType (varname)”, where “varname” is the Variant variable whose VBA data sub-type you want to find.
Therefore, I simply create a new macro called “Variant_Concatenation_VarType”. The VBA code is almost the same as that in the previous example (Variant_Concatenation_TypeName). The only difference is that, instead of using TypeName, I use VarType.
You probably expect that, when the Variant_Concatenation_VarType macro is executed, the first message box returns the value that corresponds to Empty, while the second and third message boxes display the value corresponding to String.
This is indeed what happens:
- The first message box to be displayed returns the number 0. This corresponds to Empty.
- The second and third message boxes display the number 8. This number makes reference to strings.
The main purpose of Visual Basic for Applications is to manipulate data. Therefore, in order to master VBA and macros, you must have a good understanding of what are the different VBA data types.
After reading this VBA tutorial you probably have a good understanding of the different VBA data types that you can use, and how to determine which type to use in each situation. Choosing which data type to use may seem awkward or a little bit difficult at first, but don't worry…
As with most aspects of Visual Basic for Applications, the more you practice, the better you'll become. Therefore, make sure you start using the knowledge about VBA data types that you've gained by reading this post in your day-to-day activities.
Books Referenced In This Excel Tutorial
- Mansfield, Richard (2013). Mastering VBA for Microsoft Office 2013. Indianapolis, IN: John Wiley & Sons Inc.
- Walkenbach, John (2013). Excel VBA Programming for Dummies. Hoboken, NJ: John Wiley & Sons Inc.
- Walkenbach, John (2013). Excel 2013 Power Programming with VBA. Hoboken, NJ: John Wiley & Sons Inc.