Hacker’s Guide to Visual FoxPro
An irreverent look at how Visual FoxPro really works. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro.
The past is but the beginning of a beginning, and all that is and has been is but the twilight of the dawn.
—H. G. Wells, The Discovery of the Future, 1901
“In the beginning”—isn’t that how histories normally begin? But what is the beginning of Visual FoxPro? It has bits and pieces from so many different languages and technologies that there’s no one beginning. Visual FoxPro is a true hybrid.
One bit of lineage is clearer than the rest, though, and that is FoxPro’s Xbase heritage. For that, there’s at least a partial beginning. “In the beginning, there was the dot.”
In this beginning, it was 1975 and a programmer named Wayne Ratliff was working at the Jet Propulsion Laboratory (JPL) in Pasadena, California. He wanted to participate in the football pool, but felt he needed to really work over the statistics to have a fair shot at winning. Naturally, he wanted to use a computer to help him. Somehow, he got sidetracked into exploring programming languages. Along the way, he was introduced to microcomputers and to an internal language at JPL called JPLDIS.
In 1978, Ratliff started writing his microcomputer version of JPLDIS (developed by Jeb Long and others). Along the way, he omitted some commands, added some and modified others. The language was called Vulcan, as a tribute to Star Trek. Ratliff began licensing Vulcan in 1979.
When marketing Vulcan became too much for Ratliff, he made a deal with George Tate and Hal Lashlee to take over the marketing. They brought in an ad man named Hal Pawluk who gave the product a new name, dBASE II, and named the company Ashton-Tate. dBASE II started shipping in 1981. (By the way, note that there never was a dBASE I and, according to several sources, Ashton was George Tate’s pet parrot. You can probably win a few bucks on those.)
Eventually, Ratliff and co-worker Jeb Long left JPL to work full-time with a team of programmers on a new version of dBASE (to be called dBASE III). As part of that process, it was ported to the IBM PC. dBASE III was finally released in June 1984.
The fox knows many things, but the hedgehog knows one great thing.
—Archilochus, Early seventh century B.C.
In the midst of all this, a computer science professor at Bowling Green State University named Dave Fulton got a consulting contract for which dBASE II seemed the appropriate tool. But, when the work was done, the resulting system was too slow. Fulton and his group decided the solution was to write their own, faster version of dBASE II. The product they created was a marketing failure (through no fault of their own), but from the ashes of that product, the runtime libraries were salvaged in hopes that some commercial gain could be made from them.
The result was FoxBase, one of a number of dBASE clones that hit the market. The difference between FoxBase and many of the others was that it survived and found its own niche.
Once dBASE III appeared, Fulton’s group geared up to apply the Fox magic to it. FoxBase+ shipped in July 1986. A little more than a year later, FoxBase+ 2 was released, with dBASE III Plus compatibility. FoxBase+ 2 also included a number of tools to aid in application development. One of them, FoxView, let the developer lay out screens visually, then generate code for that layout. The code was generated by running a script written in another tool called FoxCode, which meant the same layout could result in many different programs.
Suspicion all our lives shall be stuck full of eyes;
For treason is but trusted like the fox.
—William Shakespeare, King Henry the Fourth
Back in Perrysburg, Ohio (home of Fox Software), the development team was hard at work on a Macintosh version of FoxBase+.
In developing the Mac version, many of the programmers took a real liking to the Mac’s interface. So, Fulton and the gang decided to bring many of the benefits of the Mac to PC programmers. Work started on FoxPro in the fall of 1988.
Not coincidentally, dBASE IV, the successor to dBASE III Plus, was released in October 1988. The new FoxPro would be dBASE IV-compatible, but for the first time, the decision was made to deviate from total compatibility. Instead, the new FoxPro would be better. Naturally, it would still be faster. It turned out that making FoxPro better than dBASE IV wasn’t all that hard—the initial release of dBASE IV was terribly buggy and poorly received. (By this time, Ashton-Tate had a number of problems. George Tate had died in 1984 and the company never really recovered.)
It was also in the fall of 1988 that Ashton-Tate filed a lawsuit against Fox Software for infringing on their copyright of the dBASE language. It took more than two years and Borland’s acquisition of Ashton-Tate before this issue was dropped.
FoxPro 1.0 was released in November 1989, still including the FoxView-FoxCode pair for designing input screens. FoxPro remained true to its Xbase roots, but incorporated lots of new commands for using windows and menus. The Mac influence was definitely felt. FoxPro 1.0 also added the first of many sub-languages: the low-level file functions that let you manipulate files as streams of characters. The term “low-level” is something of a misnomer because these really just provide the same file input/output capabilities most programming languages have, but they are lower-level than FoxPro’s other input/output facilities.
The delight that consumes the desire,
The desire that outruns the delight.
—Algernon Charles Swinburne, Dolores, 1866
Naturally, the new capabilities offered in FoxPro 1.0 weren’t enough for the FoxPro community. The FoxPro user interface included all kinds of neat widgets like push buttons, radio buttons, scrollable lists, and so forth. It didn’t take long for FoxPro developers to start clamoring for access to these goodies.
FoxPro 2.0 was the response to these demands. It appeared in July 1991, and featured a collection of so-called “Power Tools.” Developers were told to use the new Project Manager, Screen Builder, Menu Builder, Report Writer and so forth to design and build applications. For the first time, anything you could do with the Power Tools could be done with code, too. Best of all, the Power Tools stored their data in regular FoxPro tables and, in the case of the Screen Builder and Menu Builder, used regular FoxPro code to convert that metadata into programs. Like the earlier FoxView and FoxCode, this open architecture meant you could roll your own, if you chose, but now you didn’t need to learn the arcane syntax of the template language. This was all made possible with the addition of very few commands, comprising a textmerge sub-language.
Another new language was introduced into FoxPro in this
version. FoxPro 2.0 featured four SQL commands (CREATE TABLE
, CREATE CURSOR
,
INSERT INTO
and SELECT
). Up to this point, all new commands had pretty much
followed the Xbase style. But this group came from an entirely different
background—not quite the other side of the tracks, but a whole different way of
thinking about code, a non-procedural way. With the SQL commands, you indicate
what you want, but not how to get there; FoxPro figures that out internally.
This “set-oriented” view of data opens FoxPro up to opportunities
both in larger-scale Xbase applications and in new client-server venues, which
would have been difficult, if not impossible, to reach without the SQL syntax.
FoxPro 2.0 also introduced the infamous “foundation
READ
,” which could be used as part of a structure to provide so-called
“event-driven” programs. These applications, which are the norm
today, allow a user to begin one task, leave it unfinished while moving on to
another, then freely switch between the two, or even three, four or 15 tasks.
The foundation READ
of FoxPro 2.0, while kludgy in the extreme, was the
beginning of the path to the rich event model of Visual FoxPro.
FoxPro 2.0 was very well received and won lots of awards. But was that enough for FoxPro users? Of course not! They kept asking for more. One of the big things they asked for was a version of FoxPro on platforms other than DOS. FoxBase+/Mac users felt left out because DOS users had now had two major upgrades and they hadn’t. Plus, Windows was looking more and more important.
So, the next task for the Fox group was to cross the road—that is, to make FoxPro cross-platform. Work proceeded simultaneously on the Windows and DOS versions of FoxPro 2.5 through 1991 and 1992. The 1991 Developer’s Conference (DevCon) featured demos of both the Windows and Unix versions of FoxPro then in development. At the 1992 DevCon, almost every presenter used the then-in-beta Windows version.
In March 1992, the Fox world shook when it was announced that Microsoft and Fox were to merge. Given their relative sizes and importance, it was clear that “merger” was a euphemism for “acquisition.” However, the story was that the development team including Dave Fulton would make the move to Redmond. The merger became final in June and by fall, nearly all of the former Fox employees had trekked cross-country.
FoxPro 2.5 for Windows and for DOS were released in January 1993 . They included a “Transporter” for moving applications between the two platforms. The Mac and Unix versions were promised to follow soon. Some folks complained that the Windows version wasn’t a true Windows product, but they were answered by those who pointed out that “true Windows products” don’t work cross-platform. Other than those needed for cross-platform operation or for new Windows capabilities, FoxPro 2.5 didn’t introduce many new commands and functions.
With foxes we must play the fox.
—Thomas Fuller
While DOS and Windows developers learned to write cross-platform applications, Mac and Unix developers waited and waited. It wasn’t until the spring of 1994 that FoxPro/Mac made its appearance. FoxPro/Unix never made it in version 2.5. By the time that product was ready in August 1994, the ante had been upped to 2.6 across the board.
Version 2.6 was an interesting project. Its primary reason for existence was to attract dBASE users before dBASE 5 for DOS and dBASE for Windows shipped. A bunch of new commands were added to create 2.6—almost every one of them was labeled “for dBASE compatibility,” whether or not it was actually useful. Most didn’t even rate their own entry in the Help file. And some, despite their downplaying by Microsoft, were truly useful additions to the language.
In the summer of 1994, the family was finally completed with the release of FoxPro 2.6 for Unix. That was the only FoxPro for Unix that ever was.
High thoughts must have high language.
—Aristophanes, Frogs, 405 B.C.E.
By 1994, the programming world was changing. On the data side, client-server was the next big thing. Programming-wise, it was object orientation. So, of course, Microsoft decided to include both in the next version of FoxPro. They also updated the name to be in line with their other development tools, and FoxPro 3.0 became Visual FoxPro 3.0.
Visual FoxPro still contains all the Xbase commands it ever had (and more), the “low-level file function” sub-language, the textmerge sub-language, and the SQL sub-language with lots of additions. But wait, there’s more.
The major new language in Visual FoxPro is that of OOP, Object-Oriented Programming. There’s also a sub-language for client-server operation. Altogether, Visual FoxPro 3.0 contained more than 1,000 commands, functions, system variables, properties, events and methods. It was released in June 1995. The initial version of VFP had some serious problems. Because the product was released before Windows 95 and since most of the computing world still worked in 16-bit versions of Windows, this 32-bit application had to cooperate with the Win32S subsystem to run under Windows 3.1 and Windows for Workgroups. A lot of people found that combination less than stable.
In many ways, it makes sense to think of VFP 3.0 as actually being “version 1” of a new product. Major portions of the product were brand-new code, from the object orientation to the new controls like grids. And, as with most version 1’s, it didn’t take long for updates to come along. The first one, VFP 3.0a, was released only in the Far East because the enhancements it offered were related to dealing with the languages used in that part of the world. However, in December of 1995, Microsoft released version 3.0b, which fixed a number of bugs in 3.0, as well as added support for double-byte character sets (the kind used for Japanese and Chinese and other languages that use pictographs rather than strings of characters to make words). Visual FoxPro was one of the first Microsoft products to support this level of internationalization (since Unicode hadn’t yet been accepted) and that drove a lot of popularity for FoxPro in the foreign markets. While Microsoft doesn’t release sales figures, we’ve found that FoxPro is very popular worldwide.
A Mac version of 3.0 was released in May 1996. Though it was initially popular, its extreme slowness and hardware hunger, together with Microsoft’s lukewarm support, made it something of a niche product. Mac enthusiasts kept waiting for an improved version, but it never appeared and we feel confident that there’ll never be another Mac version of VFP.
Glorious, stirring sight! The poetry of motion! The real way to travel! The only way to travel! Here today—in next week tomorrow! Villages skipped, towns and cities jumped—always somebody else’s horizons! O bliss! O poop-poop! O my! O my!
—Kenneth Grahame, The Wind in the Willows, 1908
VFP 3.0b was barely out the door before the development team started getting serious about what we figured would be VFP 4.0. Wrong again. To bring FoxPro into synch with Microsoft’s other development products, the version after 3.0b was 5.0.
Where the first version of VFP focused on improving the programming language, most of the focus for this version went into the developer tools. VFP 5 featured a new debugger, color-coded syntax, an improved editor, and integration with source control tools (especially Microsoft’s Visual SourceSafe). There were language improvements, too, of course, including offline views and a bunch of new properties. In addition, VFP 5 can be an Automation server as well as a client.
VFP 5.0 was released in August 1996. Like so many versions before it, an update wasn’t too long in the making.
Version 5.0a was released in December 1996. It was primarily a bug-fix release. The most notable thing about it was its inclusion in the Visual Studio product. Visual Studio combined Microsoft’s developer products (including Visual Basic, Visual C++, Visual InterDev, Visual SourceSafe and, of course, Visual FoxPro, and more) into a single package. In this first version, pretty much the only common thing about the products in the box was that they were in the same box and shared an installation routine. But the history of the Office product line suggested that the products would grow more together as time passed.
After 5.0a, there were two minor revisions to VFP 5, included in Visual Studio Service Packs. The last version was build 415, with a release date of October 21, 1997.
But now I am six, I’m as clever as clever,
So I think I’ll be six now, for ever and ever.
—A.A. Milne
After the quick turn-around between VFP 3 and VFP 5, things settled down a bit. Visual FoxPro 6.0 was released in 1998 as part of Visual Studio 6 as well as an independent product.
The big changes were focused in several areas. The first primarily affected developers—the ability to address projects programmatically. In addition, a lot of work was done to make VFP a stronger player in the component world. Among other things, VFP 6 was better at hosting ActiveX controls than its predecessors and supported OLE drag and drop. There was lots of other new stuff, too—cool new functions, additional properties, and more.
There still wasn’t much besides the packaging that made VFP 6 seem a member of Visual Studio. That turned out to be a foreshadowing of things to come.
Visual Studio 6 had five—count ‘em, five—service packs. The first two didn’t offer much for VFP developers, but Service Pack 3 was a whopper. In addition to a tremendous number of bug fixes (including a whole bunch for the notorious C0000005 error), it included a new Session class to provide private data sessions without the overhead of a form, the ability to created multi-threaded DLL’s, and the ability to compile code on the fly.
The last two service packs focused mostly on bug fixes as well, though there were also enhancements aimed at those running VFP through Windows Terminal Server. The final service pack for VFP 6 gives the product a build number of 8961 and a date of August 17, 2000 (unless you check with the VERSION() function, in which case the date is August 18).
Every man is the architect of his own fortune.
—Appius Claudius
If VFP 5 seemed to ship practically before VFP 3 was out of the box, and VFP 6 followed at a reasonable interval thereafter, the wait for VFP 7 seemed endless. Development started right away, and the product was demo’d at conferences as early as Summer ‘99, and finally released to manufacturing on June 26, 2001.
By the time VFP 7.0 was released, a few things had changed. VFP was no longer part of Visual Studio. That was because of the really big change—Microsoft’s introduction of the .NET framework and the conversion of Visual Studio into Visual Studio .NET. Because making VFP a full participant in .NET (that is, having it compile to the Common Language Runtime) would have meant removing or disabling many of the features that make FoxPro FoxPro, the Fox team decided to take another route and pulled the product out of Visual Studio, after discussion with the VFP community.
One of the big wins in this change was the ability to control their own shipping schedule. As of this writing, VFP 7 has been on the market for several months and the first Service Pack is already available, while Visual Studio .NET is just starting to ship.
VFP 7’s enhancements cover a wide range of territory. There’s so much that’s new that you could write a book about it. (In fact, Doug and Tamar, along with Kevin McNeish, did—check it out at www.hentzenwerke.com.) VFP 7 includes developer productivity enhancements, such as IntelliSense; language enhancements, including major upgrades to the textmerge sub-language; data enhancements, including database events and an OLE DB driver; and COM and Web enhancements, including the ability to create and consume Web Services. There’s also the beginning of a new sub-language for working with XML. In addition to all the new stuff, the long wait gave the Fox team time to include many of the smaller items that VFP developers have been demanding for years, such as word-wrap in grid headers, case-insensitive searching in several places, and much, much more.
By now, lots of things work differently in different versions of VFP. Wherever possible, we point that out and let you know where it’s working and where it’s broken.
Strengthen me by sympathizing with my strength, not my weakness.
—A. Bronson Alcott, Table Talk, 1877
The proliferation of sub-languages is a key factor in developing in Visual FoxPro. There are almost always several ways to tackle anything you might want to do. We’ll point this out over and over again and let you know where we think one approach is better than others.
The remaining chapters in this section introduce each of Visual FoxPro’s major sub-languages. Each covers the basic terminology and the fundamental assumptions you need to understand when dealing with that group of commands.