At DevCon 95 and all during the Visual FoxPro beta, the conventional wisdom was that developers should subclass all of Visual FoxPro’s base classes. I went with the crowd at first, then I changed course and used the VFP provided base classes directly. This article is about a bad decision and a learning experience that I want to pass along to the readers of this fine publication. I debated this process all during the beta and finally saw the light I was looking for.

The Basics

Visual FoxPro comes with 29 base classes. These internally defined classes are provided by Microsoft and cannot be modified directly. You can use these classes directly within an application, and you can subclass them. The conventional wisdom in the FoxPro community is that the base classes shouldn't be used directly in your applications. Instead, each should be subclassed, and you should use those subclasses (and other subclasses derived from these) in your applications (see Table 1). This will allow you to customize and standardize each class to have the functionality, look, and feel that you prefer. All the changes made to the subclassed base classes are then propagated throughout the applications using the power of inheritance.

Table 1. Visual FoxPro base classes and standard name prefixes

Base Class	Naming Prefix
CheckBox	chk
Column (*)	grc
ComboBox	cbo
CommandButton	cmd
CommandGroup	cmg
Container	ctr
Control	ctl
Custom	cus
EditBox	edt
Form	frm
FormSet	frs
Grid	grd
Header (*)	hdr
Image	img
Label	lbl
Line	lin
ListBox	lst
OLEBoundControl	olb
OLEContainerControl	ole
OptionButton (*)	opt
OptionGroup	opg
Page (*)	pag
PageFrame	pgf
Separator (*)	sep
Shape	shp
Spinner	spn
TextBox	txt
Timer	tmr
ToolBar	tbr

(*) These classes cannot be subclassed in the Class Designer because they belong to a parent container.

There are also undocumented base classes that can be subclassed only programmatically with DEFINE CLASS: the DataEnvironment, Cursor, and Relation.

There are definitely some things you will want all of a specific object type to do that Microsoft did not default to or provide. This is your chance to customize the different properties, events, and methods in the classes. One example is to base all the TextBox objects in an application on your personal TextBox base class. Microsoft has defaulted the text color to black. If you want all TextBox objects on every form you create to have a blue foreground color, it is as simple as setting the ForeColor property to blue using VFP’s property sheet and color picker to modify your personalized base class. The inheritance built into Visual FoxPro will propagate the change to every TextBox object based on your TextBox class to blue. Another example might be to change the FontName or FontSize properties so all your form objects are consistent within an application (provided you don’t break inheritance).

How to subclass the base classes

There are several ways to create a personalized set of base classes. I prefer to create them using the Visual Class Designer. Start out by typing the following in the Command Window:

CREATE CLASS

You can also use the File|New menu option or New icon on the standard toolbar to get the New File Dialog. You then select the Class option button and the New File command button to bring up the New Class Dialog (see Figure 1).

Figure 1. New Class Dialog

The New Class Dialog is very straight forward. Fill in the name of your new class. The "Based On:" combobox is where you select the parent class to your personalized base class. The combobox dropdown list contains each of the VFP base classes that can subclassed visually. Finally type in the Visual Class Library file name or use the ellipse to select an existing library. I recommend keeping all your personalized base classes in one Visual Class Library. Once you complete the dialog, the Class Designer is started so you can modify your new class. Use the property sheet to alter any properties, events, or methods to your personal specification. This is very easy to do (don’t worry I won’t tell your customers or the boss). I think it took me no more than five to ten minutes to initially set up my current set of personalized base classes.

Drag and Drop is Lost

There is a downside to subclassing the base classes. One of the more frequently demonstrated and talked about features at DevCon 95 was drag and drop. You can quickly set up a Form’s data environment by adding tables from a database container or from free tables. You can then drag and drop fields from the tables in the data environment to the form. The newly added objects to the Form will take the default base class for the field data type. Most fields default to the TextBox base class. Logicals will default to the CheckBox base class, memo fields will default to the EditBox base class. If you drag the table on to a form you will get a grid base class object. This is extremely slick and works as advertised.

