Variables, continued...
Last time I had just started to introduce the various types of variables. The types you will probably see most often are Variant (the most common), String, and Integer. Variant is the most common because it is the most versatile, and because it is the default--if you don't specify which data type a variable is, the computer assumes that it's a Variant and then automatically assigns it a provisional data type based on the type of data you store in the variable.
I see I'm getting ahead of myself again. When you set a variable equal to something, you are "storing" data in that variable. Telling the computer that NewData = "apples" is like having a bin labeled "NewData" that you then put apples in.
There are three ways of telling the computer what type of data will be stored in a variable. The first is to simply define it, using the Dim command ("Dim" stands for "dimension", which in this case means "create a variable and optionally give it a specific type"):
Dim apple As String Dim orange As Integer Dim Bulb As Long
The second method is to use a Variant, but then also use a suffix character to define the type "on the fly", so to speak--that is, while you're actually using it. You then should use the suffix character every time you use that variable in the macro.
apple$ = "Granny#4" orange% = 3
The most common suffix characters are:
$ (Dynamic string) [used in examples in the help file, so you know when
a command requires a string of some sort]
% (Integer) [also used in examples, so you know when a command requires
an integer of some sort]
& (Long integer)
(Note that some of these characters mean something else when placed at the beginning of a set of characters; for example, &H2A is a hexadecimal number [base-16 instead of the normal base-10; A-F represent 10 though 15], in this case equivalent to [2 * 16] + 10 = 42.)
It is also possible to combine the Dim statement with the type characters; in which case the "As [type]" section of the statement is not needed. You can also define multiple variables with a single statement.
Dim apple$ Dim orange% Dim grape$, plum$
The third method is to "damn the torpedoes, full speed ahead." That is, you don't define the variable in any way, knowing the computer will be able to figure things out.
x = 1 apple = "3.1415926" orange = 3.1415926
(There's nothing quite like an apple pi...) Those last two look identical, don't they? Not to the computer.
The variable "apple" is a string of characters; it is treated as plain text, and cannot have normal math performed on it. The variable "orange," however, is a number, and thus has no problems with math.
Be warned that apples and oranges--that is to say, strings and numeric variables--do not mix. This means that, if you were to add "apple = orange" to the end of the above set of commands, you would get a syntax error when you check or run the macro.
Many or most programmers consider it good style to define all of your variables at the beginning of the program, or at least before they are used. One reason in favor of doing this is that anyone who later looks at the program can then tell right away what all the variables are and what they do. If you use the Option Explicit command, as mentioned in Lesson 1, then the macro editor will force you to define all of your variables. This also allows you to quickly and easily catch typos in your variables, because the mistyped version will not be defined, or may be defined as a different type, and Option Explicit will cause the macro editor to highlight it as an error.
All types of variables (text and numeric) can be added (+), and numeric variables can be subtracted (-), multiplied (*), divided (/), or raised to a power (^), among other (less common) things. A variable is generally set equal to something (=), but it can also be found to be less than (<), greater than (>), less or equal to (<=), greater or equal to (>=), or not equal to (< >), among other (less common) things. Parentheses are used for grouping. Thus, you may find any of the following in a macro:
x = 1 a$ = "one" + "two" b$ = b$ + "gobbledegook" y = x * 2 z = ((x + y) / 3) * ((4 / (1 + 1)) + (3 ^ (4 - y)))
That last one certainly looks intimidating, doesn't it! The way to figure out what's going on with all those "nested" parentheses is to work from the inside out. From earlier lines, you know that x = 1, making y = 2. Thus (x + y) is 3, (1 + 1) is 2, and (4 - y) is 2, giving you:
z = ((3) / 3) * ((4 / (2)) + (3 ^ (2)))
That, in turn is the same as z = 1 * (2 + 9), which means z = 11. Not all that difficult, was it? This sort of number crunching is what the computer was designed to do, and it has no problems quickly solving problems like this.
As you saw, however, it's also possible to add strings together. If you have the following statements:
a$ = "one" b$ = "two" c$ = a$ + b$
Does c$ = "three"? Nope! c$ = "onetwo"; the second string is merely tacked onto the end of the first. This also means that if a$ = "1" and b$ = "2" in the above example, then c$ = "12"! With "new math" like that, you can see why string variables and numeric variables just don't mix!
In order to keep your strings separate from your integers and other numeric variables, OML has a second "addition" symbol (&), which only works with strings.
c$ = a$ & b$
If you try to add a string and an integer together (or a variant containing a string and a variant containing an integer), OML will not warn you when it compiles the macro that you have an error, as it does with other errors. However, it will usually be more than happy to inform you of this fact when you try to run the macro. It is not totally wrong to only use + for all addition, but if you use + for numbers and & for strings, you will more easily be able to find mistakes and also more quickly remember how your macro works when you need to change it a year later.
A brief warning about the ampersand: If you use it, you must always put a space before and after every & symbol, so that the computer can tell the difference between string addition and variables of the Long type.
a=b& a=b&c a=b$&c$ a = b & c a = b$ & c$
The first line above gives the variant "a" the same value as b&, which is a long type variable. The second line is an attempt to add two variants together, but because the computer cannot tell whether I meant to add two variants or set a variant equal to a long, this causes an error to occur when you try to validate the macro. The third line is an attempt to add two strings together. Since the string type indicators are there to tell the computer what I meant, it will not cause an error to occur. However, as you can see, it is very confusing to look at when compared to the last two lines. This demonstrates not only that spaces around symbols can affect whether a macro runs without errors, but also that they can make a macro much easier to read.
Addendum to variables: You may have noticed a pattern in the way I chose some of the variable names in the examples above. It is an unofficial stylistic convention--going back to the beginning of BASIC and beyond and with roots in the mathematics field--to use x, y, and z for the first three numeric variables ("unknowns" in math); a$, b$, and c$ for the first three strings; and i and j for the first two numeric variables used in counting loops (For...Next and the like; details on that later, so don't worry if you don't know what a "counting loop" or a "For...Next" statement is). This can work for small, simple macros, but for longer macros, it is good to use a mnemonic or full name in order to make the variable more recognizable and understandable, such as using pname$ or PersonalName$ for "Personal Name". (Remember that you can only use letters, numbers, dashes, and underscores in constructing variable names. Personal Name$ would be treated as two variables--a variant named Personal and a string named Name$.) The usage of generic variables such as a, b, c, has become less and less common now that real words can be used for variable names. You may even see "Hungarian notation" or variations thereon, which use verbal prefixes instead of type suffixes--for example, sPersonalName, strPersonalName, nHowMany, intHowMany, lngLargeNumber, or varRandomVariable. However, simple one- or two-character variable names can still come in handy if you don't need a specific name or mnemonic for a given variable in a small, simple macro.
Next time, string manipulation...