Contributing Editor Ted Roche and I have been working on a new version of our Hacker's Guide to Visual FoxPro.

The editing of our first Hacker's Guide used the traditional paper publication system. We completed the manuscript and submitted it on paper and disk to our publisher. Later, we received paper galleys that had been marked by a copy editor. We edited those and, a few weeks later, received final proofs on paper for a last check.
This time around, we've eliminated one round of paper galleys. Our copy editor started reviewing sections of the book as soon as we finished writing them. Like us, she worked in Microsoft Word and simply returned edited files to us.

While this was much better in terms of time management and flexibility, it left us with a big problem. Some decisions about style (such as "textbox" vs. "text box") weren't made until many sections had been edited. In fact, the name of the product (Visual FoxPro 98 or Visual FoxPro 6.0) wasn't known when we started. So, before we could turn the parts into a book, we needed to do some search-and-replace.

In addition, our book points out bugs in the product. We did our original testing with beta versions. Before we could publish it, we needed to re-test all those bugs to see if they were fixed in the shipping version.

We had a number of other tasks like this, as well, such as making sure we'd removed all our notes to ourselves, ensuring that all the graphics were linked rather than embedded, and so on.

None of this would have been a big deal, except that we had more than 800 source documents to deal with.

Enter COM. Naturally, we tracked the progress of the book with a set of Visual FoxPro tables. Using Automation to Word, we were able to search for our special bug icon to log all the documents that needed checking, perform search-and-replace for all items that needed it, and do the other necessary bookkeeping chores. Automation also let us consolidate the documents into a final product. (We actually used Automation to assemble the original Hacker's Guide as well. See our article on Advisor.com.)

But it goes further. This version of the Hacker's Guide is also available as an HTML Help file. We used Automation to convert the clean documents to HTML.

There are two key points here. First, some tasks are tremendously easier in the COM world than they were before. Imagine manually searching through 800 documents for 15 or 20 different strings. Even with macros, that would be a horrible task.

Second, and perhaps more importantly, you don't have to reserve COM for the times when you want to build state-of-the-art, multi-tier, Web-enabled, choose-your-favorite-buzzword applications. It can fit into many applications you're building today.

Read them all

My older son is taking chemistry this year. Listening to him talk about it brought back memories of my high school chemistry class twenty-five years ago. Although I have vivid mental pictures of the classroom and teacher, I only remember two things from the course content. The first is Avogadro's number (6.02 x 10^23) -- however, I no longer remember what it represents. The second is a technique called dimensional analysis for converting from one unit of measure to another, to figure out whether to multiply or divide by the relevant conversion factors. To this day, when I need to go from pounds to kilograms or centimeters to feet, I use it.

What's striking about this is that dimensional analysis isn't chemistry. It's a tool we acquired that made learning chemistry easier. Yet, it was one of the most useful things I learned in high school.

A lot of education is like this. We don't know when we're learning which items we'll need later and which we can forget immediately (or at least after the test). We also don't know which ones we'll store up for no reason, only to find later on that they're valuable. (I'm still waiting for the chance to use Avogadro's number.)

As a developer, one of the benefits of being the editor of FOXPRO ADVISOR is that I read every article at least twice. If I were a subscriber, I'd probably read only those that seem relevant to what I'm working on at the moment, or that discuss topics of general interest to me. And I would rarely read an article more than once.

But, I have to read them all more than once. The result is that I'm exposed to a lot of things I wouldn't otherwise be, so I acquire at least passing familiarity with all kinds of topics. (Writer Rick Strahl is the king at stretching me to my technical limits and beyond.) It's amazing how often something in an article I probably wouldn't have read on my own proves useful.

I highly recommend that you try this. Read all the articles. Then, come back in a week or a month or more and read them again. Down the road, it will pay off.