Managing Classes with Visual FoxPro

Microsoft Corporation

November 1996

Introduction

Microsoft® Visual FoxPro™ excels in its support for object-oriented programming. When working in an object-oriented environment, managing class libraries is an issue of critical importance.

This document discusses the issues relating to managing class libraries, including who should do the management and what Visual FoxPro tools and commands assist in this important task.

Why Manage Classes?

Visual FoxPro stores classes created with the Visual Class Designer in visual class libraries (.VCX files). What’s involved in managing them?

Managing class libraries is not something to take lightly. The power of object orientation lies in the use of a framework that is reused throughout multiple applications and throughout an organization. Therefore, it is important to manage your framework. Consider this: an application framework may consist of hundreds of classes on which you base other classes for your applications.

In order to properly keep track of your classes, you probably want to keep them grouped in a logical manner in different files. For example, the “base classes” in the framework might be stored in a class library called CONTROLS.VCX. Another library might have more specialized versions of these controls. There may be a file, UTILS.VCX, that has utility classes. The list here is limitless. When you put all these disparate class libraries together, you have a basis for creating all your applications.

Now, imagine what might happen if someone modifies the TextBox class that serves as the “framework base class” (as opposed to the TextBox class that is built into Visual FoxPro) and introduces a bug to it. That bug can ripple through applications in the same way that a bug in a procedure can ripple through to every application that calls it.

The key, then, is to ensure proper control over the class libraries.

Class Library Structure

Typically in an organization, you may see as many as three levels of class libraries. The first set of libraries is a corporate-wide set of standard libraries. The corporate framework and standard utilities, for example, may be in these libraries.

A specific department or business unit within a company may have a more specialized set of classes that they use across their applications. For example, a set of base business classes can be created for each business unit.

Finally, each application will have class libraries specifically for its use.

Figure 1 shows, in an organizational chart, the hierarchy of a corporate library.

Figure 1. Class library structure

The Class Librarian

Each level of classes requires a Class Librarian—an individual responsible for managing the libraries. The Class Librarian’s job, simply put, is to control what goes into the class libraries. At the corporate level, a corporate Class Librarian is responsible for the content and integrity of the corporate framework. Each department has individuals with similar responsibilities. Finally, the leader of each application project, or another designated person, manages the application libraries.

Criteria for Inclusion in Class Libraries

It would be unfair to assume that the class libraries at any level should be static and not subject to change; as time goes by, enhancements can and should be introduced. Developers who work on applications might have significant contributions to make to the framework in terms of new and enhanced classes. No one is suggesting that this should not take place—just that it should be controlled.

Classes created for inclusion in the class libraries at any of the three levels can be created by the developers and stored in a temporary .VCX file. When the developer is satisfied that the classes are complete, the classes can be submitted to the appropriate Class Librarian for consideration.

The Class Librarian should carefully review each class for:

Completeness: The class must accomplish the agreed-on responsibilities. It should also trap the appropriate errors and be properly developed.
Standards: Many organizations have standards, such as variable, property, and method naming conventions; commenting requirements; and so on. If the code does not strictly meet these standards, the class library can be difficult to maintain.
Documentation: Any good class library is well documented. A good rule for the librarian is to accept only classes that have sufficient documentation. The documentation should discuss issues surrounding the public interface such as which methods are callable, which are public properties, what the public properties do, what they return, and so on. The documentation must be complete enough so that someone who is totally unfamiliar with the class can use it in the course of developing applications, either directly or by subclassing it.
Robustness: The robustness of a class refers to how resistant the class is to errors. For example, if a bad parameter is sent to a method, the method should gracefully catch the error.
Compatibility: The Class Librarian must ascertain that the new class will not break any old code. It is a good idea to have a test case for every new class so that subsequent versions can be tested for compatibility. It should be taken as an axiom that any new or modified class must be properly and completely tested against existing code. This should be viewed as a primary responsibility of the Class Librarian.

Merging the New Classes

Once the submitted classes have been reviewed and approved, the next step is to merge the classes into the class libraries.

Merging classes into the class libraries should take place at regular intervals, perhaps once a week or once a month. A rapidly changing class library removes the element of stability that is important to developers.

In addition, once merging is complete, the Class Librarian should inform all the users of the class libraries of the changes and additions that were made. Never make a change to the class libraries without telling everyone about it. In this manner, if something does accidentally break, the developer will have an idea where to look.

Technical Aspects of Managing Class Libraries

On the technical side, there are three basic actions that a librarian normally has to take to manage classes in a library:

Copy or move a class between class library files.
Change the name of a class.
Remove a class from a class library.

Visual FoxPro has commands for each of these tasks.

Copying a Class

The ADD CLASS command is used to copy a class from one visual class library file to another. Here’s the syntax:

ADD CLASS <ClassName>;
   [OF <ClassLibrary1>] ;
   TO <ClassLibrary2> ;
   [OVERWRITE]

ClassName is the name of an existing class. The class may be already accessible in a .VCX file loaded with SET CLASSLIB or it may be a .VCX file that you specifically reference from <ClassLibrary1> with the optional OF <ClassLibrary1> clause. The name of the .VCX file to store the class in is specified with the TO <ClassLibrary2> clause.

If the class already exists in <ClassLibrary2>, an error will be generated by Visual FoxPro to prevent accidentally overwriting a class in a class library. The OVERWRITE keyword overrides this message and allows you to overwrite a class.

Moving a Class Between Class Libraries

In order to move a class, you need to copy it into the new class library and then remove it from the original one. There is no MOVE CLASS command.

Renaming a Class

