We define double and single quote characters as VBA constants. Quote characters are used often throughout various editing macros, so defining them as global constants saves us from needing to define them in each macro where they are used. The approach can be easily applied to create any other necessary global constants.
Thanks for your interest
This content is part of a paid plan.
Define constants for all macros
Some quantities are useful across many macros, but it is annoying to have to redefine them every time they're needed. If the values never change, we can define them specifically as constants. Moreover, if we do at the top of the module (a group of macros in the VBA usually listed in the left sidebar), we can use the constants in any macro within that module. We do not need to repeatedly declare the same constants throughout our macros when they are needed.
Fortunately, the main difference between global constants and those created inside a macro or function is simply where we place them in the macro (module) file.
What is a module?
When a macro is opened, the editor is showing a module. It contains all the previously created macros. Usually a default module is also opened when you tap Option+F11 in Word for Mac or Alt+F11 in Windows.
We're creating constants that are valid across all macros in a module, but they can also be modified (see below) to be valid across all modules in a project.
Defining constants
How do we define typical constants in a macro?
The basic notation is:
VBA strives to read more like English, so why the developers snipped off three characters of "Constant" is … dubious is too strong … questionable. Why not just lean into the benefits of VBA to make macros (secretly programming code) easier for regular users, but "Const" it is.
What do we do?
- Start with the Const keyword
- Give it a descriptive constant name which is SomeConstant above
- Give it a data type which is currently a fictional type of SomeType here
- Define the constant value (see below)
Many valid data types exist, but common ones in VBA are String, Range, Paragraph, Document, Integer, Long, etc. Any valid standard type (String, Integer, Long, and more) works as well as any valid VBA object type (Range, Paragraph, Document, and many more). My personal naming convention is to define constant names with a capital first letter.
Defining the constant value
Since the constant value cannot change while any macro runs, we cannot assign the value as a second step like we do with VBA variables. Let's work with an Integer type (includes counting numbers) to be clearer.
Remember using Dim is how we tell VBA that we're creating a variable. The variable assignment works because its value can change at any time while a macro runs, but the constant version causes an error because its value cannot change.
Thus, we must define the value at the same time we declare the constant. Fortunately, it's not difficult, just a tad messy. Immediately after the data type, just include a variation of = SomeFixedValue, but the value must be fixed. It cannot refer to a function or anything than needs an evaluation when a macro is run.
On the plus side, setting the constant value can refer to a previously defined constant, if needed, which is helpful at times.
This allows us to build some constants and also makes them easier to read (in most cases).
Double and single quote characters
As authors, double quotes appear by the thousands in dialog, so it would be super convenient to just have them defined with easily remembered constant names as opposed to something like, ChrW(8220).
See what I mean? The clumsy version works, but we can also trim our lawn with scissors if we want. I mean ... it works ... but we spend money for mowers to make it easier. Of course, we'll also include single quotes on the journey.
How do we define them and make them easy to use?
A straight single quote is easy. Since it isn't a double quote, we can just include it in double quotes like normal characters "'". We can also specify a straight double quote as two double quotes inside another pair of double quotes ““””.
That’s not confusing at all, right? [sarcasm off] I suppose it's not bad once you get used to it, but I won't or haven't because it’s clearer (to me) to just refer to quote characters by number. More importantly, neither of those includes "curly" left and right versions of single or double quotes, so we might as well solve both problems at the same time.
Older ways to get characters (incomplete)
A very old table ubiquitous character table is called "ascii" which Word adopted. It stores text numbers 0 through 9, upper and lowercase letters, some common punctuation, as well as some other characters. It was defined in 1961 and has been extended many times. Unfortunately, the various extended ascii tables are inconsistent across the computer world, but even the extended tables are inadequate for modern character set needs.
Many languages have a Chr(…) function to translate the numerical representation from the ascii number to the text characters we want to see on the screen. For example, straight single and double quotes are Chr(39) and Chr(34), respectively, but the "curly" left and right quotes have different values between Windows and Mac systems since they reside in different extended ascii tables. We previously created some double quote functions to make using them easier in VBA. Despite some information to the contrary, they are available when using Chr(…), but it just isn't necessary to resort to functions when more convenient constants exist.
A more common character scheme is called Unicode, and we can access Word's implementation of it also through a sibling function, ChrW(…). Unicode is more complicated than just a single table, but we will not delve into any details. We just need some common relatively standard character numbers.
Getting quotes in Word VBA
It's easier and more consistent to just use the more general ChrW(…) function. The respective numbers are:
- Straight double quote " → ChrW(34)
- Left double quote “ → ChrW(8220)
- Right double quote ” → ChrW(8221)
The character numbers are similar for single quotes.
- Straight single quote ' → ChrW(39)
- Left single quote ‘ → ChrW(8216)
- Right single quote ’ → ChrW(8217)
The ChrW(…) character values work on both Word for Mac and Windows. Most of the time, people will give the number in a base-16 system called "hexadecimal", but I like the decimal values as used above.
Define our quote characters
Using the above quote numbers with the constant definition style, we have:
Just copy and paste these constants at the top of your macro file (it pops up when you tap Option+F11 in Word for Mac or Alt+F11 in Windows) outside of any macro. We can create multiple projects and multiple modules within those projects, but we're trying to keep it simple here.
Global variables are frowned upon since any macro can change them, but these are fixed constants. They are the same regardless of where they are used. As such, defining them once makes perfect sense. The only real disadvantage is they are messy to define at one constant on a line, but we only need to do so once.
Adding quote characters
Since we're already defining a bunch of constant characters, we can think ahead a little bit. Many times, they will be used in related groups, and it would be even more convenient to just group them ahead of time.
We're using the previous constant definitions to create more. Of course, define whatever groups you find convenient.
Project global constants
If you want your constants to be available to all modules in the project, just prepend the constant definition with "Public".
Can I do this with variables?
You can replicate some what we did above for global variables, including making them Public, but we cannot assign a value at the same time (other than VBA assigning a default data type value) since that requires running some VBA code. You would need to assign the value when some macro is run which limits their usefulness.
Global variables are frowned up because it comes with a slop bucket full of possible problems begging to be dumped out. I'm not saying standard practice is always best, but there are some good reasons people moved away from using global variables.
A whirlwind review of a few better options include:
- Create macros and functions with parameters, so you know what is being passed and when (most useful).
- Use "static" variables. They do not change value between calls to the procedure. These definitely have special and also probably rare use cases.
- Create objects to take advantage of constructors automatically initializing variables when an "instance" is created. They keep everything tidier and more controlled, but they require a lot of up front effort. More often than not, they are overkill for creating editing macros in Word.
These alternatives are all well outside the scope of the current article.
