How To Use This Book

Insert flap (A) in slot (B). Turn crank (C) so that teeth (D) engage with flap (A).
—Every Instruction Manual You’ve Ever Used

“So how do you use a book like this? We don’t imagine that many of you will sit down and read it cover to cover. Of course, if you’re the type who reads language reference manuals sequentially, be our guest.” We wrote those words in the first edition of this book. Since then, we’ve learned that a lot of you are the type who read language manuals in order. A surprising number of people have told us that they read the original Hacker’s Guide from front to back before turning it into a reference book. We’re flattered and astonished (especially by the one reader who told us he reads the book cover to cover once a year).

Nonetheless, we still think that most of you have a few other things to do with your time, so this edition is still organized so that you don’t have to read it all before you can put it to work. In fact, with this edition, we’ve made it a lot harder to read the book sequentially—more on that below.

The book is divided into five sections. The first, “Wow, What a Concept!” is an overview of Visual FoxPro, organized by the various components of the language: Xbase traditions and assumptions, SQL, OOP, data structures, Web support, and more. We recommend you read it, even if you’ve been working with FoxPro since FoxBase days. We hope you’ll find a few little nuggets tucked away in there.

The second section, “Ship of Tools,” looks at Visual FoxPro’s Power Tools, including some of our favorite tips and tricks for working with the tools, with more in-depth coverage of debugging and source control.

Section 3, “Franz and other Lists,” is a somewhat random assortment of lists—from hardware suggestions, to things that sure feel like bugs when you run into them, to optimization tips. A lot of what was in this section in the first edition migrated into other parts of the book in later editions. In particular, many of the “It’s a Feature, Not a Bug” items have been moved into the appropriate entries in the reference section to make them easier to find.

After you finish with all those appetizers, Section 4 is the main course. It’s a complete reference to Visual FoxPro’s commands, functions, properties, events and methods. We’ve even thrown in a few operators like “%” and “&”.

This is the part of the book we really don’t expect you to sit down and read sequentially. In the VFP 6 edition of the book, Section 4 occupied more than 750 8½” x 11” pages, but it rapidly became clear that few readers actually looked at those pages. Instead, virtually everyone who bought the book went ahead and used the HTML Help version to read the reference section. So, this time around, we’ve chosen to save trees (as well as the backs of the poor lackeys at Hentzenwerke Publishing who have to move these books around). For VFP 7, Section 4 appears only in the electronic version of the book.

Finally, Section 5 is for those daring souls who want to take the product a little further. It covers the various Active technologies as they relate to VFP (some are like siblings, while others are more like that annoying second cousin you wish would go away); two incredibly deep tools, the Class Browser and Component Gallery; VFP’s Builder and Wizard technologies; and VFP’s incredibly flexible version of IntelliSense.

Hey, CHM. Can you give me some Help here?

After the original Hacker’s Guide came out, lots of people asked us whether we could make it available in some online format (ranging from Windows Help to PDF to HTML to who knows what). They wanted access to the contents no matter where they were, without having to carry the book along. While we sympathized (especially when we were on the road ourselves), we just didn’t have the resources to do the job.

When we prepared the VFP 6 edition, we planned a digital version from the beginning. Anyone buying the book was also entitled to a complete copy of the book in HTML Help format. At that time, HTML Help was just appearing and you needed it for VFP 6’s Help file, so we figured it was a safe bet that all our readers would have it. That seems to have been a good choice.

This time around, we’re going one step farther and, as we said above, putting the reference section only in the electronic version. We suspect most readers will notice, only because the printed book no longer makes a good monitor stand.

For the curious, let us add that we created both the book and the Help file using Automation from VFP (where we track the progress of the book) to Word. In addition, we used VFP to do extensive post-processing on the generated HTML, parsing it and applying textmerge with VFP’s lightning-fast string manipulation features.

Feel free to copy the Help file onto your hard drive (even more than one, if you have multiple machines yourself), but please do us the courtesy of not sharing it with everyone you know. (You will find appropriate copyright notices in there.) We’ve put a tremendous amount of time into this book, and illegal copies deprive us of the income to pay for that time.