The name of a class in a visual class library file may be changed with the RENAME CLASS command. For example:

RENAME CLASS <OldClassName> ;
   OF <ClassLibrary> ;
   TO <NewClassName>

OldClassName is the class name as it exists in the .VCX file prior to renaming. ClassLibrary is the name of the .VCX file and NewClassName is the new name for the class.

Be very careful with this command. If you rename a class, it only affects the one class. Any classes that are subclassed from this class will no longer be able to find it.

Removing a Class

The REMOVE CLASS command removes a class from a class library, as follows:

REMOVE CLASS <ClassName> OF <ClassLibrary>

ClassName is the name of the class to remove; ClassLibrary is the name of the .VCX file to remove it from.

Be careful with this. Removing a class is very dangerous in that it can break the chain in a class hierarchy. For example, if you have a class hierarchy and remove one of the classes in the middle of the hierarchy, you will invalidate everything from the class you delete on down. You will not be able to edit those classes in native Visual FoxPro because the hierarchy has been broken.

So, what do you do if you accidentally remove a class? The simple answer is to open the .VCX file as a table and use the RECALL command to retrieve the records you just deleted.

If you want to delete a level from a class hierarchy, Visual FoxPro does not have a command to do it. You can do it with the Class Browser Redefine feature, which is discussed below.

Managing Classes Visually

Visual FoxPro has the commands to perform the rudimentary functions associated with managing class libraries. Adding, removing, and renaming cover the bulk of what you want to do.

Although they get the job done, they aren’t very pretty. After using the Form Designer and the Class Designer, developers would be disappointed if they had to manage class libraries by hand alone. Fortunately, they don’t. That’s where the Class Browser comes in.

The Class Browser

The Class Browser is a Visual FoxPro application (written entirely in Visual FoxPro) designed to provide a user-friendly, visual way to work with and manage class libraries. Loading a class library into the Class Browser provides all the functionality previously discussed, and much more, at the touch of a mouse button.

There is one interesting note about the Class Browser to make up front. You may think of the Class Browser as a tool used only for managing classes. However, since the file structures of a form and a class are identical, the Class Browser also allows you to load .SCX files. This is really nice in that most (but not all) of the Class Browser functionality works equally well with a form and class.

Figure 2. The class browser

Here are the elements of the Class Browser interface.

Form caption

The title of the Class Browser form shows the name of the currently selected class and the name of the .VCX/.SCX file it belongs to.

Action buttons

At the top of this modeless form is a series of command buttons that launch the bulk of the Class Browser actions. These are described in Table 1.

Table 1. Class Browser Action Buttons.

Open	Opens an existing class library (.VCX) file, creates a new class library file or opens an existing form/form set (.SCX) file. Any open files will be closed.
View additional file	Adds an existing class library (.VCX) file or a form/form set (.SCX) file to the class list or creates a new class library file. This is useful when the parent class of a class in a .VCX file is stored in a different .VCX.
View class code	Exports the code for the currently selected class and shows it in a window. If the currently selected class is the .VCX file itself, the entire class library is exported in one click.
Find	Searches for specific text in class names, class descriptions, member names, and member descriptions.
New Class	Creates a new subclass based on the currently selected class. To create a new subclass in a .VCX file based on a Visual FoxPro base class, position the list on the .VCX file item and then click New Class.
Rename	Changes the name of the selected class, property, or method. Caution: Renaming a class might invalidate forms or classes that are not currently displayed in Class Browser windows and that rely on the class. Changing the name of a property or method can cause code that references the property or method to fail.
Redefine	Changes the parent class of the selected class.
Remove	Removes the selected class or deletes the selected file. Caution: Removing a class or file might invalidate forms or subclasses that rely on the class.
Clean up class library	Runs the PACK command to remove records in the .VCX file marked for deletion.

Starting the Class Browser

Starting the Class Browser can be accomplished in one of two ways. From the Tools menu, select Class Browser. A dialog box appears asking for the name of the class library to load. If you type the name of a class library that doesn’t exist, the Class Browser creates it for you.

The second way to load the class Browser is to use the _BROWSER system variable. _BROWSER is typically set to BROWSER.APP, which is located in the Visual FoxPro home directory. Issuing the following command is equivalent to using the menu:

DO (_BROWSER)

You can also pass a parameter containing the name of the class library to load. For example, the following code loads ABOUT.VCX for the TASTRADE sample application:

DO (_BROWSER) WITH HOME()+"samples\mainsamp\libs\about"

Optionally, a second parameter can be added to the command that will automatically select a particular class in the list. For example, the following code loads the ABOUT library and selects the class called AboutBox:

DO (_BROWSER) WITH HOME()+"samples\mainsamp\libs\about", "aboutbox"

Specifying a form file name directly works too. The following code starts the Class Browser with the form CUSTOMER.SCX loaded:

DO (_BROWSER) WITH HOME()+"samples\mainsamp\forms\customer.scx"

Conclusion

Microsoft FoxPro® has a tradition of being not only an excellent language and database but also an excellent development environment. Microsoft Visual FoxPro follows this tradition. Not only have new features been added to the product that revolutionize database applications development, the tools provided with the product ease the advanced tasks associated with creating and managing classes.

The Class Browser is a model not only for the functionality it brings but also for its open architecture. The Visual FoxPro Help file documents the objects, properties, events, and methods contained in the Class Browser. The Class Browser, as a class, allows us access to practically all of its internals. This makes it not only easy to use, but incredibly powerful.

Acknowledgments

We acknowledge the help of Flash Creative Management, Inc., Hackensack, NJ, in providing portions of this material.