If you set up your own "base" classes (a visual class library of subclassed base classes) Visual FoxPro won't know to default these dragged objects to your set of base classes. Unfortunately there is no way to get these objects to use your base classes without some customized VFP Builder/Wizard. Such a routine would be fairly difficult to write, because it would have to actually change the class of the objects dropped, which would - as far as I know - require operating directly on the .SCX file outside of the Form Designer. This would make seamless integration with the development environment difficult to achieve.

This seems like a lot of work to me. I've spent enough time learning the basics of this product; I don't want to start writing utilities to change base class properties. I'm sure some developer will eventually come up with this solution, but I don't want to wait.

So the choice is as simple as “drag and drop, or customized base classes”. It is an unfair choice, but one I think each developer will need to make at some point early in their VFP apprenticeship.

A Solution Finally Realized

I talked with several developers during the beta on this topic. The debates never lead to a clear solution or reason to go one way or the other. It wasn’t until I started developing some “production” screens that I finally realized why I wanted to create my own base classes. The decision was two-fold (and in order of importance):

Microsoft defaults for properties and methods
I don’t think every developer will agree on every default that Microsoft came up with for every property and method. I know I have changed a few basic properties. I have also added a few properties of my own and I’m sure a method or two will get added over time as well. This is where the real power is.
Naming conventions
I was tired of each new object added to the form being named Label1, TextBox1. I then had to change it to lblAddress or txtAddress, in order to conform to the Microsoft-recommended naming standards. For example my base class TextBox is called txtTextBox. This way each TextBox already starts with the naming convention adopted from industry standards. All I have to do is substitute the “TextBox1” part with the objects real name. It is a small time savings for production screens, and significant time for prototype screens that get productionized later. I also don’t need to look up the standards in the help file when I forget them.

Using Your Personalized Base Classes

The classes are easy to create, but you might be asking “how easy are they to use?” Fortunately the Microsoft Fox Team made the use of Visual Class Libraries as easy as they are to create. There is a View Classes icon (books) on the Form Controls toolbar that you can press. Select the Add... menu option to select your personalized Visual Class Library. The toolbar will change to reflect your base classes.

You can set up Visual FoxPro to pre-load the View Classes menu with customized visual class Libraries. This is accomplished by using the Option Screen Form Page (see Figure 2).

Figure 2 - Adding visual classes to the View Classes menu

Basic Base Class Modifications

I have made some basic modifications to my personalized base classes. The BackStyle property of Labels and CheckBoxes defaults to “0 - Opaque” which will drive you nuts if they have moved to a form color other than white. I have modified my Label and CheckBox base classes BackStyle Property to “1 - Transparent”. I don't really understand Microsoft’s thinking on this one, but we are provided simple ways to make these changes.

Another change that I find even more critical is my base class for Forms (called frmForm). This is my form Template Class that is set on the Option Screen dialog box (see Figure 3). Each new form created is based on (or if you prefer, "inherits from") my template form class instead of the built-in Form class. This way, as I develop my forms and come up with my application development methodology, all I have to do is make changes in one place. If I add a custom property or method, each of my forms based on my template form class automatically inherits the new value or functionality.

Figure 3 - Setting the template form

Conclusion

I decided that the "modify once, propagate everywhere" philosophy is the way to go. Losing the drag and drop functionality was a small price to pay. I now add objects one at a time to my forms. I add an object, make any changes I need and then copy the first object over and over. For example, I'll add a TextBox object to my form and modify the appropriate properties. I then copy that object to the clipboard and paste it on the form when I need another TextBox object. This procedure saves me time in the long run.

Another concern I have with personalized base classes is adding another “layer” in the class hierarchy. I have not performed, nor have I seen, an analysis on how this impacts runtime performance. Theoretically, it should slow performance slightly because Visual FoxPro has another layer to traverse as it looks for property values and to execute methods (this would be another excellent article).

I hope this article provided some insight on a topic which will probably be debated over and over as Visual FoxPro developers learn more about this exciting product. If it saves you some time in making a decision or provides you with more arguments for going one way or another, then I have accomplished what I set out to do.

On this month's Companion Disk I've provided my current visual class library VF3BASEC, which contains all of the subclassed base classes that I use in my applications.

This site is designed to be viewed in 800x600 video resolution or higher, but it should work fairly well at any resolution and with any of the major browsers (all free!). Optimized for MS Internet Explorer, Firefox, and Opera (mostly works with Mozilla and Netscape Navigator).