Company logo


Advice, tips, techniques and downloads for Visual Foxpro developers.

Home | Contact

Looking back: How Visual FoxPro looked in 1995

To mark VFP's tenth birthday, we are re-printing Mike Lewis's original review of Visual FoxPro 3.0.

This article first appeared in Windows User, in June 1995. It was (we believe) the first review of VFP to be published in the UK, and one of the first in the world. We are posting it here exactly as it originally appeared, despite what Mike describes as some embarrassing factual errors.

For years, FoxPro has been a darling of the database world. Sleek, powerful and good-looking, it has attracted millions of happy users - and with good reason. It offers a powerful programming language, rich design tools, true cross-platform compatibility, and, above all, speed. Thanks to its proprietary Rushmore technology, it is one of the fastest data-retrieval tools around.

And yet FoxPro has somehow never really been in tune with the Windows way of doing things. As one of three surviving members of the XBase dynasty (the others are Borland's dBASE for Windows and Computer Associates' Visual Objects), it is shackled to an ancient procedural language which ill suits the event-driven world of the GUI. It also suffers from an over-simplistic file system - the famous DBF format - which fails every test of a true database.

In order to drag FoxPro into the mid-1990s, Microsoft has now come up with a thoroughly updated version. Known as Visual FoxPro 3.0, it offers all the features that a Windows database developer would expect, not least of which is a full object-oriented programming language. It also boasts some vastly improved design tools, a sophisticated data model and the ability to scale applications for client/server environments.

I've been testing a late beta version of Visual FoxPro and have been impressed with its abilities. Despite a massive jump in size, it is still very fast, and it is sufficiently like its predecessors to mean that upgraders should have no difficulty mastering it - though I'd hate to have to learn it from scratch.

Moving to OOP

The biggest change lies in the object-oriented language extensions. Visual FoxPro amply supports the three tenets of OOP: encapsulation, inheritance and polymorphism. Programmers can create their own classes and subclasses, and populate them with procedures and methods in true OOP fashion.

The syntax for this more or less follows the standard XBase style. Just as you could previously create a menu by using the DEFINE MENU command, you now create classes with DEFINE CLASS. Properties are addressed just like other variables, but with "dot notation" used to denote ownership. For example, to alter the font of an on-screen object, you might assign a value to MyObject.FontName.

The new OOP syntax can be freely mixed with standard XBase commands. You can continue to use the traditional @/Say/Get system to interact with the user - in fact, you can create some pretty impressive interfaces with it - but once you have tried the OOP approach, you will probably want to ditch @/Say/Get for good. You can make the transition gradually if you prefer, adding OOP features to your code as and when it suits you.

The OOP extensions make Visual FoxPro more amenable to an event-driven environment. Previously, you had to use the extraordinarily clumsy Foundation Read to simulate an event loop, with When and Valid clauses to trap GotFocus and LostFocus events. With Visual FoxPro, you write your own event-handling methods, just as in most other Windows development systems. Visual FoxPro can handle the full range of Windows events.

Database container

On the database front, Visual FoxPro is still rooted firmly in the DBF world, but it now supports the concept of the database container. This is essentially a repository containing all the tables, relationships, connections and views that make up the application. Conceptually, the container is like a "real" database in which the individual tables are XBase data files. The DBFs still exist as separate physical files, but once they have been added to the container, you can more or less ignore them.

The important point about the database container is that it is persistent. You no longer have to open individual tables and set their relationships within your application. You merely open the container. A visual design tool is available for creating and maintaining the container. Defining a relationship is reduced to a simple drag-and-drop operation.

The table-creation tool (equivalent to the old Modify Structure dialogue) has been extended to support table- and field-level properties. You can now establish business rules within the database, for example to prevent out-of-range values being entered. You can also specify insert, update and delete triggers. The main use for these is to enforce referential integrity - to automatically delete all "child" records when the corresponding "parent" is deleted, for instance.

Although Visual FoxPro still relies heavily on the DBF format, it is also a fully paid-up ODBC client. You can add tables from any supported data source to the database container, after which they look and feel just like the familiar DBFs. You can also use pass-through mode in SQL to talk directly to back-end servers. You no longer need to install the FoxPro Connectivity Kit to access remote data.

SQL to the fore

FoxPro has always had limited SQL capability. This has now been enhanced by new commands such as Alter Table and Update, and the existing Create Table command has been extended to cater for the new table and field properties. This SQL capability, which works on both local and remote data, is useful for folk who like working in that language, but it can safely be ignored by others - it offers nothing that cannot be done in other ways.

Because of its improved connectivity features, Visual FoxPro lends itself to application "scaling". Typically, this means that the programmer develops the application against local tables on the workstation or file server. When the application is ready to go live, it can be scaled up and deployed against a remote back-end. The scaling is done by creating a new "view" of the data, using an interactive view designer.

The ancient command window

Despite the substantial enhancements in this release, Visual Foxpro still looks much the same as its predecessor, at least at a superficial level. The first thing you see when you fire it up is still the ancient command window, a device whose lineage goes all the way back to the dot prompt in dBASE II. If visual programming does not appeal to you, you can type raw XBase commands in this window, and see the results displayed on the surface behind it.

