A long time ago, a macro was a way to write really fast subroutines in assembly language. Rather than go through all the overhead to call a subroutine, you wrote the subroutine as a macro, which could even have parameters, and when the macro was called the code was generated in-line with the rest of your program. This took more program space, but if speed was more important than space, this could make a dramatic difference in the run time of your program.
The C programming language has macros, but essentially they are one line long. You #define variable to be a string of code, and then when the compiler hits the macro later on in the program, it substitutes that code. And even this can have parameters.
Word processors, like of course Word Perfect, and text processors (like even the ugly vi) have macros, in which a series of commands can be memorized and then later replayed by hitting some sort of alt key. The SCO Unix operating system now delivers its help files in browser (html) format. But the files presume that you are viewing them with the SCO help system. I wanted to put them on our LAN. Each instance of a hypertext jump was composed of a real long sequence of paths known to SCO, but not to my LAN. So I created a couple of macros using the WinEdit text editor, to first find the hypertext reference, and then to delete the extraneous junk. I could reformat a rather complex help page in much less than a minute, and create html files that are now viewed with a browser from our LAN, and have preserved the hyperlink jumps.
More recently I have had the need to generate some macros in Micro$oft Excel, the spreadsheet. Readers of this column know that I go to extreme lengths to avoid using any applications from the Evil Empire. However, sometimes I do jobs for clients, even internal clients at World Wide Widgets. For whatever their reason, a client may already be using this particular series of products, and you can't very well expect them to change when they are paying the bills.
Knowing little about Excel, I went to a friend to borrow some books. All he had were manuals for version 3 and 4 of Excel. I have the version labeled Office 97, which is several releases later than those books were written for. I also found that nobody I knew in the entire WWW organization had any current books for Excel 97 or 95. It seems that M$ now not only does not ship printed manuals (almost no vendor does today), they don't even ship any manuals on the CD Rom, which most other vendors (WordPerfect for instance) does.
So I started hacking. I don't really like this approach to using software. I do work with some people, generally ex Macophiles, that would never dream of using a manual. The first thing they do with a new piece of software is to start bouncing the mouse around and hitting function keys, hoping to make the program kill itself, but maybe also to make it do something interesting. I personally like courses with a teacher, and second to that, I like (and read [and write]) manuals. Since I had some familiarity with the (WordPerfect) Quattro spreadsheet, I figured that Excel would probably not be too different, just more primitive.
I blush to say that I was partly wrong. I was right about the part that the worksheet part of the two spreadsheets would be similar. Excel uses an '=' to indicate a function, while Quattro uses an '@'. But Excel accepts the '@' and just translates it.
But I finally got to a point where I needed to generate some spreadsheet macros, and much to my humilification, I have to admit that these guys really got it right. Their macro language is composed of Visual Basic subroutines, and this is just the neatest idea that I have come across, once you get used to it. (And yes, I know, that the other parts of the Office 97 suite also uses Visual Basic, but so far I have not had the need or desire to check this out.)
As with most new things, my very first reaction was a snarl, with some comment about how those young Redmond whippersnappers have gone and screwed up something perfectly simple again. Most macro facilities that I have come across, even those documented in the early versions of Excel, are simply a way to play back a series of commands or mouse clicks that you do manually once, and then use the macro to do it over and over again. Sometimes there is a way to edit your macro to either fix a problem, or enhance it without redoing the whole thing.
Still not having an Excel manual, I found a menu item that said, "record macro". So I manually ran through the first few steps of what I needed, stopped the recording, and then went back to the menu and ran the "edit macro" command. Instead of seeing a series of Excel commands, there was a program. The macro contents were nothing like what I had actually done on the spreadsheet, but were calls to Excel API subroutines that would eventually recreate what I needed.
I am not terribly impressed with the help screen in the main part of Excel. But, maybe because the authors knew that this feature would be more different that what people had become used to with other products, there is a whole different help system just for editing these Visual Basic routines, and it is quite complete. By recording a series of macros, and then looking at the generated code, and then using the help file system to figure out just what the funny generated subroutines were doing (highlight the routine, hit F1, and up comes a description of the routine) it became quite easy to start making serious modifications to these macros beyond what I would probably have done with a more traditional system.
I still do not know the entire extent of the language. But it has the usual constructs, like loops, if then else sequences, and calls to external routines or other macros. However, it is object oriented, and this can be a little disconcerting to somebody that has not programmed in an OOP style before. In fact, I would expect that this whole thing, which seems so quite natural to me after doing programming for some 30 years, might be quite confusing to a person who had never actually programmed in a real computer language at all.
The most confusing part of using these things is to point the macro to a particular cell on the spreadsheet and have it read or write a value or formula there. It is easily done, but this is where the Object Oriented gobbledygook comes in. Rather than refer to a cell directly by its row and column coordinates, first you have to designate your ActiveCell object by referring to a Range or Cell object which has a method (like ".select"), and then having done that, you can use another method (".value" for instance) against your ActiveCell object to stuff something into the selected cell.
I did get quite stuck on one point, that being how to autostart the macro when the spreadsheet was loaded. The help files said to do thus and so, but none of their directions seemed to work. So I finally started looking for a proper manual. Bookstores have tons of computer manuals, as you all know. There are probably 90 currently available books on Excel alone, although for several different versions. Most of these are of the "Idiots guide to..." brand, or "21 days to...". These books have their place, especially when you are first starting out with a new application. None of the ones that I looked at got into the subject of macros. There are a very few books that do specialize in this subject though. These books presume that you already know how to use the basic tools of the application, and concentrate on the advanced items. The one that I selected was "Step by Step Excel 97 Visual Basic", which is one of a series of Step by Step books on various Office 97 applications. It did answer my question on autostarting, and seems to be a prety good guide to a subject that is not really very intuitive for most people.
Subsequent to all this, I have had reason to start working with Active Server Pages. And this product, as it turns out most M$ products, is based on Visual Basic routines. Even my beloved WordPerfect, in its soon to come Version 9, will scrap its macro language and start using VB.