Computer Associates' Visual Objects, Borland's Visual dBASE, and Microsoft's Visual FoxPro -- a far cry from your fatherýs Xbase.
A close friend of mine insists that there are more Xbase programmers in the world than there are programmers of all other languages combined. I'm not sure that's really true. I mean, that would be quite amazing considering that Xbase is younger than both Cobol and Basic, and there are probably as many mainframers who became brain-damaged writing legacy code in Cobol as there are Basic programmers who have been institutionalized in psychiatric wards, and are still mumbling about go-tos that went nowhere.
Still, the point is well taken. Xbase (along with its .dbf file format) is popular and will continue to be so because its vendors and supporters continue to evolve the language and the product to satisfy user requirements. The latest reincarnation of Xbase on a PC is a DBMS that is based on an event-driven model with object-oriented characteristics and wrapped in a highly visual development environment. This latest evolution is a far cry from the CP/M-based dBASE II version 2.02, so you definitely will not confuse it with your father's Xbase. This crop of Visual Xbase implementations has given new meaning to the concept of rapid application development; they are adept at serving as standalone DBMSs and as GUI front ends to SQL database servers. I have used one of these products as a front-end replacement for Visual Basic.
In this article I discuss three popular PC-based Visual Xbase implementations: Computer Associates' Visual Objects (CA-VO), Borland's Visual dBASE, and Microsoft's Visual FoxPro (VFP). All of these products implement an intuitive development environment and come equipped with debuggers. Importantly, they are not just old versions of their predecessor products on which object-oriented features have been grafted. You can't really choose one over the other simply on the basis of how they implement object-oriented characteristics. In all three products, features such as inheritance and encapsulation have been implemented quite well.
Given that each of these products has particular advantages over the others depending on the problem at hand, my advice is to look at the products with an open mind and use the best tool for the job. Once you get over the object-oriented concepts and implementation strategies, becoming productive in any one of the three is easier than you might think.
CA-VO is distinct from CA-Clipper (although one of its design goals is to make the transition by CA-Clipper developers as painless as possible). Thus, the CA-VO documentation contains a CA-Clipper migration guide and a separate manual explaining the important differences between DOS and Windows.
In CA-VO, the main window is the Integrated Development Environment (IDE) window, from which you can access various system components, including the browsers, visual editors, compiler, and debugger. The capability to run the application inside the IDE speeds up your application development process. When you first invoke CA-VO, it displays the Application Browser, which contains buttons for all the standard CA-VO libraries. (See Figure 1.) Any applications you develop from then on will show up in the Application Browser screen as well.
A CA-VO application consists of modules. In turn, modules consist of entities that are the application's building blocks. Examples of module types are forms, menus, reports, and data. Entities are things such as classes, methods, and field specifications. When you compile a CA-VO application, only those entities that have changed are recompiled.
You use the CA-VO repository to organize the application's entities. Therefore, you don't have to deal with a collection of individual files and their dependencies. The repository helps you manage the application's components, including source-code files and compiler options. There are three hierarchical levels in the repository: Application, Module, and Entities. Because the repository is, in effect, your application's container and lifeblood, you should treat it with respect. I have not corrupted a repository so far, but CA-VO's Repository Manager lets you pack and rebuild repositories if necessary. You may also export the application and libraries into an .aef file, which you can safeguard and transport.
CA-VO provides a variety of editors to facilitate the creation of application components such as menus, reports, windows, source code, data servers, and icons. Many of the editors, such as the menu and window editors, are visual editors that support the usual point-and-click and drag-and-drop techniques.
The usual process of developing CA-VO applications consists of two major steps: first, generating what is known as a standard program, and second, customizing the standard program for the task at hand. With the aid of the various editors, you can add menus, processing logic, reports, and so on. Creating the standard program is a straightforward process -- all you do is supply application-dependent information and pick options on three short screens. Some of the required information includes the application name and directory, the user interface style (GUI classes, for example), compiler options, and database style (typically, .dbf classes or SQL classes -- more on this topic shortly).
CA-VO opens a module browser with your selections incorporated in the generated modules. The system generates object-oriented source code for the various application components. You can use the appropriate entity browser or source-code editor to inspect the generated code. CA-VO does not have Visual dBASE's Two-Way Tools feature, where changes instituted in the visual design editors, such as the form and menu editors, are reflected in the source code, and vice versa.
CA-VO applications can work with .dbf tables as well as SQL databases via data servers. A data server is an abstract definition of a database. You may alter the definition dynamically (for example, by changing validation rules for some of the data fields). You create and modify data servers with the aid of two editors: The DBServer Editor lets you create a data server based on the .dbf database model, while the SQLSelect Editor lets you create a data server based on the SQL database model. Creating a DBServer object is equivalent to opening a .dbf file in a work area; creating a SQLSelect object is accomplished through a standard SQL select statement that defines the desired rows and columns.
Your application talks to data servers through Data Windows. To make the association, you simply assign the name of the data server to the "data server property" of the data window. Within the data window, you make a window control data-aware by binding the control to a specific database field, using the field name as the name of the control.
CA-VO is designed around the concept of a work area in which a database table may be opened. The product supports 250 work areas. The system can use .dbf tables and associated index files created by other Xbase dialects such as dBASE or FoxPro by way of replaceable device drivers (RDDs). RDDs for these two products (DBFMDX for dBASE and DBFCDX for FoxPro 2.x -- not Visual FoxPro) come with the package. With the appropriate RDD, a CA-VO application can share files with a dBASE or FoxPro application. Note that FoxPro memo file (.fpt) compatibility is lost under the DBFCDX RDD when the memo block size is reduced to a value less than 32. On the issue of compatibility, it is worth noting that CA-VO has a User-Defined Command facility that lets you use the command syntax of your favorite Xbase dialect.
The standard version of CA-VO (as opposed to the Lite version) provides ODBC drivers for a number of SQL databases, including Oracle, Informix, SQL Server, CA-OpenIngres, NetWareSQL, SQLBase, and SQL Anywhere (formerly Watcom SQL). SQL Anywhere is included in the standard version as a local database server, enabling you to write and test applications that communicate with a SQL database on the same PC.
CA-VO implements row-level buffering, but not table-level buffering. The standard DB Server class buffers changes to the current record, allowing changes to be rolled back before the application moves off the record. To allow full transaction processing that involves table-level buffering, you must create some sort of a transaction processing DB Server class.
The report writer bundled with CA-VO is CA-RET (Computer Associates Report Engine Technology), the same tool found in other CA products. CA-RET is a banded WYSIWYG report writer. When you save a CA-RET report, the report specification is written into an external .ret file. CA-VO writes some source code to facilitate integrating the report into your application. You bind the report to a pushbutton control or a menu command in your application. To bind the report to a menu command, you assign the report entity name to the event name property of the menu item.
To compose a report, you select the desired report style (tabular, form, letter, label, free style, and so on) and identify the pertinent data servers. If the report uses more than one data server, you must specify the appropriate join conditions. A CA-RET User Guide and a CA-RET Reference Guide describe various built-in report functions. You may freely distribute the CA-RET runtime engine with your applications.
CA-VO also lets you build dynamic link libraries (DLLs) for use by other Windows applications. Conversely, your application can access functions from DLLs created by other developers -- as long as you know the function prototype. With CA-VO, you have access to the Windows API functions. Visual Objects aficionados would probably want to get the software development kit (SDK) at an extra cost. The SDK includes the source code for class libraries, the Error API, and the APIs that let your C programs access the repository.
If you build your application as a standalone .exe for distribution to users, the Install Maker can help you deploy the application. With the Install Maker you create a set of disks containing the application and associated files. You specify the disk size, the name of the program group, and the name of the target directory in the user's machine. The Install Maker creates disk images in appropriate subdirectories (DISK1, DISK2, and so on), which you then copy to floppy disks.
The standard CA-VO package comes with a comprehensive set of paper documentation, including a Getting Started manual and a manual that takes you through a complete application development cycle. I believe that with these two manuals (along with an occasional peek at the online Help), you should be well on your way to developing your first CA-VO application.
Additional documentation is provided online. You can obtain paper copies of this reference set (which includes a three-volume Function Reference Guide, a two-volume Class Reference Guide, and a single-volume Command Reference Guide). My evaluation copy included a set of Facilities documents, which included the CA-RET manuals, ODBC Reference, Creating Help Files manual, and a SQL Anywhere manual.
The Visual dBASE desktop consists of the menu bar, toolbar (also called SpeedBar), the Navigator, and command window. (See Figure 2.) The toolbar is a context-sensitive item that changes as the active window changes. As you move the mouse cursor over a toolbar button, a tool tip (pop-up hint) tells you what the button does, and the status line at the bottom of the screen displays a longer button description. Each window has a context-sensitive SpeedMenu, which you can summon via a mouse right-click. You can view and change the properties of the active window or object from the SpeedMenu.
The Command window consists of two panes. The lower pane displays any textual output from the commands you issue in the upper pane, leaving the rest of the desktop uncluttered with command results. The upper pane is the successor to the old dBASE dot prompt. Commands you type in this window execute immediately or generate instant error diagnostics. As you work on the desktop, making appropriate selections from menus, the equivalent dBASE commands resulting from your series of mouse clicks display in the upper pane. Novices find this facility helpful in learning the dBASE language, especially SQL commands.
The Navigator window displays a collapsible list of files in the default path grouped by categories such as tables, forms, reports, programs, queries, labels, catalogs, images, sounds, and custom. Custom works like "none of the above," and can include any other files. In a client/server environment, the Navigator can display tables in a database, rather than files in a directory. When a file in the Navigator is highlighted, you can modify it (Design mode) or run it (Run mode).
Files that display in the Navigator window may or may not be part of the same application or may or may not be related to one another. If you want to work with related files belonging to a specific application, you should work with catalogs. A catalog works like an application project, except that you must deliberately place files in a catalog -- unlike FoxPro's Project Manager, it does not hunt down files.
Several screens in Visual dBASE sport a tabbed interface. For example, the all-important Inspector screen, which allows you to change object properties, has the Properties, Events, and Methods tabs. The tabs are at the bottom of the screen (which took me just a short while to get used to).
To develop applications in Visual dBASE, you can use the same general approach that everyone uses for developing applications in any language or tool: Build screens, menus, and reports, and tie them all together. From the Navigator window or from a catalog, you can build and modify the application's components (such as menus and forms) with the aid of the appropriate visual designer tool. In the process, you can't help but learn Visual dBASE's object-oriented language. This is possible because of the product's aforementioned Two-Way Tools feature, which lets you see the source code results of your visual design efforts, or change the source code and have that change be reflected in the visual design. Two-way tool capability is available while you're constructing forms, menus, SpeedMenus, and custom classes. Unfortunately, it is not yet available for reports.
Designing a form in Visual dBASE is a breeze, especially because you have an Expert (or Wizard) to help you. Suppose you want to design a data-entry form that involves a parent table and a child table. As usual, you want records from the child table to display on a grid and display in sync with the corresponding parent record. To do that, simply create a quick query file describing the parent-child relationship, and then invoke the Form Expert and choose the One-to-Many layout.
Visual dBASE's dynamic object model lets you add or remove objects from active forms. When designing forms, you have the use of a field palette and a control palette. The control palette has three tabbed pages: Standard, Custom, and VBXs. Standard controls (for example, ComboBox, TabBox, or OLE) are built-in. Custom controls are external .cc files that you can make yourself. One of your favorite VBXs should be the TabBox, which makes creating a form with tabbed pages a no-brainer. To include any control on your form, simply drag it from the palette and drop it on the form. Visual dBASE has a default association between a field and a control (for example, a numeric field is typically associated with a spin-box control), but you can change the association at any time.
To distribute your application as a royalty-free, standalone .exe, you need the dBASE compiler or the client/server version (which contains the compiler). The compiler finds all of the components used by your application, so you don't need to create a project file for this purpose. The system lets you embellish the compiled applications with splash screens and icons. The Application Deployer helps you prepare and copy the compiled application into CD-ROM or floppy disks in a form that users can install themselves.
Visual dBASE, like Paradox and Delphi, comes with the Borland Database Engine (BDE) -- an application-independent database engine that provides native support to .dbf and database (Paradox) tables, and also provides connectivity to both SQL and non-SQL databases through native drivers in the form of SQL-Links and ODBC. You use SQL-Links to connect Visual dBASE to SQL database servers or to create SQL database tables there and take advantage of server-based security and processing. SQL-Links provides native drivers for Oracle, Interbase, Sybase/Microsoft SQL Server, and Informix. The Visual dBASE client/server edition comes with SQL-Links, ODBC, and a local Interbase server. OLE is a valid field type in both .dbf and DB tables.
Visual dBASE does not have a built-in data dictionary facility, so it does not support referential integrity at the engine level for .dbf tables. Instead, Visual dBASE can enforce .dbf referential integrity in code. Built-in referential-integrity support for Paradox tables is provided in the form of cascading updates. Visual dBASE supports 225 work areas. If that does not seem enough, consider that the product supports the notion of sessions, where each session can have 225 work areas. With sessions, you can simulate a shared (network) environment; that is, you can open the same table in two different sessions, and locks imposed on a table by one session are respected by other sessions.
Visual dBASE has a security system to prevent unauthorized users from accessing .dbf tables and associated files. The three levels of security include login security, data encryption, and table/field security. The latter lets you define which tables or fields can be accessed by which users. Data encryption extends to .dbf tables and their associated memo and index files. Paradox tables can be protected by a password (once assigned, the password is required to open the table in Visual dBASE as well as in Paradox).
Visual dBASE has two types of transaction processing: local and server. Local transaction processing is enforced by the product over dBASE and Paradox tables, using the typical begintrans( ), commit( ), or rollback( ) functions. In server transaction processing, Visual dBASE sends transaction commands to the server, which takes care of transaction processing. Clearly, your transaction set cannot include both .dbf and SQL tables. Visual dBASE supports several isolation levels on server transactions, including dirty read, read committed, and repeatable read.
The report writer in the product is a special version of Crystal Services' Crystal Reports. It is a banded WYSIWIG report writer that supports crosstabs, grouping expressions, and OLE objects. The regular version of Crystal Reports has no macro capability and has a limited set of built-in report functions. The Visual dBASE version, however, has a richer set of functions, which you can access through the report's Expression Builder. In Design mode (but not in Run mode), the product invokes Crystal Reports as a separate application. Therefore, if you need to switch between the two, you'll have to use your Windows task-switching facility (Alt-Tab in Windows 3.x or the taskbar in Windows 95, for example).
In Print Preview mode, you can send the report as an email message or export it to a disk file in a variety of formats, including comma-delimited value, Excel, Lotus 1-2-3, Quattro Pro, text, and Rich Text Format. Crystal Reports has an irritating default that saves data with a closed report, so you may find that the report keeps showing the same results even after you've modified the underlying tables. To correct this, uncheck the "Save Data with Closed Report" option in the Report menu.
If you have an insatiable appetite for functions and would like to extend Visual dBASE's functionality even more, you have several choices. First, the PaintBox control in the standard control palette lets you work with the Windows API functions. Also, Visual dBASE can serve as an OLE client; in other words, with the aid of the OLEAutoClient class, you can invoke the services of an OLE server such as Microsoft Word to perform functions such as spellcheck the information in your application's edit box. Visual dBASE does not support OCXs.
Visual dBASE can act as both a DDE server and a DDE client. Like Visual Objects and Visual FoxPro, it can also access the functions in a DLL that was created elsewhere, including the Windows API functions. The product's Extern system, along with a C or C++ compiler, enables you to create your own DLL that can manipulate Visual dBASE's objects. This facility is not documented very well.
Those of you who are Internet diehards may have seen third-party products that use a Visual dBASE class library to create client/server applications using the World Wide Web as an application server. One of the products is WebTools for Visual dBASE, produced by DeltaPoint Inc. (Monterey, Calif.). With this tool, you can write a simple application that is Common Gateway Interface-compliant.
Visual dBASE comes with a User Guide, Programmer Guide, Language Reference manual, Quick Command Reference guide, and a short manual on Crystal Reports. Additional paper documentation is supplied with the client/server version, including a SQL-Links manual and an Interbase guide. All manuals are well-written and easy to follow, but I would have preferred to see a Getting Started manual that takes a new developer through a complete application development process. I also think the Extern system (which supports creating DLLs that can call back to the Visual dBASE environment) should have better documentation than the code comments in the SAMPLES\EXTERN subdirectory. However, the package comes with extensive online documentation, including the OnLine Books reference in Adobe .pdf format.
The VFP desktop consists of a menu bar, a set of toolbars, and one or more windows. The desktop windows typically consist of the Project Manager window, the Command window, and the View window. (See Figure 3.) The Command window (accessible at any time via Ctrl-F2 or a menu item) is the usual place at which you issue FoxPro commands. Unlike Visual dBASE, VFP does not have an output pane in the Command window; rather, all textual output of commands display on the desktop where the results could be obscured by other windows. The View window lets you open, close, or browse any tables (or views) in the active data session. Here you may also modify table properties such as index order or data filter. Many of VFP's windows have a tabbed interface with tabs on top.
The Project Manager is VFP's control center and primary organizational tool. From here you can access any of the application components and invoke the appropriate visual designer to modify the component. The Project Manager shows a collapsible list of components that include Data, Documents, Class Libraries, Code, and Other. Under the Data group you include the application's database, free tables, queries, and remote or local views. The Document group includes forms, reports, and labels. The Other group includes menus, text files, and icons.
To modify an application component, you can summon the visual designer for that component. For example, the Form Designer lets you build the application's data-entry forms. While you work with a designer, you have access to one or more toolbars, such as a color palette, the form controls palette, and so on. You can create your own controls using VFP's builders and save them in class libraries. You can also create your own classes by customizing VFP's standard classes.
The conventional approach to developing VFP applications is to construct and organize the application's components with the aid of the Project Manager. You use the Table Designer to define the application's tables and indexes; you use the Database Designer to define the database, including persistent relationships among the tables; you use the Forms Designer to construct the application's forms; you use the Menu Designer to build the menus; and you use and the Report Designer to construct the reports.
Wizards walk you through the steps for completing a task such as designing a form or creating a report or label. VFP has Wizards for almost everything, including Table, Query, Form, Report, Label, MailMerge, and Import. One of my favorites is the Pivot Table Wizard, which lets you perform data analysis by building pivot tables (which are like crosstabs) for Microsoft Excel. Builders, available in the Form Designer and Class Designer, let you modify an object simply by answering a series of questions. One of the most popular is the Grid Control Builder for setting up data grids in forms.
Creating forms in VFP is a piece of cake. For example, creating a one-to-many form is even easier here than in Visual dBASE because the database knows all about table relationships. First, drag the fields of the parent table from the Project Manager onto the form. Next, drag the child table onto the form and run the form. Notice that VFP also lets you run a form without first building the application. However, unlike previous FoxPro versions, VFP does not generate the source code for the forms. VFP supports Page Frames and lets you create tabbed multipage forms. It also supports embedded OCXs in forms.
VFP has a commendable client/server application development approach if you use SQL Server as your database server. You can test your application by creating a view using local data. When you're ready to work with server data, simply invoke the services of the Upsizing Wizard, which walks you through the steps of migrating your local application into a client/server application that uses remote tables and views. For other servers, you would use SQL pass-through to create remote tables, and then create remote views that access the tables.
To compile and distribute your application into a standalone .exe, you must have the Professional Edition (which is well worth the cost). You can help protect your source code by using the Encrypt option in the Project Information dialog box, clearing the Debug Info option there, and setting debug in your application. The Setup Wizard helps you through the process of creating user-installable distribution disks.
One of VFP's major contributions to the Xbase world is the demonstration that it is indeed possible to have a data dictionary built around the .dbf file format. VFP supports the notion of a database that consists of one or more tables and associated files that conform with data dictionary rules. I like the ability, through the Table Designer, to create table relationships by visually connecting appropriate indexed fields. The VFP data dictionary supports long table and field names, comments for each field/table, field captions for Browse windows and Grid columns, field default values, primary and candidate keys, field- and table-level rules, triggers, stored procedures, local and remote views, and persistent relationships among the tables. The data dictionary facility enables VFP to enforce referential-integrity rules at the database engine level, rather than in code. Tables that are part of a VFP database have altered file header records and are not typically recognizable by other Xbase dialects, including earlier FoxPro versions. One way to convert them to free tables (which are compatible with FoxPro 2.x) is to use the fox2x type clause in the copy to command.
Visual FoxPro supports 32,767 work areas. Think that's not enough? Then, how about this: That's 32,767 work areas per data session, and you can have a lot of data sessions as well. This all seems impressive, but you'll probably never take advantage of it because you can have only 255 files open at one time. VFP tables can have General fields that contain embedded or linked data from other Windows applications such as Word or Excel. It also supports data from any ODBC source, including the popular SQL databases. As I mentioned previously, client/server applications may use either SQL pass-through or remote views.
As in Visual dBASE, Visual FoxPro's data session facility lets you simulate a shared (network) environment on a single PC. VFP implements both row-level and table-level buffering, so you no longer really need to use memory variables for data-entry forms; instead, you can collect data against the current record and still roll back any changes at the last minute. Your application has a choice of two buffering modes. In a row-level pessimistic buffering scheme, the record is locked as soon as you change the data, preventing others from accessing the record. In row-level optimistic buffering, the record is locked only at the instant you save the changes to disk. Naturally, transaction processing is also supported in the SQL database servers.
VFP's built-in report designer is also a banded, WYSIWIG report writer similar to those in Visual dBASE and CA-VO. With it you can easily create reports with standard layouts such as columnar, list, label, and multicolumn (telephone directory, for example). A Report Wizard is available to help you generate a one-to-many report involving parent/child tables, similar to that in Visual dBASE. As in earlier FoxPro versions, the report specification is written to .frx and .frt files. Report output may be directed to the screen (Preview), printer, or file. New in VFP is the to ascii clause of the report command, allowing reports to be recorded to a text file free of graphics and printer codes.
You have already seen that VFP supports OCXs, and can act as an OLE client. That is, OLE objects can be embedded both in tables (inside General fields) and in forms. The VFP Professional Edition comes with four OLE custom controls: a serial communications OCX, a messaging API (MAPI) session OCX, an outline OCX that allows list items to be displayed hierarchically, and a picture clip OCX, so you can display a selected bitmap area in a form or picture box. Similar to Visual dBASE and CA-VO, VFP can access functions in DLLs created elsewhere.
You may have noticed that FoxPro has always attracted substantial third-party support. A major reason for that is its ability to be extended through API libraries. VFP API libraries contain functions that behave, for all intents and purposes, like those built into the product. Such libraries can call back into the VFP environment and manipulate objects, variables, and just about everything else. API libraries are really DLLs that are usually created with a C++ compiler. Because VFP is a 32-bit application, it requires a 32-bit compiler. The API facility is sufficiently documented and support files are provided with the Professional Edition.
VFP comes with a comprehensive set of manuals, including a Language Reference manual and a Quick Command Reference guide. Novice users can get going with the aid of the User's Guide. The Developer's Guide gives you everything you need to know to develop VFP applications. Serious developers would want to consult the Professional Features Guide, which discusses client/server issues, the FoxPro API library facility, how to build graphical Help for applications, and how to prepare a finished application for distribution to users.
I have several clients who constantly worry whether they should be standardizing on any one of these products, or even on any Xbase product at all. The Microsoft-allied clients worry that VFP will be dropped in favor of Microsoft Access, despite repeated assurances from the Redmond top brass. I admit it doesn't help that some Redmonites have been talking lately of folding VFP into the Visual C++ IDE. Borland-allied shops fear that all Borland development efforts are being channeled into Delphi, which could only mean that dBASE and Paradox will wither on the vine. And Computer Associates-allied clients apparently keep hearing rumors that CA-VO will be replaced by a PC version of CA-OpenIngres. To all these clients I say: chill out.
All of these tools are hard to beat for rapid application development. You can be up and running in days, and even if the world ends on these products, your schema and processing logic will probably survive. Those millions of Xbase developers can't all be wrong, can they?