With all the interactive tools now available, I can't imagine many people continuing to use the command window. It might still come in handy for trying out commands or for performing ad hoc operations, especially as you can paste commands from the window into your program code. It's also useful to be able to view the commands which the interactive processes generate - a USE command when you open a table, for instance. Nevertheless, it's surprising that Microsoft chose to keep the command window as the default interface, rather than as something you can whistle up as the need arises.

Managing the project

A far more useful device is the greatly improved project manager. This tool, which combines the functions of the old project manager and the catalogue, is the focal point of the application development process. In particular, it provides an easy way of getting at the disparate objects that make up the project.

The project manager initially appears as a dialogue with six tabbed pages (All, Data, Documents, Classes, Code and Other). Each page displays a list of the relevant objects, in the form of a collapsible outline. The Data page, for example, shows databases at the top level. When you click on it, it opens up to reveal the names of the databases in the project. Click on a database to see a list of its tables; click on a table to see the names of its fields.

Once you have found the required item, you can either run it - in the case of a table, this means opening its Browse window - or you can call up its design tool. Buttons are available for adding and removing items and for rebuilding the project. The whole thing is neat and intuitive.

The project manager sports some interesting new usability features. For a start, you can shrink the whole thing down so that only the page tabs are visible, then dock it to the edge of the screen. If you place it at the top of the screen, it merges with the toolbar and its tabs appear as enlarged buttons. You can also "tear off" a tab, so that the page floats independently of the dialogue. Having done so, you can then click on a "push pin" to make the page stay on top of the other windows.

Beefed-up tools

FoxPro's other design tools have also been beefed up for this release. The most extensive improvements are in the form designer (previously known as the screen builder), where new toolbars and palettes have been provided to assist the design process. I especially like the alignment tools, which makes it easy to line up objects at any of their sides, something that was surprisingly difficult in the previous release.

The form designer has a streamlined properties window which makes it easy to alter properties and methods. It is divided into five tabbed areas and includes a separate edit line for modifying the selected item. There is also a "builder" button which invokes a wizard-like tool for configuring various kinds of controls.

To get at the code behind an object, you select the Methods tab within the properties window, then double-click on the corresponding event. This leads to a code window which hosts FoxPro's source-code editor. The editor supports automatic indentation and drag-and-drop editing, but, surprisingly, not syntax highlighting - a popular feature in other products. The code window includes controls for selecting other objects and events. In the case of events, the names are highlighted in bold if they already contain code - a nice touch which makes navigation that little bit easier.

Wizards everywhere

Finally, Visual FoxPro, like so many Microsoft products, has been endowed with an army of wizards. No fewer than 18 of these handy devices are available. There are wizards to help you create tables and reports, to convert query results to a cross-tab, to set up local and remote views, to format and analyse program code, to import data and to create a SQL Server version of a FoxPro database.

These wizards are in addition to the builders, which are interactive tools for setting the properties of a given type of control. The combo box builder, for example, allows you to specify the values that appear in the box and its overall style and layout. It then creates the box for you and sets its properties.

Despite the huge number of new features - and I've only had space to describe a few of them here - the package's underlying concepts have not changed all that much. In particular, Visual FoxPro is completely compatible with earlier releases at the code level, which means that it should run existing applications without change. The internal formats of the screen and report files are different, but these are converted automatically when you first open them. Apart from a slight delay, you should not be aware that it is happening.

Perhaps the most significant change is that FoxPro has finally thrown off any pretence of being an end-user product. The original FoxPro, like the earlier FoxBase, tried to meet the needs both of power users and developers, though it was developers that made up the bulk of its customers. Visual FoxPro is a developer's product to the core. The best indication of this is the fact that the Browse command - the main tool of the interactive user - has finally vanished from the menus and toolbars (you can still use Browse inside your code).

Without this new release, it's likely that FoxPro would have withered away. Despite its immense popularity, it was clearly failing to keep up with the modern event-driven client/server world of the mid-1990s. Unlike its two main rivals, it did not support object-oriented programming and it was firmly wedded to the old-fashioned DBF file format. Now, with a single leap, Microsoft has put all these problems behind it and placed FoxPro firmly back on track. With Visual FoxPro, this venerable database has every chance of regaining its former glory.


Visual FoxPro 3.0

First published: June 1995. This post: July 2005. Mike Lewis, 1995 - 2005. All rights reserved.

More Visual FoxPro articles | Crystal Reports articles | Recommended books | Visual FoxPro consultancy | Contact us

FoxStuff is maintained by Mike Lewis Consultants Ltd. as a service to the VFP community. Feel free to download and use any code or components, and to pass around copies of the articles (but please do not remove our copyright notices or disclaimers).

The information given on this site has been carefully checked and is believed to be correct, but no legal liability can be accepted for its use. Do not use code, components or techniques unless you are satisfied that they will work correctly in your applications.

© Copyright Mike Lewis Consultants Ltd.