I Think Therefore Icon

We have pretty mixed emotions about icons—they’re great as a supplement to text, but not as a replacement. (After all, humans didn’t spend centuries going from written text to pictographs; it was the other way around.) The icons in this book flag those portions of the text you’ll want to pay particular attention to if you’re having problems, trying to understand why Microsoft makes it work this way, or just skimming for cool features of Visual FoxPro. Here are the icons we use in the book and their meanings. You’ll find the icons that appear only in the HTML Help file in “How to Use This Help File.”

This ugly creature identifies bugs, both the ones that Microsoft recognizes and the ones we think are bugs, even though Microsoft says they're just fine. Although many of the bugs we identified in earlier versions have been fixed, there are still plenty of these to go around.

This critter indicates bugs from earlier versions that are now fixed. We debated removing the bug notices entirely, but decided that, since many of us have to work with multiple versions of VFP, in most cases leaving the description in the book and marking it as fixed would be a better choice.

This doodad is supposed to say "design" to you. We use it whenever something is less than intuitive but not wrong, just hard to understand. We also use it sometimes when we think the design stinks.

This one probably speaks for itself. It's for stuff we think is incredibly cool ("cool", we think, should be the official adjective of Visual FoxPro). These things are jaw-droppers—enjoy them.

Code-dependent

When Ted and Tamar started writing the first edition of this book, they noticed that each of them had somewhat different coding conventions. Nothing major, but some real differences, especially in capitalization. Since the styles were pretty readable and since the skill of being able to read code written by different people is an important one, they chose not to change their varied styles. By the time they wrote the VFP 6 edition, their styles had converged somewhat, but there were still differences.

With this edition, we’ve added two more authors, who each have their own unique coding styles. So you may find what appear to be inconsistencies among the examples. We think each individual example is internally consistent. (We’re sure you’ll let us know, if not.)

Many of the examples show class definitions in code. Others show code to assign values to various properties in forms. The truth is that we usually don’t do it that way—we use the Designers. But code makes better examples. Just about any class you see in code here can be created as a visual class, too.

Who Ever Heard of a Sin Tax?

We’re capable of drawing the kind of syntax diagrams contained in the FoxPro manuals. In fact, we learned in school how to draw even more obscure syntax diagrams than that. For this book, though, we wanted to present the syntax of each command in the least threatening way possible. So, we use a simpler notation than the manuals. The flip side is that our notation is a little bit ambiguous.

Here are the rules we’re using. FoxPro keywords use either all uppercase or mixed case. For the most part, Xbase-style keywords are in uppercase, while OOP-type keywords are mixed.

Vertical bars (“|”) indicate choices—pick one or the other, but not both. Square brackets (“[ ]”) indicate options—use it or not, your choice. Those two are the same as in the manuals.

What we didn’t do was use angle brackets (“< >”) to enclose the things you need to substitute into commands. Most of the time, you can recognize them because they begin with a single lowercase letter to indicate their type (“c” for character, “n” for numeric, and so on). It does get confusing when a command requires something like a filename or table name that isn’t any of those types. Names are shown in mixed case (which can be confused with OOP-style keywords).

For the most part, we’ve tried to use meaningful names in our diagrams so you can see what a command or function is looking for, even without reading further.

A Class Act

In the reference entries on Visual FoxPro’s base classes, you’ll find charts showing properties, events, and methods for that class. Rather than showing you every single PEM for every single base class, we’ve chosen to include only those that are special for that class. So, none of the classes list Top or Left in their reference entries—those are pretty much the same across the board. On the other hand, Style means something different to just about every class that has it, so you’ll find it listed in several of the base class sections.

For a complete list of the PEMs of any base class, check Help.

Version Mania

Writing about software is like chasing a moving target. This edition of the book was written about the initial release version of Visual FoxPro 7.0. Before we finished it, though, Service Pack 1 was released. It fixed a number of the bugs we’d identified (including some of the worst ones). We’ve updated the book to mark those bugs as fixed. However, it is possible that SP1 has added new bugs we didn’t manage to uncover. We also imagine that there’ll be further service packs, and look forward to more of the issues we’ve raised being addressed.