Printing - FoxTalk - dFPUG-Portal

January 1996
Extend the Visual FoxPro Class Browser
with Add-Ins
Ken Levy
The Class Browser provided with the Professional Edition of Visual FoxPro takes the term "open
architecture" to new heights. If you don't like the Class Browser, you'll learn how to customize it to
your heart's content.
Working with and managing class libraries isn't easy. Visual FoxPro's Class Browser provides an
easy, user-friendly interface for dealing with Visual Class Libraries (if you're not familiar with
the Class Browser, see the sidebar, "Class Browser Basics"). However, ease of use represents
only a fraction of its power. The Class Browser also supports the unique ability to be totally
customized using what are known as add-ins.
Flexibility and the Class Browser
The key to a tool is how well it can work in getting a job done. Managing class libraries carries
with it a myriad of chores, from checking the code in a class to merging it with the production
libraries.
In many development environments, the Class Librarian molds the way they do their jobs into
the way the tool they use allows them to perform their tasks. Visual FoxPro, in true keeping with
the history of both Microsoft's Visual development tools and the FoxPro product line, not only
provides a simple to use tool for managing class libraries but has also made the architecture of
this utility totally open so that it can be customized to fit the needs of every individual. This
customization is accomplished using add-ins.
An add-in is a program that you write and "register" with the Class Browser. Once registered,
this program can execute automatically in response to an event in the Class Browser or can be
called manually by the user. An add-in can do just about anything you like. Here's an example of
an add-in program:

* Program...........: CLSNAME.PRG
*) Description.......: Simple add-in for the Class
*) : Browser that
*) : displays the current class' name.
* Calling Samples...:
* Parameter List....:
* Major change list.:
LPARAMETERS toSource
WAIT WINDOW toSource.ProperBaseClass(toSource.cClass)
RETURN
Note the parameter. The Class Browser, when calling the add-in, passes itself as a parameter to
the add-in, meaning all the member objects, properties, events, and methods are available for
reference. In the example just shown, the Class Browser's ProperBaseClass() method and cClass
property are used in the add-in.
This capability allows you to do many things. You can use the information in the Class Browser
to guide what you want to do (for example, if the currently selected class is really the .VCX file,
you could loop through all the classes in the .VCX as opposed to just the class currently
selected), access the methods or even get at the .VCX table itself. Understanding and using this
powerful feature is key to creating add-ins.
First let's cover the nuts and bolts of registering and running add-ins.
Registering add-ins
Before you can use an add-in, it has to be registered. The Class Browser has to be running in
order to do this:
_oBrowser.AddIn("Class Name", "ClsName")
The AddIn() method registers an add-in. The syntax shown here specifies a name for the add-in
(Class Name) and the program to run (ClsName.Prg). The name is case-insensitive, but the way
it's specified here is the way it will show in the add-in menu.
Running the add-in
The add-in can be run in several ways. First of all, you can run it with the DoAddIn() method:
_oBrowser.DoAddIn("Class Name")

Passing the name of a registered add-in to the DoAddIn() method will run that add-in.
You can also call the add-in with the add-in button. Clicking on the add-in button activates a
menu with the installed add-ins. The same menu can be expanded manually with the
AddInMenu() method as follows:
_oBrowser.AddInMenu()
Running this method will expand the menu at the location of the mouse pointer. You can close
the menu with _oBrowser.DeactivateMenu(), although you shouldn't need to because the menu is
automatically closed when a selection is made.
Unregistering an add-in
You can also remove an add-in from the Browser Registration table with the AddIn() method:
_oBrowser.AddIn("Class Name",.NULL.)
If the program name is provided as a value of .NULL., the add-in record in the browser
registration table is marked for deletion.
Creating custom add-ins
Add-ins let you control many events and extend or override existing behavior. The previous
example is a trivial one that simply displays the name of the currently selected class. It
accomplishes this by accepting the object parameter (remember, the Class Browser form object
is the parameter) and then accessing the Class Browser's cClass property in the WAIT
WINDOW command.
While this example isn't particularly useful, it does illustrate a few key concepts. First, by
sending itself as the parameter to the add-ins, every add-in has access to the full power of the
Class Browser. That's why it's so important to take the time to learn about the objects, properties,
events, and methods of the Class Browser (they're all documented in the Visual FoxPro help
file). Another key point here is that there isn't much that an add-in can't do for you.
Here's another example of an add-in: This one inserts additional header information to the code
exported with the Class Browser's ExportClass() method. It's useful when you have to represent
a class in code. You may need to do this for system documentation, when writing articles or
books, and so forth:

* Program...........: DOCCLASS.PRG
*) Description.......: DocClass is an add-in program for
*) : the Class Browser that exports
*) : the code for a class with a
*) : standard heading at the top.
* Calling Samples...:
* Parameter List....:
* Major change list.:
LPARAMETERS toObject
#DEFINE cr_lf chr(13)+chr(10)
_cliptext = toObject.ExportClass()
LOCAL laHdrLine[5], lcText, lnCounter
laHdrLine[1] = "* Class.............: " + ;
toObject.ProperBaseClass(toObject.cClass)
laHdrLine[2] = "* Author............: " + ;
"Joe Developer"
laHdrLine[3] = "* Project...........: " + ;
"My Project"
laHdrLine[4] = "* Copyright.........: " + ;
"(c) My Company, Inc. 1995"
aHdrLine[5] = "* Notes.............: " + ;
"Exported code from Class Browser."
lcText = ""
FOR lnCounter = 1 TO ALEN(laHdrLine,1)
lcText = lcText + laHdrLine[lnCounter] + cr_lf
ENDFOR
lcText = lcText + cr_lf
_cliptext = lcText + _cliptext
=MessageBox("Code exported to clipboard!", 32)
RETURN
In theory, this add-in is very simple. The ExportClass() method is used to dump the code for the
class into the Clipboard (modifying _CLIPTEXT modifies the Clipboard). The array holds the
additional header lines, which are then added -- with carriage returns and linefeeds -- to the
output text. Then you can paste the outputted text wherever it's needed.
This is a fairly good example of an add-in in that it automates a procedure and reduces it to two
simple mouse clicks.
Changing Class Browser behavior with add-ins
By installing add-ins in the manner shown earlier, you can run it by selecting a class, clicking on
the add-in command button, and selecting the appropriate menu item.

Sometimes an add-in most appropriately enhances or replaces existing functionality in the Class
Browser. For example, the DocumentClass add-in can be viewed as analogous to the View Class
command button. You could say it would be appropriate to hook this add-in not to the add-in
menu but rather to the RightClick event of the View Class button.
To show how this is done, let's take a closer look at the syntax of the AddIn() method:
AddIn(, ;
, ;
, ;
, ;
, ;
)
is the name of the add-in. The name can be one or more words and case isn't
important except that it will display on the menu in the same manner as you specify here. The
add-in will display in the add-in menu if the third parameter (Method Name) isn't specified.
is the name of a program to run. The program can be a .PRG, .APP, .EXE, or
.FXP. In addition, you can specify an .SCX. The assumed extension is .PRG; specify other
extensions as appropriate.
can also be the name of an object. The syntax for this would be , for example:
_oBrowser.AddIn("MyAddIn", "MyVcx.VCX, MyClass")
When the add-in is run, the class MyClass of MyVcx.VCX is instantiated. Remember that an
object parameter will be sent through to the class.
It's a good idea to specify a full path to the program in this parameter, ensuring that the add-in
runs properly wherever you are in your hard disk. If the Class Browser can't find the program or
.VCX when trying to call an add-in, an error will be generated.
is the name of a method to automatically call the add-in. Any valid method,
either a method of the Class Browser form or one of its objects, can be a hook for a method. For
example, if you want to hook MyAddIn to the Export CommandButton's RightClick event, you
can use the following code:
_oBrowser.AddIn("MyAddIn", , "CmdExport.Click")
By the way, you don't have to specify the second parameter in this command. This allows you to
change the registration of an add-in only as much as you need. In this case, since the program
that will run when MyAddIn is run doesn't change, there's no need to specify that parameter.

Leaving it blank will pass a logical .F. to the corresponding parameter variable in the Class
Browser's AddIn method. The AddIn() method is intelligent enough to understand that an empty
parameter means that the corresponding value remains unchanged.
The third parameter is the key to this task. By specifying the cmdExport.RightClick method in
the third parameter, the add-in is hooked to that event and will be called by that event when it
fires.
If you hook into a method that already has behavior (for example, the click method of
cmdExport calls ExportClass()), the add-in will run first, followed by the original behavior. If
you have multiple add-ins registered for a method, they will run in the order they were
registered.
Finally, if you want to totally override the behavior of a method (for example, you don't want
cmdExport to call ExportClass()), the add-in must set the lNoDefault property of the Class
Browser to .T. If this property is set to .T., the Class Browser method will detect this and won't
execute the rest of its code. It's not necessary for the add-in to reset lNoDefault to .F.; the Class
Browser does this automatically just before it calls any add-in.
allows you to determine which files the add-in will work for. By default,
when an add-in is added to the Class Browser registration table, it's available for all .VCX and
.SCX files you may work with. This parameter allows you to specify a file or list of files
(separated by commas) that this add-in will be available for. For other files loaded into the Class
Browser, the add-in will in effect simply not exist.
specifies the platform (for example, "Windows") the add-in will work in. By default,
it is available for all platforms.
is an optional comment you can store with the add-in.
If you take a close look at the AddIn() method, it provides a wealth of insight into the power of
the Class Browser and its flexibility. Add-ins allow you to customize the Class Browser to run
your code at almost any interval. For example, assume you prefer to use Courier New as the font
for the Class Browser. All you need to do is create an add-in like this and register it for the Init()
method:
* Program...........: FONTSET.PRG
* Author............: Menachem Bazian, CPA
* Copyright.........: (c) Flash Creative Management, Inc., 1995
*) Description.......: Set the fonts for the Class
LPARAMETERS toSource
toSource.SetFont("Courier New")
RETURN
To register it:
_oBrowser.AddIn("FontSet", "FontSet", "Init")

Summary
As you can see, the Class Browser is quite malleable. Most aspects of its appearance and
behavior can be modified with just a little bit of coding to suit your particular needs and tastes. I
hope that this article has inspired you to explore the Class Browser and use it more effectively in
your work.
Ken Levy is a software engineer at Flash Creative Management Inc., a consulting and software
development firm in River Edge, New Jersey. Ken spends most of his time working in the Los Angeles
area, specializing in the research, design, and creation of application development tools. While working
as a full-time consultant at NASA's Jet Propulsion Laboratory in Pasadena, California, Ken developed
several public domain programs including GENSCRNX, PTX Editor, and other FoxPro tools.
201-489-2500, CompuServe 76350,2610.
Sidebar: Class Browser Basics
The Class Browser in FoxPro 3.0 (see Figure 1) is written in FoxPro and is specified by a system
variable named _BROWSER, which defaults to _BROWSER=SYS(2004)+'BROWSER.APP'.
The Class Browser opens a single visual class library (VCX). The Class Browser is included
with the Professional Edition of Visual FoxPro and allows you to see the structure of a visual
class or form at a glance, view equivalent code, change the class hierarchy, and so on.
The Class Browser user interface
The Class Browser is launched by selecting Class Browser from the Visual FoxPro Tools menu.
This causes Visual FoxPro to execute the program defined in a system variable called
_BROWSER. The Class Browser supports both visual and non-visual (Custom) classes. Multiple
instances of the Class Browser can be launched. Selecting Class Browser from the Tools menu
always launches a new instance; the window list on the Window menu is used to activate an
existing instance.
If the Class Browser form is resized, the controls will be resized and moved to fit the available
space. If the Class Browser form height is changed, the class display outliner and the member
form pages height will change. If the Class Browser form width is changed, the class display
outliner, member form pages, class description, member/instance description, and class type
combo box height will change. Classes can be moved from one .VCX to another using
drag-and-drop.
Using Class Browser with Class Designer and Form Designer
Components of an application are developed in the Class Designer (which saves the class in a
VCX) by creating classes visually, while applications are assembled from those components in
the Form Designer (which saves forms in an SCX). Not every line of method code and every
property setting needs to be saved as a class when building an application. Adding code and
setting properties of objects in an SCX makes sense if you don't intend to reuse specialized
changes. The SaveAsClass function makes it easy to create classes in a .VCX from objects in an

SCX, should you need to subclass the functionality of a form.
Since an individual class library can contain any number of classes, and the Class Designer can
edit only one class at a time, the menu and command line interfaces to access the Class Designer
are clumsy. It's much easier to navigate a class hierarchy in the Class Browser and invoke the
Class Designer for the class you've selected in the Browser.
The Class Designer allows developers to create classes visually. These classes can be either
visual or non-visual (Custom) subclasses. Custom properties and methods can be added to a
class and will appear in the Properties window for visual editing. The Form Designer allows
forms to be created by subclassing existing classes by dropping them onto the form surface from
the Controls toolbar.
The object model in Visual FoxPro supports container classes. Container classes are classes that
can contain objects as members. For example, Forms and FormSets in an SCX are containers.
The FormSet can contain Form objects, while the Form can contain control and Custom objects,
as well as other containers such as OptionGroups and CommandGroups. The Toolbar class is a
container that can contain control objects. Control classes such as the CommandButton class
aren't container classes since they can't contain objects.
If you experiment with the Save As Class dialog box in the Form Designer, you'll notice that you
can save controls as classes into a .VCX . You can also select multiple controls and save all
selected controls. You can even save an entire form (including its object members) as a single
class. When you select an individual control (or just the form) and you save the selected (single)
object as a class, you are creating a class based on the object's classification. When you save a
group of selected controls or the entire form that contains controls into a single class, you are
actually saving a container class.
A Wild Ride, But Worth It
Bob Grommes
I've been editor of FoxTalk now for two and a half years. During my watch, FoxTalk has grown
from 24 to 32 pages, we've redesigned the visuals, added many new features, and covered the
release of FoxPro 2.6 and Visual FoxPro. Two and a half years ago we still struggled with 286
client machines; now we fret about those slow 386 machines and how to shoehorn applications
into 8M of RAM. Less than a year ago, we passed arguments to functions, and now we send
messages to methods. As the saying goes, "the only constant in this business is change."
But what really defines the essence of an experience are the people -- subscribers and the staff at
Pinnacle alike. My experience as editor has been a richly rewarding time of service to the
FoxPro community. I've made a lot of friends, had a lot of fun, and grown tremendously.
So it's with many warm memories like these, and with more than a little regret, that I've decided
to leave my post as editor to concentrate on other projects, including a Visual FoxPro book
planned for late 1996. It was a difficult decision. Thank you for your letters, suggestions, and

constructive criticisms. I treasure them all. The loyalty of FoxTalk subscribers is something to
behold. You really care about this publication!
I hope you'll be as kind to my successor, Whil Hentzen . Whil needs little introduction: he's been
a regular columnist in FoxTalk since before my time, has served the past few months on our
Editorial Advisory Board, and is probably one of the best-connected and best-liked folks in the
Fox community. He's president of Hentzenwerke Inc. in Milwaukee, Wisconsin, a FoxPro
development firm that each November sponsors the Great Lakes Great Database Workshop for
FoxPro developers. In addition, Whil is a driving force behind the FoxPro user group in his area,
as well as the author of the new book Programming Visual FoxPro 3.0 from Ziff-Davis.
Somehow, he finds the time to run competitively and raise three children with his wife, Linda.
I hope that you'll take a moment to extend Whil a warm welcome (he can be reached on
CompuServe 70651,2270).
I won't be disappearing entirely from these pages; indeed, I may have more time to write articles
than I did as editor! I wish you and yours the best of success in the coming years, and invite you
to keep in touch (I can still be reached on CompuServe 74126,72).
Tip: Set Focus to a Control When a Record is
Added
William O'Connor
To set focus to a particular control when a record is added, add a new property to your form
called cAddfield. Then add this method and give it the name of your choice:
* This method requires the form to have a property
* called cAddField. cAddField MUST contain a fully
* specified object path pointing to the object.
* For example:
* cAddField = 'PageFrame1.Page1.txtEmployee'
* Please note that this will set focus, but won't change
* the page to show the field if it is on the non-current
* page of a pageframe.
IF TYPE("THISFORM.cAddField") = "C" AND ;
NOT EMPTY(THISFORM.cAddField)
cObjName = ALLTRIM(ThisForm.cAddField)
= EVALUATE("THISFORM." + ALLTRIM(cObjName) ;
+ ".SetFocus()")
ENDIF

If you named this method SetFocusOnAdd, you'd execute it just after adding a record using a
call like this:
THISFORM.SetFocusOnAdd()
Why not just call the SetFocus method for the specific object directly? Because maintaining and
subclassing the form is easier this way, particularly if you need to perform this operation from
many places within your form, or even from outside the form (say, in an object that manages
database access or in a stored procedure). In that latter situation, you could issue a command like
this:
_SCREEN.ActiveForm.SetFocusOnAdd()
William O'Connor is a senior programmer with ContrAcct Systems Corp. of Naperville, Illinois. E-mail:
bocon@aol.com.
Liven Up Your Applications with 3-D
Graphical/Text Push Buttons
Paul Russell (1)
While Visual FoxPro allows you to combine text and graphics on the same control, it's also possible
to achieve the same effect in FoxPro 2.x for Windows; indeed, this technique may at times still be
necessary in Visual FoxPro to get the effect you want because text is always displayed centered
under the graphic.
Push buttons aren't the most exciting object in a FoxPro application, especially the ones that
shipped with early versions of Windows 3.0 applications. They had the requisite text, and you
could tell that they were a button, but they weren't very interesting. With more powerful
computers, and with developers always striving to be more flashy, this has been changing. We
have gone from the old style push button, like the two images on the left in Figure 1 (the button
in the middle is actually a Windows 95 push button), to a combined image plus text push button,
like the one on the right in .
As you click on the buttons on the left, the text responds by moving down and to the right,
giving the impression that the button is being "pushed in." Then, when the mouse button is
released, the buttons resume their normal appearance, giving the impression that they have

"come back out."
The button on the right behaves a bit differently. When you click on this button, the text and the
shadow below the check mark are moved down and to the right, but the arrow itself stays in its
original position. This gives the impression that this button has depth and is a bit closer to being
3-D.
How do you do this?
You need to combine a number of tricks to get this to work in FoxPro for Windows 2.x (this
obviously won't be relevant for the character-based versions of FoxPro, and it doesn't fit with the
look and feel of the Mac). Essentially, you have to do the following:
• Load multiple images for a single button.
• Generate the images that you want to display.
• Adjust the position of the second image.
• Allow for white space if necessary.
• Load multiple images for a single button.
FoxPro has three states for a push button: Up, Down, and Disabled. Using this information, you
can have one image for the "Up" state of the button, and another for the "Down" state. To
include different bitmaps for the different states, separate them with commas.
Unfortunately, the Screen Builder supports only a single image for each button. This is because
it verifies that the file exists, and then surrounds the filename with code to allow the user to find
it at runtime, just in case it wasn't included within the .EXE file.
This means that you have to use GENSCRNX to override the image definition of the @ GET
command. In the Comment snippet of the push button that you want to change, in this case the
"OK" push button, include this GENSCRNX directive:
*:PICTURE OK_UP.BMP,OK_DOWN.BMP
This will replace the LOCATE() function that GENSCRN puts into the .SPR file with your
definition. You can also construct the list of images in a memory variable and insert the
following GENSCRNX directive:
*:PICTURE m.lcButtons
Generate the Images that you want to Display
Using the "OK" button as an example, you want the green portion of the arrow and the text to
remain in one place and the shadow to move one pixel down and to the right. It's easiest to

generate the "un-pressed" image first, and then reload the image into your bitmap editor and
make the changes manually. (I usually prefer to do this while Zoomed into the image so that I
have a better view of the pixels themselves.)
Figure 2 shows the two images generated by this process. The text in the second button has been
moved up, and that the shadow underneath the arrow has been moved down and to the right.
When these two images are set up in a screen, you'll see that the shadow in the pressed button
moves, but so does the rest of the image. This is because FoxPro moves the whole image down
and to the right by a single pixel. This needs to be countered.
Adjusting the position of the second image
Moving the second image up and to the left by one pixel corrects the look of the button. The
arrow and "OK" text stay in their original position, but the shadow will move down and to the
right by two pixels. Figure 3 shows the two final images.
Allow for white space if necessary
In bitmaps, white represents the background. When FoxPro sees white in the bitmap, it turns it
into whatever color required for the button background, gray for the "un-pressed" button and
light gray for the pressed button. This becomes obvious if you have gray as the background of
the button image (try some of the sample buttons that Microsoft ships with FoxPro for
Windows).
You can display the color white on your buttons, but the method isn't obvious.
If, for example, you want to mimic the appearance of the Windows 3.x Information message
box, you will want to have a white exclamation point inside a blue circle. Typically, this would
be drawn as shown in Figure 4.
As you might have guessed, the problem with this is that the exclamation point will be the same
color as the background behind the button: gray in the un-pressed button and light gray in the
pressed button.
You can override this default appearance by creating a "mask" of the image. A mask is a .BMP
file that has the same filename as the original image, but with .MSK as the extension. Of course,
the easiest way to create this is to define the bitmap that you want first, then copy it to a file with
the .MSK extension (see Figure 5).
The mask file contains only two colors: black and white. Wherever the color is black, the image
itself shows through. Where the mask is white and the image is white, the background of the
button shows through, and where the mask is white and the image is anything other than white, it
seems like a negative of the image shows through. Table 1 shows this a bit more clearly.
Table 1. Mask file vs. the image.
White areas of .BMP Non-white areas of .BMP
White portion of .MSK file Button Background Negative of the .BMP color

Black portion of .MSK file White The .BMP Color
Conclusion
The FoxPro manual shows most of the commands and functions that you can use along with
some straightforward examples. What the manual can't show you is what you can do with this
information. Whenever I see constructive, inventive interface and reporting requirements, I try to
figure out what the author did to get that effect. Frequently, as with both of the examples here,
the answer was staring me in the face in the manual.
RTFM (Remember The "Fantastic" Manual), because it can frequently solve an elusive problem.
The manual might not be the easiest or the best place to look for an answer, but it should be the
first place that you look.
Paul Russell, a software specialist with Software Kinetics Ltd., is chairman of the Fox Users of Nova
Scotia, and is an active member of the FoxPro sections on the Internet. He has been programming for
more than 10 years, with more than seven of those years of experience with the Fox product line. Internet
prussell@fox.nstn.ca, or russell@atl.sofkin.ca, CompuServe 102440,2125.
Subclassing Visual FoxPro Base Classes
Richard A. Schummer (2)
To subclass or not to subclass, that's the question. When, if ever, should you use Visual FoxPro base
classes directly in your applications?
At DevCon 95 and 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, but then I
changed course and used the Visual FoxPro-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 can't 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 them) 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

ase classes are then propagated throughout your 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 cnt
Control ctl
Custom
EditBox edt
Form frm
FormSet frs
Grid grd
Header * grh
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 can't be subclassed in the Class Designerbecause they belong to a parent container.
[There are also undocumented base classes that can be subclassed onlyprogrammatically with DEFINE CLASS:
DataEnvironment, Cursor, and Relation.-- Ed.]
There are definitely some things you'll want all of a specific object type to do that Microsoft
didn't 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 set the default the text color to black. If you want all

TextBox objects on every form you create to have a blue foreground color, it's as simple as
setting the ForeColor property to blue using Visual FoxPro'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. Begin by typing the following in the Command window:
CREATE CLASS
You can also choose New from the File menu or the New icon on the standard toolbar to get the
New File dialog box. Then select the Class option button and the New File command button to
bring up the New Class dialog box (see Figure 1).
The New Class dialog box is very straight forward. Fill in the name of your new class. The
"Based On:" combo box is where you select the parent class to your personalized base class. The
combo box drop-down list contains each of the Visual FoxPro base classes that can subclassed
visually. Finally, type in the Visual Class Library filename or use the ellipse button to select an
existing library. I recommend keeping all your personalized base classes in one Visual Class
Library. Once you complete the dialog box, 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 10 minutes initially to 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 most 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 on
the form will take the default base class for the field data type. Most fields default to the
TextBox base class. Logical fields will default to the CheckBox base class, and memo fields will
default to the EditBox base class. If you drag the table on to a form, you'll 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 own classes. Unfortunately, there's
no way to get these objects to use your base classes without some customized Builder or 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 the solution, but I
don't want to wait.
So the choice is as simple as "drag and drop or customized base classes." It's an unfair choice,
but one I think each developer will need to make at some point early in their Visual FoxPro
apprenticeship.
[Here's something to think about that might make the decision easier: since a data environment
can be associated only with a form, saving a form as a class causes you to loose its data
environment. In other words, data environments can't be visually subclassed, so you have to set
one up for each individual form you create. Some developers feel this is enough of a liability that
they are willing to forego the visual data environment designer altogether. Instead, they create
DataEnvironment container classes programmatically, attaching code to each form's Load or
Init events to manually instantiate the appropriate DataEnvironment object for the form. If you
buy into this argument, then subclassing becomes almost a "no-brainer," since with this
approach you can't drag and drop fields from the data environment anyway. -- Ed.]
A solution finally realized
I talked with several developers about this during the Visual FoxPro beta. The debates never led
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
reasons were 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've changed a few basic properties. I've also added a few properties of my own,
and I'm sure a method or two will be 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 having names
like Label1 or TextBox1. This required me to change the name to lblAddress or
txtAddress in order to conform to Microsoft-recommended naming standards. I solved
this by naming each of my base classes to conform to the Microsoft naming convention.
For example, my base class TextBox is called txtTextBox. All I had to do is substitute
"txtTextbox" for Microsoft's default name, "TextBox1." At design time, this results in
TextBox names defaulting to txtTextBox1, txtTextBox2, and so on, a significant time
savings. 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 FoxPro team made using Visual Class Libraries as easy as they are to create. There
is a View Classes icon (it looks like some books on a shelf) on the Form Controls toolbar. This

ings up a pop-up menu. Choose the Add menu option to add your personalized visual class
library to the menu, then choose your library from the menu. 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. Do this by using the Controls page of Visual FoxPro's Options dialog box (choose
Options from the Tools menu; see Figure 2).
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 you've moved
to a form color other than white. I've modified the BackStyle property of my Label and
CheckBox base classes to "1 - Transparent." I don't really understand Microsoft's thinking on
this one, but thankfully we have 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 Form page of Visual FoxPro's Option 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 existing form based on my template form class
automatically inherits the new value or functionality. [If you use FormSets, you might also want
to create a template FormSet class. For detailed information on how form and FormSet
templates interact, see the topic, "Using Form and Form Set Templates" in Visual FoxPro's help
file. -- Ed.]
Conclusion
I decided that the "modify once, propagate everywhere" philosophy is the way to go. Losing 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 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 haven't performed, nor have I seen, an analysis of 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. [FoxTalk is
preparing an article with benchmarks on this topic. -- Ed.]
I hope this article has provided some insight on a topic that will be debated over and over as
Visual FoxPro developers learn more about this exciting product. If it saves you time in making
a decision or provides you with more arguments for going one way or another, then I've
accomplished what I set out to do.

In download file _SCHUMME.EXE, I've provided the visual class library VF3BASEC, which
contains all of the subclassed base classes that I use in my applications.
Rick Schummer has been a FoxPro developer by day and night since 1989. He's also the president of the
Sterling Heights Computer Club and a co-founding member of the Detroit Area Fox User Group. He
enjoys camping and cycling. CompuServe 70254,1643.
The Tracks of My Tiers
Robert Green
One buzzword making the rounds these days is "three-tier architecture." What is it, exactly, and
what's it good for? And how do you implement it in Visual FoxPro?
If you've been following developments in the client/server arena lately, you've no doubt heard
about three-tier application development. It's a hot topic, and we should spend some time
thinking about it. What is three tier? Can it be implemented in Visual FoxPro? How? And what
about one tier and two tier?
If buzzwords followed the same rules as software versioning, we would have moved directly
from one tier to three tier. In fact, there really are three models. A one-tier architecture exists
when the client and the server are the same environment. This describes the applications you
build solely using FoxPro. The data, the forms it gets entered into, and the rules that control it
are all written in the same place and run in the same place. Whether you access data directly
from tables or through views and whether your rules are in code snippets or triggers, you have a
single application layer: Visual FoxPro.
In a two-tier architecture, the data is moved to another environment and is accessed through the
first tier. This describes traditional client/server applications. The data resides in a back end such
as SQL Server or Oracle. The front end is responsible for the user interface (the forms, menus,
and so on). In a traditional two-tier architecture, the business rules are often enforced entirely on
the back end.
In a three-tier architecture, the business rules are stored in their own environment, typically on a
separate computer so multiple front ends can use it. The front end supplies the interface, the back
end supplies the data, and the middle tier takes care of enforcing the business rules. This means
that you have two client/server conversations, one between the front end and the middle layer
and one between the middle layer and the back end. The front end never talks directly to the
back end.
There are two main benefits to a three-tier architecture. The first is that you have more layers
splitting up the work. You have three pieces to the application, user interface, data, and rules,
and you have three layers to handle the chores. The second benefit is that it's easier to reuse your

usiness rules because they aren't buried in either the front or the back end. If you coded all of
your data validation rules in Visual FoxPro, then it would be difficult to reuse them in, say, a
Visual Basic or Access application. If they were sitting in their own layer, then any front end
could use them to send data to any back end.
This is the general idea of two- and three-tier architectures. In practice, you have more flexibility
in how you structure your applications if you're using Visual FoxPro to build a client/server
architecture. In a two-tier architecture, you can enforce the rules entirely in the back end, entirely
in Visual FoxPro, or in both places. For example, if a rule is that prices can't go up by more than
20 percent, you can do this in SQL Server with a rule or constraint. You can do this in Visual
FoxPro in the Valid event of a text box.
This is a pretty simple rule to enforce. If you enforce it in Visual FoxPro, the user gets instant
feedback and the back end doesn't have to spend time checking the price. If you have 100 users
entering 200 orders a day each, this adds up to a lot of work the back end doesn't have to do. If
the only front end accessing the back end data is your Visual FoxPro application, then you might
wind up putting the bulk, maybe even all, of the data validation code into the front end.
But what if other front ends need to access the data? If Access and Visual Basic applications can
enter or edit orders, then you would want to validate price on the back end. As a wise person
once said, "Write once, use many." If the only other applications to access the data were written
in Visual FoxPro, you could write FoxPro code and share it, perhaps through a stored procedure
or a data validation class.
In a three-tier architecture, you can still split the work by enforcing data integrity in the front
end. If the middle tier is the only one responsible for making sure that price increases are
acceptable, then are you overly burdening that layer? What will you gain by either duplicating or
moving the rule enforcement into Visual FoxPro on the front end?
What is the middle layer written in? The Visual Basic team wants you to write the middle layer
in Visual Basic, using VB 4.0's new ability to create OLE servers. The OLE server could be
called from Visual FoxPro using OLE Automation. Data would be passed to the middle layer,
which would validate it. If the data were rejected, the middle layer would let FoxPro know about
it. If the data were good, it would be sent on to the back end and FoxPro would be told.
You would use this VB middle layer from Visual FoxPro the same way you use any OLE
Automation server. You might issue the following to start a conversation with the server:
oData = CreateObject("VBServer.BizRules")
When you wanted to send data to the middle layer, you might issue the following code:
oData.Send("Update employee Set salary = 87000000")

To see if the data was valid you might use the following code:
If oData.ValidData
= MessageBox("Success")
Else
= MessageBox(oData.ErrorMessage)
Endif
Note that the previous syntax is speculative. Your actual implementation may vary.
What are the downsides to this approach? You won't be able to write client/server applications
using Visual FoxPro's remote views, at least in this version of the product. Also, sending data via
OLE should be slower than sending it via ODBC.
You could write the middle layer in Visual FoxPro. When the front end wants to save data, one
option is to store it in a table sitting out on the network somewhere. The middle layer is a Visual
FoxPro application that constantly polls the table for new data to be validated. The data is either
rejected or is sent to SQL Server. The middle layer could store a success or failure message in a
table. The front end would then query that table and find out if the data it sent were valid or not.
Compare that to writing the same validation rules in a stored procedure and putting that in a
database. Each Visual FoxPro application could open that database and run the validation code
in the front end. Only valid data is sent on to SQL Server. Does the three-tier architecture offer
any benefit over this?
I hope this column has raised some interesting questions about how to implement a three-tier
architecture using Visual FoxPro. In the months to come we'll explore this issue further. In the
meantime, let me know what your thoughts are. As always, FoxPro's the best. Pass it on!
Robert Green is a vice president with The Information Management Group, a Chicago-based Microsoft
Solutions Partner and Authorized Technical Education Center specializing in consulting and training in
Microsoft database products. He was a speaker at the 1993 and 1995 International FoxPro Developer
Conferences, and his articles have appeared in Data Based Advisor, FoxPro Advisor, and FoxTalk.
312-280-1007, CompuServe 76104,2514, Internet rgreen@imginc.com.
Tip: Get Object References by Location
Ken Levy
If you ever need read or write access to a visible object, either in design mode or in run mode,
follow these steps:
1. Activate the Command window
2. Place the mouse over the object you want to get a reference to.

3. In the Command window, enter o=SYS(1270). The PUBLIC memory variable o is now a
reference to the object.
4. Address the object as needed. Example: o.Caption = 'Foo'
5. When you're finished working with the reference, you should probably destroy the reference
by executing o=.NULL. or o=.F. or RELEASE o. If the object you reference is a control in a
container, you may not be able to release the container until all the references are released.
[SYS(1270) and three other new SYS( ) functions are documented in the README.HLP file that
comes with the Professional Edition of Visual FoxPro. -- Ed.]
Ken Levy is a software engineer at Flash Creative Management Inc., a consulting and software
development firm in River Edge, New Jersey. 201-489-2500, CompuServe 76350,2610.
Do You Know Who Your Parents Are?
Barbara Peisch
Here's some hard-won wisdom in dealing with the idiosyncrasies of designing and using visual
classes in the Class Designer and Form Designer. These workarounds will save you many hours of
experimentation as you design increasingly elaborate forms.
So, you're ready to start your first Visual FoxPro project. You've been reading all the articles and
going to seminars, and you think you're prepared, right? Well, maybe not. There are many cases
in Visual FoxPro where the default or intuitive approach either gives you something you didn't
want or makes it impossible to easily make changes in the future. This article will point out some
"gotchas" in building and using class libraries that you may not have heard about.
Classy alternatives
You may have heard that you should never instantiate the Visual FoxPro base classes directly. I
agree with this because there's no way for you to change the properties of the Visual FoxPro base
classes, and we all know how often you want to change things after you finish a program [for
more information on subclassing the base classes and why you should, see "Subclassing Visual
FoxPro Base Classes" by Richard Schummer, FoxTalk, November 1995. -- Ed.].
In fact, I recommend a minimum of two levels of class libraries: first, a global class library that
inherits directly from the Visual FoxPro base classes. You'll use this library to set standard
attributes for all your applications. The second is a library for each client (or perhaps each
application) you write. This gives you the ability to change a property for all instances of a
particular object for that client or application without affecting every other Visual FoxPro
application you've written. This may seem like unnecessary duplication at first, but you will be
much happier when your client decides to change the behavior of all the text boxes in the
application six months after you deliver the finished product.

Look Ma, no buttons!
When you create your standard library, there are some things you will probably want to change.
Some of these are a matter of taste, like the BackColor property of an object. Some you have
probably heard are good practice, like making your forms use private data sessions. But there's
one handy change you probably aren't aware of: changing the object count of container objects to
zero. This includes the OptionGroup, CommandGroup, and PageFrame objects. (I didn't include
FormSet in this list. We'll cover that later.)
I can hear you saying, "Why would I want my base Option Button Group to have a button count
of 0? I'll always want at least two buttons, so why not define the base class that way?" The
reason for this is that you can't change the Name property of objects in the container that were
instantiated from the parent class. In other words, you'll always have to refer to Options 1 and 2
as "Option1" and "Option2" instead of "OptFile" or "OptDisplay." This may not seem like much
at first, but when you have a lot of option groups nested deep in your container hierarchy, it will
become a big deal.
I'd like to give you a word of warning about making the PageCount of your PageFrame class 0.
There's a problem with using an object based on the Container class when it's on a Page that
didn't exist in the immediate parent class. The problem is that most, if not all, of the objects in
the Container will either disappear or be strange sizes. (When I say "Container," I'm not referring
to all container objects, like grids or OptionGroups. I'm referring only to the class called
"Container.") To illustrate this problem, follow these steps:
1. In the Class Designer, create a class based on the Container object. Put two labels and two text
boxes in the Container and save the class.
2. In the Class Designer, create a PageFrame class with a PageCount of 0.
3. Create a new form.
4. Create a PageFrame on the form by dragging your newly created PageFrame class from the
toolbar.
5. Change the PageCount to 2.
6. Right click on the PageFrame and select "Edit." Select page 1 by clicking on it.
7. Drag your new Container class from the tool bar and drop it on the page.
8. Click on Page 2 and drop the Container object on it.
You'll notice that you can't see the labels or text boxes in your Container on either page. Save
this form and return to the Class Designer. Change the PageCount of your PageFrame to 1.
When you modify your form in the Form Designer, you'll notice that the Container on page 1
now looks fine but is still wrong on page 2. If you go back and increase the PageCount of the
PageFrame class to 2, the second page will look fine.
The point is your global PageFrame class can have zero pages. But if you plan to use a Container

on a page frame, you'll need a subclass with the pages that will hold Containers objects.
Use SetAll to set common properties
One problem you may have run into with container classes (I'm talking about all container
objects now) is setting certain attributes for all the items you'll want to create in that container.
For example, you may decide that you want the BackColor property of all the option buttons
within your option group to be gray.
You don't want to create an option group with the maximum number of buttons you'll need with
the expectation that you can reduce the number of buttons when you instantiate the option group.
Although you can remove these buttons with RemoveObject() at runtime, you can't reduce the
number of controls at design time. You also don't want to go through the hassle of having to set
the BackColor for each and every button in the group. This fails to take advantage of container
polymorphism.
Instead of laboriously setting a property for each object, you can use SetAll(). Put this nifty
command in the Init method of the container to change a specific property for all of a particular
kind of item in that group. For example, the following code will change the BackColor of all the
options within a group to gray:
THIS.SetAll('BackColor',RGB(192,192,192),'OptionButton')
Now, don't worry when you drop an option group on your form and the BackColor on all the
options is white. Remember, you don't actually run the Init code until you run the form. Any
properties that you set in this manner won't be visible until runtime.
Of course, it's possible to create a builder to set all the properties at design time, or even to use
SetAll() from the Command window at design time if you first select the container and get a
handle to the form with ASELOBJ():
=ASELOBJ(o,1)
o[1].SetAll('BackColor',RGB(192,192,192),'OptionButton')
If you need to change this property, it's easier to go to the container's Init method and change a
single runtime SetAll() call. Also, if you use the runtime SetAll() and later add more objects to
the container, they will automatically share the properties of the existing buttons. You don't have
to remember to change the properties for the new objects. Personally, I find these advantages
outweigh the disadvantage of not being able to see the property settings at design time, but you
may feel differently.
Is your data dragging you down?
You've probably seen at least one Visual FoxPro demo where someone dragged an item from the
data environment and dropped it on the form to create a text box for that item. If you want to use

your own subclasses, don't do it like that. Text boxes you create that way will always be
instantiated directly from the Visual FoxPro base class! The same goes for creating a grid by
dragging the title bar of a table onto the form. If you don't believe me, just check the Class
property of the text box or grid. And note that this class property is in italics, so you can't change
it.
A little discipline on your part will prevent such headaches. Whenever you create or edit a form,
always do the following:
1. Change the toolbar to show your own library instead of the Visual FoxPro base library. (No,
Visual FoxPro won't always "remember" it from the time before.) To do this, click on the books
icon. Then select your library if it's already shown, or choose "Add" and find your library.
2. Always create objects on the form by dragging them from the tool bar. You can then change
the ControlSource property for the item to whatever you want. Other techniques that work
equally well are to drag-and-drop from either the project manager Class tab or the Class Browser
onto the form.
You can have your cake and eat it too by using Andy Griebel's GAPP utilities. GAPP will allow
you to change the class property of objects after you put them on your form [see Whil Hentzen's
"Cool Tool" column in the November 1995 issue for details. -- Ed]. This means that you can drag
and drop from the DataEnvironment and use GAPP to change the class afterwards.
Figuring out forms and FormSets
Now, let's get back to the FormSet. Always have a least one form in each FormSet. Visual
FoxPro won't let you set the FormCount to 0. Even worse, when using the Class Designer, the
initial form created with a FormSet always inherits directly from the Visual FoxPro base class.
This is true even if you have set a form template on the options screen.
By creating your global FormSet with the Form Designer instead of the Class Designer, your
initial form will inherit from your own Form class:
1. Set a Form template to your base form class by selecting Options from the Tools menu. Do not
set a template for a FormSet yet.
2. Create a new form in the Form Designer.
3. Click on the Form menu pad and select Create FormSet.
4. Click on the File menu pad and select "Save as class." Make sure you select the option to save
the entire FormSet. Select whatever name you want for your standard FormSet class.
You can now set your FormSet template to your new template class.
There is one disadvantage with this FormSet: You can't change the Name property of the form
inherited from the parent class. You can set the Name property in your global FormSet subclass,
and if you want the first form in all your FormSets to have that same name, then it's not a
problem. If you want to assign new names to the first form on each FormSet subsequently

created, however, you must use only forms added in the Form Designer. To remove the original
form (which you can't rename), use "THIS.RemoveObject('')" in the Init method of
your FormSet to remove the form you can't name. To make sure you don't accidentally use this
form in the designer, change its size to the minimum in the Class Designer and move it down to
the lower right corner of the FormSet; otherwise, you'll end up putting objects on this form and
wonder where they went when you run it.
Don't forget that if you want Visual FoxPro to use your form subclass when you create a new
form, you must go to the "Tools...Options...Forms" screen to specify the class to use for forms.
Make sure you press the "Set as Default" button before you exit if you want this option to be
restored the next time you run Visual FoxPro. You may notice that there are two sections on this
screen, one for your default FormSet and one for your default form.
If you define both a default FormSet and a default form, the FormSet template will be the one
used when you create a form. If you want a single form, first add a new form (so you can name
it). Then remove the first form and the FormSet. If you plan on using FormSets, you should set
templates for both the FormSet and Form so that Visual FoxPro will use your form class when it
adds forms to FormSets.
Avoiding gridlock
Grids can be a little time consuming to set up properly. The problem is that the control for
columns in a grid will by default be the Visual FoxPro base TextBox class. Telling Visual
FoxPro which library to use for its grid text boxes is one thing you can't do with a call to SetAll
in the Init method as I discussed earlier. This is because all the items in the container are
instantiated by the time you run the container's Init method. Once an item is instantiated, you
can't change its class.
If you create a grid with a column count of -1, you'll have no control over naming column
headers or what controls go where. So, although there's no problem in your grid's subclass
having a column count of -1, you'll want to change that when you actually use the class at design
time.
First, get around the problem of the base TextBox class being used in grids by deleting these text
boxes and putting in your own controls. The only way to delete the text box is to select the text
box from the property sheet, click on the title bar of the form or the grid itself (make sure you
don't click outside the grid), and press the delete key. You should see the TextBox icon
disappear from the grid column. At this point you can drag any control from your toolbar and
drop it on the column.
You can drop multiple controls in the same column. Only one control can be visible at a time, as
determined by the CurrentControl property for the column.
Conclusion
I hope I've given you some techniques that will make your life easier when using Visual FoxPro.
Most of the tidbits in this article came from many hours of frustration and help from fellow

programmers. I hope my hours of exploration will save you some time.
Barbara Peisch is a partner with Gersztyn, Peisch and Associates, which specializes in custom software.
She has been with the firm since 1988. 619-268-4639, CompuServe 70303,1064.
Ignore Deleted Records, Set Form Template
Defaults, and More
John V. Petersen
My application runs with SET DELETED OFF, but I want to ignore deleted records in a
particular form. I issued the command SET DELETED ON set in the Load method of my
form, but the views in my Data Environment still includes the deleted records in the result
set. It's my understanding that the Load method is the proper place to put my data
session-specific SET settings. In addition, I'm using private data sessions. What am I
missing?
The best answer depends on whether you use the DataEnvironment. If so, the first event that
fires is actually BeforeTablesOpen. This event belongs to the DataEnvironment, not the form. By
the time the form's Load method fires, the query associated with the view has already been
executed. The problem is that your SET DELETED setting was still OFF when
BeforeTablesOpen fired, which means that your query saw the deleted records and brought them
into view.
One solution is to place your SET settings in the BeforeTablesOpen method of the
DataEnvironment. If you don't want to put your code there, you can take the following steps:
1. Set the NoDataOnLoad property of the view cursor object to .T.
2. In the Load method of the form, enter SET DELETED ON.
3. In the Init method of the form, make a call to the REQUERY() function. This causes the query
to occur after you SET DELETED ON.
I like the idea of form template defaults that can be set in the Forms Section of the Options
dialog box under the Tools menu. However, it becomes quite burdensome when I have
multiple forms classes and have to continually reset the template Visual FoxPro uses. Is
there an easier method?
I'll outline two solutions: one prescription is for folks who have the Professional Edition and the
Class Browser, and the other is for folks who use the Standard Edition. First, the solution for the
Standard Edition users (this will also work in the Pro Edition as well):
The trick is to employ a pre-3.0 FoxPro trick: hacking the .SCX file. Every object on a form has

a record in the .SCX. Two fields in the .SCX that are of interest here are the Class and Classloc
fields. By default, all forms created are based on Visual FoxPro's base class definition.
Therefore, the default values of Class and Classloc are Form and an empty string, respectively.
Assume that your class definition, called 'MyForm', is contained in 'MYLIB.VCX'. Further
assume that MYLIB.VCX is contained in the same directory as your .SCX. It's merely a task of
changing the values of Class and Classloc to 'MyForm' and 'MYLIB.VCX', respectively. When
changing the Classloc value, make sure to enter the relative path if the class library isn't in the
current directory. Finally, close the .SCX and open the form. Your form should now be
inheriting from your MyForm class.
For those of you who have the Professional Edition (and therefore the Class Browser), the
procedure is a bit simpler. First, open the Class Browser and instead of opening a class library,
open your form. Next, with the form reference highlighted in the outline control of the browser,
press the Redefine button. You'll now be presented with a dialog box to enter a class definition
and the visual class library in which the definition resides. In this example, it will be Redefine
As 'MyForm' Of 'MYLIB.VCX'. Finally, press the Redefine button to save your
changes. The form will now inherit from the 'MyForm' class.
In both cases, I encourage you to make a backup of your form so that you can recover from any
mistakes.
I have a form that uses a series of tables and views. All of the cursor objects in the Data
Environment are set to optimistic table buffering. Additionally, all of the views have the
Send SQL Updates check box checked. Whenever I make changes to a view and issue a
TABLEUPDATE() and subsequently close the form, I get an uncommitted change error
referencing the table that is associated with a view even though a TABLEUPDATE() was
issued. What could possibly be the problem?
The behavior you're encountering actually makes sense when you break the steps down. Views
will respect the buffers of the tables upon which they are based. Since the tables that your view
is based on are already open and are in optimistic buffer mode, when you update a view it
updates the underlying table's buffer, not the disk. Therefore, you must make a final pass through
your tables to commit any changes that have been made. Code similar to the following will do
the trick: (Assume the name of the view is called 'myview' and the table upon which it is based is
called 'mytable'):
BEGIN TRANSACTION
IF tableupdate(.t.,.t.,'myview') AND ;
tableupdate(.t.,.t.,'mytable')
END TRANSACTION
ELSE
** tell the user there is a problem
ROLLBACK
ENDIF

Is there a way to ensure my modal forms will always retain their modal status regardless whether
I generate the screen inside or outside the project?
Sometimes, it's faster to generate one screen than to rebuild the project to see your results. The
best solution is to use the #READCLAUSES MODAL screen generator directive in the Setup
Snippet of the screen. This will ensure that whenever screen code is generated, the READ
command will always have its associated MODAL clause.
John V. Petersen, MBA, is director of FoxPro and Visual FoxPro development for MaxTech Inc., a
consulting firm specializing in database consulting, project development and mentoring, and training
based in Northern Virginia. Working out of Philadelphia, John is active in the FoxPro community, has
written for publications in the United States, and has been a speaker at user group meetings and at the
1995 Developer Days Conference. CompuServe 72722,1243.
Tip: Avoid Two-Dimensional Arrays
Barry Chertov
Many people use two-dimensional arrays with different types of data in each column and use
constants to identify each column, for example:
#DEFINE C_StateID 1
#DEFINE C_Population 2
#DEFINE C_StateFlower 3
DIMENSION StatePop[50,C_StateFlower]
This leads to all sorts of trouble. The first problem is that #DEFINEd constants aren't useable in
the debug window. To solve this, you could be a heretic and use variables that happen to be
constant.
The second problem is that searching is a nightmare. You have to use ASCAN, which doesn't
know about columns. This means it's slower because all the elements are searched, not just the
column you're interested in. At best, it's slow and you then have to use AELEMENT() to get the
row and column number. At worst, you could get misled if the search happens to match on a
unintended column.
Here's the answer: It's a database system! Use a cursor. You can index and search easily using
familiar commands. A two-dimensional array can be useful if it holds only one kind of
information (such as Sales[year,month]).
Barry Chertov lives in Sebastopol, California, and is the primary developer of Foxfire!, a query and
reporting add-on for FoxPro 2.x and Visual FoxPro. CompuServe 73020,1032.

A Glossary of Object-Oriented Terminology
for FoxPro Developers
Ken Levy
Dense terminology is one of the biggest impediments to entry into the object-oriented (OO) world.
This glossary eases the problem by relating the terms to their implementation in Visual FoxPro.
In my article, "Object Oriented Programming: Preparing for a New FoxPro Paradigm" (FoxTalk,
October 1994), I laid a conceptual groundwork for object-oriented programming (OOP) for
FoxPro 2.x developers. That article ran almost three months before the Visual FoxPro beta was
widely available and nine months before the first commercial release of the product. Now, some
six months after commercial release, a second major wave of Visual FoxPro developers are
wading deep into their first significant Visual FoxPro projects. If you didn't see the original
article, you might want to call Pinnacle at 800-788-1900 and order a copy of the October 1994
issue.
In the meantime, here's a glossary of terms that didn't run with my original article due to lack of
space. Although you can learn this terminology from any OOP text, I've optimized this glossary
for the Visual FoxPro developer and covered the terminology quirks specific to Visual FoxPro -something
I wasn't at liberty to do when the original article ran.
Abstract data type
An abstract data type is a data type defined by the programmer that isn't supported by the
language. In non-OOP languages, such as standard C, abstract data types can be constructed
from existing data types that the language recognizes (in C, this is done using language features
such as typedef or struct). In OOP languages, abstract data types are generally high-level
definitions within a program, called classes, from which runtime objects are created that
correspond to real world objects. In Visual FoxPro, this latter type of data abstraction is
supported programmatically through DEFINE CLASS and visually with the Class Designer
(which is usually called from the Class Browser or Project Manager). Runtime objects are
referenced via memory variables of type "O," which serve as references (or pointers) to objects.
Abstraction
Abstraction has the benefit of ignoring irrelevant details of software components and focusing on
only those details required to interface, send messages, and so on. Abstraction includes concepts
such as information hiding and black box routines. Since most real world objects include abstract
details, objects allow a better representation of real world objects than functions do.

Base class
Base class is the root class or most generalized class in a class hierarchy. In the FoxPro world,
the term is used more restrictively to mean the "built-in" classes from which all other classes
must be derived. Examples of base classes in Visual FoxPro include Form, Custom, and
CommandButton.
Class
Class is a blueprint, or template, for defining methods and properties of a particular type of
object. Classes are defined at design time and aren't executed at runtime. Objects are created
based on class blueprints at runtime. Multiple objects can be created (instantiated) from a single
class at runtime. Classes are defined programmatically with the DEFINE CLASS command, or
visually using the Class Designer. Objects are created with the CREATEOBJECT() function.
Class hierarchy
Class hierarchy is a tree structure of classes that represent the relationship between a set of
classes of similar type. The top node of a class hierarchy is known as the base class or
superclass, while related classes below it are known as subclasses. Although you can create any
number of levels of subclasses, most methodologies state that well-defined class hierarchies
shouldn't exceed five levels deep.
Note here an important quirk in Visual FoxPro OO terminology: Outside the FoxPro world, the
term base class means the root or top class in a class hierarchy; in Visual FoxPro documentation,
"base class" means one of the "built-in" classes from which all user-defined classes are derived.
If you're reading OO literature that isn't FoxPro-specific, keep in mind that the term "base class"
is used less restrictively than the FoxPro documentation usually uses it.
Composite (container) object
A composite, or container, object is an object that contains one or more objects. This occurs
when at least one instance variable of an object is of type object (in Visual FoxPro, it also occurs
when an object is defined as a container for other objects; see Instance). Composite objects,
along with delegation, are typical techniques to eliminate the unwanted side effects of multiple
inheritance (see Inheritance).
Delegation
Delegation occurs when an object receives a message and passes it on to another object.
Delegation is useful in "chain of responsibility" situations where an object handles only those
messages it understands, and simply passes on messages it doesn't understand to some other
object. In effect, it delegates responsibilities to other objects. Non-OOP languages can also
support delegation by defining a user-defined function (UDF) that passes its parameters on to
another UDF. The interface to the developer sending the message doesn't have to know about the
internal details.

Encapsulation
Ecapsulation is the concept of methods (procedures or functions) and properties (data memory
variables) packaged together. The result of this packaging is the object. Objects contain both
methods and properties. The methods are referred to as the object's behaviors and the properties
are referred to as the object's attributes.
Inheritance
Inheritance occurs when a class is derived based on an existing class; the existing methods and
properties are referenced for reuse with the new class. A subclass uses all of the methods and
properties defined in the superclasses above it within the class hierarchy. Inheritance can be
broken for individual methods and properties when creating a subclass. This is known as
specialization.
Generally the term "inheritance" implies single inheritance. In some languages, such as C++,
multiple inheritance is supported. In multiple inheritance, a single subclass can be derived from
more than one superclass. Along with the problems of naming conflicts within the union of
methods and properties of the superclasses, multiple inheritance is considered by many software
engineers to be an improper class hierarchy design solution because the combination of
composite objects and delegation is superior to multiple inheritance. Visual FoxPro doesn't
support multiple inheritance.
Instance
Instance is a term that describes a runtime occurrence of an object belonging to a particular class.
Classes are defined at design time, while object instances are created from defined classes at
runtime (in Visual FoxPro, using the CREATEOBJECT() function). An object member within a
container is also an instance (objects can be added to a container at design time with the ADD
OBJECT clause of DEFINE CLASS; they can be added at runtime with the container object's
AddObject() method).
Message
A message is an instruction from one object (the sender) to another object (the receiver) to
execute one of the receiver's methods. The three parts of a message are defined by the receiver
object name, the method name, and any parameters the method might require. Messages can also
be two-way, which occurs when the receiver object's method returns a value to the sender:
* Sending a message to an object
oRegistry.RequestUpdates(THIS)
* Sending a message to an object and receiving a response
lUpdatesOn = oRegistry.RequestUpdates(THIS)
In these examples, oRegistry is the reference to the object, RequestUpdates is a method of

oRegistry, and THIS is a message being sent to oRegistry (in this case, a reference to the object
sending the message). In the second example, lUpdatesOn receives the return message as a
logical value (true if the RequestUpdates method successfully handled the request).
Object
An object is a software collection of related methods (functions) and data (memory variables).
The methods generally act on the associated data. An object generally refers to an instance of a
class.
Parent class
Visual FoxPro documentation uses the term parent class to mean the same thing that most OO
texts refer to as a superclass. See the definition for superclass.
Polymorphism
Polymorphism is the ability to send the same message to various objects while each object is
responsible for acting on the common message. Polymorphism allows a common interface to be
created for objects sending messages. For example, sending the message "Draw" to both a box
object and a circle object would be an example of polymorphism since the message that was sent
to each object had the same name while each object contained its own Draw method. A Draw
method would be defined in both the Box class and the Circle class and each may have similar or
completely different implementations. Polymorphism is supported by allowing the same method
name to be defined within different classes.
Superclass
A superclass is a class that is the parent of one or more subclasses.
Ken Levy is a software engineer at Flash Creative Management, Inc., a consulting and software
development firm in River Edge, New Jersey. Ken spends most of his time working in the Los Angeles
area, specializing in the research, design, and creation of application development tools. While working
as a consultant full-time at NASA's Jet Propulsion Laboratory in Pasadena, Ken developed several public
domain programs including GENSCRNX, PTX Editor, and other FoxPro tools. 201-489-2500,
CompuServe 76350,2610.
Save Space in Memo Fields
Bob Grommes (3)
Here's an overview of how block sizes affect memo field size and fragmentation in both Visual
FoxPro and FoxPro 2.x, plus the scoop on a little-known Visual FoxPro enhancement to memo
fields and some coding tips to reduce memo field "bloat."

Memo fields (variable-length fields in the parlance of many languages) have been with us for a
long time in the Xbase world. Old-timers will recall that they weren't very useful back in the
pre-FoxPro days. One of the most exciting things about FoxPro 1.0 was that memo fields could
handle binary data of arbitrary size, and not just text. Not only that, but we finally got some
useful tools and commands for manipulating memo field data.
But there are some interesting benefits to understanding how FoxPro implements memo fields.
Applying your knowledge of what goes on "behind the scenes" can result in significant,
sometimes dramatic, disk space and efficiency savings, as I'll demonstrate.
Memo field data is stored in an .FPT memo file, which is completely separate from the .DBF
table file. In the .DBF, a pointer is stored to the physical location of the memo data in the memo
file. At that location in the memo file, FoxPro sees eight bytes of data that indicate the number of
blocks the memo data occupies (almost always one block), and the length of the first memo
block. So far, so good.
But FoxPro introduces a wrinkle. When a table is created, the .FPT file is stamped with a
minimum memo field allocation for each value stored. This "memo block size" is determined by
the SET BLOCKSIZE command in effect at the time the table is created.
The SET BLOCKSIZE command is an odd beast, because like many parts of the FoxPro
language, it's saddled with backward compatibility issues. In dBASE III Plus, you could SET
BLOCKSIZE to any value between 1 and 32. If you SET BLOCKSIZE TO , dBASE would
use a block size of times 512 bytes.
This meant that even if you SET BLOCKSIZE TO 1, the minimum value, a minimum of 512
bytes was always allocated in the memo file for the contents of any memo field -- an
extravagance in the days of 20M hard disks!
FoxPro 1.0 extended SET BLOCKSIZE so that if you used a value of 33 or greater, it was
interpreted in bytes instead of 0.5K units. This effectively gave us block sizes ranging from 33
bytes and upwards. The default value for SET BLOCKSIZE in FoxPro is, and always has been,
64.
A hidden treasure
You may not have noticed the new ability to set the memo field block size to "zero" in Visual
FoxPro, using the command SET BLOCKSIZE TO 0. When you SET BLOCKSIZE TO 0,
Visual FoxPro effectively uses a block size of 1 byte -- in other words, the contents of memo
fields can now take up only as much space in the .FPT file as the data demands. More accurately,
a table created while SET BLOCKSIZE TO 0 in effect stores each memo field in a single block
of exactly LEN() + 8 in size. In effect, there is no minimum allocation for a block
of memo data.
For example, consider an .FPT with the following two memo field values stored in it:

This is a test.
X
Ignoring the 512-byte header that appears once at the very beginning of any .FPT, the .FPT
storing these two strings takes up 32 bytes if you SET BLOCKSIZE TO 0 before creating the
table, but takes 82 bytes if you SET BLOCKSIZE TO 33. With the default SET BLOCKSIZE
TO 64, it takes 128 bytes. Clearly, with thousands of records, smaller block sizes can add up to
big space savings.
Incidentally, regardless of the block size setting, there is one more improvement in Visual
FoxPro memo fields. The memo field pointer in a FoxPro 2.x .DBF used to take 10 bytes per
record, whether or not the memo field contained data; in Visual FoxPro, it takes only four bytes
per record. That's a savings of six bytes per record, or about 1K times the number of memo fields
for every 170 records in a table.
What's the best size?
Should you always SET BLOCKSIZE TO 0 in Visual FoxPro (or to 33 in FoxPro 2.x)? Probably
not, but these are generally the best defaults to use. The trade-offs in memo field sizes have to do
with FPT fragmentation.
I've described the "ideal" situation that exists when a table contains nothing but newly added,
unedited records. The trouble begins when you start editing memo fields. Any time you replace
the existing contents of a memo field with a longer string than the original, FoxPro abandons the
original block and rewrites the entire string at a new location in the .FPT. The more often this
happens, the more wasted space in the .FPT, and it's reclaimable only via PACK, PACK MEMO,
or by copying the table. On the other hand, regardless of memo block size, once a block of memo
data is written to the .FPT, values that are the same length or shorter will reside in the same area
and the only wasted space will be the difference between the lengths of the original and the new
values.
It's important to realize that block sizes have to do only with minimum allocations for memo
field data. For example, if you SET BLOCKSIZE TO 64, that doesn't mean that a very long
memo field value will be broken up into dozens of 64-byte blocks that are chained together
through a pointer list; a large memo will be physically stored in a single block. SET
BLOCKSIZE TO 64 just means that 64 - LEN() bytes will be "wasted" if the
memo field value is less than 64 bytes long. But it also means that you can REPLACE any
values you want into the memo field, as long as the values are 64 bytes or less in length, and the
memo data won't be "moved" to a new block, thereby "orphaning" the entire original 64-byte
allocation.
How do you determine the best memo block size for any given table in your application?
Smaller block sizes are ideal for tables where the memo field contents aren't changed frequently,
are generally short in length, or for smaller tables that can be packed frequently. For example,
Visual FoxPro uses a block size of 1 byte when creating forms (SCXs) and class libraries

(VCXs), regardless of what you currently have the memo field block size set to. These small
tables are frequently rewritten and can be packed quickly, and the memo fields usually contain
short strings. Furthermore, SCXs and VCXs are often embedded in .APP or .EXE files, where
space is at a premium. I suspect this latter consideration may have had a lot to do with inspiring
the new SET BLOCKSIZE TO 0 option and the new, more compact memo pointer in the .DBF.
(Incidentally, unlike SCXs and VCXs, database containers (DBCs) are created with whatever
block size is in effect at creation time, just like any other table, while report form tables (FRXs)
are always created with a block size of 33).
Consider larger block sizes when you know that most of your memo field data will consist of
longer strings, or will be changed frequently with data of varying widths.
Analyzing application data
In general, if a table has a single memo field, and you have some idea of what the average length
of the data going into that field will be (ignoring records with no data in the field), then that's
probably your ideal memo block size for that table. The smaller the percentage of records that
actually have memo field data, the closer the block size can afford to approach the maximum
length that the field will ever store.
Often, it's best to let a new application run in the field for awhile and accumulate a significant
amount of data. You can then analyze the contents of the memo fields and adjust the block size
by using SET BLOCKSIZE followed by COPY to create a new table with a more efficient FPT.
If the table isn't too big, you might consider making several copies of it with different memo
block sizes and using the setting that produces the smallest FPT.
However, for an accurate comparison, first do a PACK MEMO on the original table to remove
any fragmentation. Not only will your comparisons be more accurate, but the degree of
fragmentation will be instructive. Even if a particular block size initially yields the best
efficiency, a larger block size may help prevent fragmentation as the file is used use over time.
Things get more complicated if there are multiple memo fields in the table with varying
requirements. Regrettably, the memo field block size is an attribute of the table, not of individual
memo fields. In such situations you'll have to weigh the requirements of each memo field
individually, weight them according to frequency of usage, and come up with a good overall
block size for the entire table.
Block size-related commands
SET BLOCKSIZE doesn't alter the block size of existing tables; it simply governs the block size
of any tables that you create. Any time your application is about to create a table (CREATE
TABLE, COPY, and similar commands), consider what you expect to see in the table's memo
fields and consider issuing an appropriate SET BLOCKSIZE command first.
You can determine the memo block size (in bytes) of existing tables using the SYS(2012)
function against the table once it's open (SYS(2012) returns zero if the table has no memo
fields). You can use SET(`BLOCKSIZE') to determine what your current SET BLOCKSIZE

setting is (in bytes).
A likely problem and its solution
Here's one caveat to observe: the SET(`BLOCKSIZE') function always returns the current block
size setting in bytes. If, for example, you SET BLOCKSIZE TO 1, SET('BLOCKSIZE') will
return 512. If you're changing the block size in a routine and want to preserve and restore the
caller's block size (a technique often used in application startup and shutdown code as well), you
run into a problem. Consider the following code:
nOldBlockSize = SET('BLOCKSIZE')
SET BLOCKSIZE TO 64
* more code here, then reset the caller's block size
SET BLOCKSIZE TO (nOldBlockSize)
If the caller had previously SET BLOCKSIZE TO 0, then SET('BLOCKSIZE') will return a
value of 1, since SET BLOCKSIZE TO 0 produces one-byte blocks. But when you "restore" the
caller's block size, you'll issue SET BLOCKSIZE TO 1, which will create 512-byte blocks, just
like in the good old days of dBASE III Plus! To get around this problem, you need code like the
following instead:
nOldBlockSize = SET('BLOCKSIZE')
IF nOldBlockSize = 1
nOldBlockSize = 0
ENDIF
SET BLOCKSIZE TO 64
* more code here, then reset the caller's block size
SET BLOCKSIZE TO (nOldBlockSize)
REPLACE and fragmentation
A technique you can use to minimize .FPT fragmentation regardless of memo block size is to
avoid repeated REPLACEs on a memo field whenever possible. For example, suppose that you
have code that appends transaction log information to a memo field named TranLog. Perhaps
you need to add several lines to the field. You might have code similar to the following:
FOR n = 1 TO nMessages
REPLACE TranLog WITH CHR(13) + cTransMsg[n] ADDITIVE
ENDFOR
This code extends the memo field on each iteration of the loop, potentially orphaning .FTP file
space each time. It's much better, and probably faster, to build the additional data in memory and

do a single REPLACE:
cNewMessages = ''
FOR n = 1 TO nMessages
cNewMessages = cNewMessages + CHR(13) + cTransMsg[n]
ENDFOR
IF NOT EMPTY(cNewMessages)
REPLACE TranLog WITH cNewMessages ADDITIVE
ENDIF
I once had a text management application that would read in text files, do on-the-fly translations,
and write the text files a line at a time to a memo field. I noticed that the memo file was bloating
by a factor of several hundred K per day, even though no new records were being added to the
table. This coding trick got rid of most of the "bloat."
Conclusion
Fiddling with memo block sizes isn't one of the most pressing issues in FoxPro database
development, but as you deal with larger and larger databases, some attention to detail in this
area can have a significant impact on disk storage efficiency. And, as you saw in the code
examples I just shared, paying attention to the subtleties of syntax can produce big savings, too.
Finally, I suspect that Visual FoxPro is taking us in directions that are likely to cause us to
provide database administration services to clients in addition to application design and
development services. Knowing how to tune memo fields is one skill that will differentiate the
kind of administration you can provide from what the client can do in-house.
Bob Grommes is editor of FoxTalk and president of Software Excellence in Kalamazoo, Michigan.
CompuServe 74126,72.
Ease Form Design Tasks with SUPERCLASS
Whil Hentzen (4)
GENSCRNX fans probably wonder what Ken Levy has been up to since the release of Visual
FoxPro. Wonder no more: he's produced another "must have" that every Visual FoxPro developer
will want in his bag of tricks.
Ever had one of those days? The type of day where nothing goes right? You're working in Visual
FoxProand you have to look at the Language Reference for just about every command you type.
For some reason, you can't remember the syntax for even the simplest commands, like WAIT
WINDOW or SKIP. You even tried to do some simple data entry in a Browse window, but
couldn't figure out why Ctrl-N wasn't working when you were adding new records.

Of course, according to Murphy's Law, you probably have a ton of class and form design work to
do on this type of day. As a result, you keep running into that annoying problem of not being
able to work with a class and a subclass, or a form and the class used to create objects on that
form. Typically, the following happens:
1. Grab a class library and place it on the Form Controls toolbar.
2. Create a form, and place some controls on the form using classes in the class library.
3. Realize that you have to change something about the class -- some property, say, or perhaps
you have to add a method.
4. Try to modify the class, and face that obnoxious error message: "Cannot modify a class that is
in use."
5. Close the form.
6. Modify and save the class.
7. Open up the form again.
8. Try to remember what it was you were doing in the form that required changes to the class.
You get this message because the appropriate record in the class library file (the .VCX table) is
locked when an instance is open in the designer.
SUPERCLASS to the rescue!
Since there's no need for GENSCRNX 3.0 in Visual FoxPro, Ken Levy has spent his time
reading the minds of frustrated developers who are "having one of those days." He created
SUPERCLASS, a utility that enables you to view and edit the methods of an object's superclass.
You'll still have to close the form or class if you want to do other things (like modify properties
of a superclass), but SUPERCLASS will save you hours of opening and closing designers simply
to tweak the method of a superclass.
Using SUPERCLASS is one of those operations that takes longer to explain than it takes to do.
First, run SUPERCLS.PRG. I recommend you put SUPERCLASS in your developer utilities
directory, or somewhere else in your path and run it during Visual FoxPro startup.
SUPERCLASS stays hidden until you open up a method-editing window in the Form Designer
or Class Designer. At this point, the SUPERCLASS toolbar with three buttons appears (see
Figure 1).
SUPERCLASS functionality
The left button allows you to view or edit the superclass method of the object that you are
working onprecisely what you weren't able to do before. Furthermore, it's just a mouse-click
away; you don't have to open up the Class Designer.
However, there's a caveat to be aware of when editing superclass methods. Behind the scenes,
SUPERCLASS makes a temporary .VCX with the record of the Methods field. When you

change the superclass method, those changes are placed in this temporary file. The temporary
file is then closed, recompiled, and the resultant ObjCode field contents are placed in the .VCX.
However, the instance of the original object is still in memory, and this doesn't get changed. As a
result, if you create more instances of that class, these new instances will still contain the old
method code. To prevent this from happening, you'll have to CLEAR CLASS (or CLEAR ALL,
and DO SUPERCLASS again).
The middle button on the SUPERCLASS toolbar allows you to insert a superclass method call in
the current method window at the current cursor position. However, if you're inclined not to read
the documentation, you'll miss a trick. Left-clicking will insert a call to the superclass method. In
other words, suppose you have a command button class called cmdBase, and in the Click()
method of that button, you've placed the following code:
WAIT WINDOW "Jeepers. I'm in the Click method"
If you place an instance of that command button class on a form, opening up the Click() method
of the command button instance will bring forward the SUPERCLASS toolbar. Clicking on the
middle button will insert the following command:
cmdBase::click()
This will execute the parent class code (the Jeepers WAIT WINDOW) in addition to any code
you put in the instance's method. It's just a simple timesaver, but isn't that what I promised earlier
in this article?
Right-clicking on the middle button in the same scenario as the previous example will insert the
following code if you're editing a subclass:
=EVALUATE(this.ParentClass+"::click()")
If you're editing an object member of a container, on the other hand, a right-click will produce
this code:
=EVALUATE(this.Class+"::click()")
If you think that a direct class or parent class might be changed, you might want to use this since
it inserts a generic reference that is evaluated correctly regardless of how the superclass
reference changes.
Finally, the right button on the toolbar brings up the Help file. Now you don't have any excuse
for reading the documentation! And here's a nice touch: Right-clicking on the Help button will

display the version number of SUPERCLASS -- an enhancement we all would do well to
emulate.
Where to find SUPERCLASS
SUPERC.ZIP is public domain software and can be found in download file _SUPERC.EXE as
well as in Library 9 of FoxUser and Library 3 of VFOX.
Whil Hentzen is president of Henzenwerke, a Milwaukee, Wisconsin, software development firm that
specializes in strategic FoxPro-based business applications for Fortune 500 companies. 414-224-7654,
fax 414-224-7650, CompuServe 70651,2270.
Sidebar: Book of the Month
This month's "must have" is the next in a series of three Microsoft Press books on software
development. Writing Solid Code by Steve Maguire (ISBN 1-55615-551-4) is billed as
"Microsoft's Techniques for Developing Bug-Free C Programs," but that shouldn't scare FoxPro
developers. The techniques described in these 250 pages are sometimes specific to C code, such
as "Don't use output memory as workspace buffers" and "Use LINT to catch bugs that your
compiler may miss," and the examples are all in C, but it would be hard to turn two pages in a
row without picking up a valuable idea.
Maguire starts by discussing how bugs come about. He proposes that a programmer ask two
questions about every bug they encounter: "How could I have prevented this bug?", and "How
could I have automatically detected this bug?" He then guides you through assertions, code step
throughs, bug-proof functions, methods to code safer algorithms, risky programming practices,
and finally he covers attitude. "If a programmer regularly `cleans up' code or simply tries
haphazard solutions to problems, hoping to hit upon something that works, writing bug-free code
will be an uphill battle."
In the last chapter he describes a number of real-life events, including the cancellation of an
unannounced Microsoft product due to a runaway bug list, and techniques that could have
prevented those situations. This book is an easy read, but may well be one of the most valuable
books on software development that you can own.
Non-Tabbed Pages: An Alternative to the
Tabbed Interface
Paul Russell (5)

Tabbed interfaces, such as those implemented with Visual FoxPro PageFrames, are useful, but
some users may prefer alternatives. Paul Russell explores an innovative way to implement
multipage forms in FoxPro 2.x for Windows (or Macintosh), and provides a sidebar with tips for
implementing the idea in Visual FoxPro and the character-based 2.x platforms.
By now, most of you have probably become familiar with the tabbed interface style for dialog
boxes. This style was developed for screens that have too much information to display at one
time. For example, the Visual FoxPro Project Manager dialog box has a number of different
"Tabs" across the top, each referring to a specific set of information. This Tab style has become
so standard, in fact, that it has been incorporated as a design tool in Visual FoxPro (see Figure
1).
The FoxPro community is fortunate to have Ken Levy's GENSCRNX with a Tabs driver to
perform the same type of thing in FoxPro for Windows. This tool allows you to have a set of
pages immediately available for a single record, and have all of this information contained in a
single Screen Set.
While this is a useful tool, there are a number of drawbacks. For example, I'm developing an
application with 14 sub-screens that contain information. It would have been impossible to use
the tabbed style and still see what each tab represented (the standard Tabs driver allows only a
single row of tabs that become thinner as more tabs are added). Also, with the standard Tabs
driver, all of the screens are contained within a single Screen Set and all are defined at once. This
displays all of the sub-screens when the screen is first started, which would have confused the
users of this particular application more than it would have helped them.
Requirements of a new style
For this application, using the tabbed style was clearly not the way to go. Instead, I needed a way
to do the following:
• Select any one sub-screen directly, from more than 10 sub-screens.
• Display an obvious visible indicator of which sub-screen was active.
• Be able to select the next/previous sub-screen easily.
• Move directly back to the first sub-screen.
• Avoid displaying all of the sub-screens at the beginning.
• Display text or a bitmap as the prompt for the button.
The solution that I came up with resembles the appearance of the View dialog box in FoxPro for
Windows (see Figure 2). This style displays a set of buttons vertically down the left side of the
sub-screens, and the current sub-screen is indicated by the depressed button. ON KEY labels
were set up so that users could move to the next or previous sub-screen by pressing the PgDn
and PgUp keys. They could move to the first sub-screen by pressing the Home key (while this

isn't strictly a Windows-standard, it's what the customer requested). The main screen and each
sub-screen are stored as separate screen entries in the Project database (that is, not in a single
Screen Set), and a .PRG controls which screens are displayed at any one time.
You can now develop a sample application. All of the source code for this application is
included in download file _RUSSEL2.EXE. Since the purpose of this article is to demonstrate a
screen interface, rather than any database manipulations, this application will work only on
memory variables, which won't be saved when the application exits. Since the data is irrelevant
to the article, you won't perform any validation on the data that gets entered.
The sample application will be a prototype for a customer management system. The main
information (the information that you want to display all of the time) is the customer name and
ID. For this application, you'll have three sub-screens, each with a single piece of information.
The first sub-screen will have the Address, the second will have any Contacts that you've made
with the customer, and the third will be general notes on the customer. For simplicity sake, these
will all be character memory variables.
Define the main screen loop
All of the processing for this screen is controlled from within a single .PRG that calls multiple
.SPR files. The screen files all have the #NOREAD directive and, therefore, can't do anything
more than display the information on the screen. This means that the controlling .PRG contains
the controlling READ. Here's a sample of the controlling loop. In this case, the READ SHOW
and READ WHEN procedures aren't defined; the calls are just for illustrative purposes:

* Initialize the variable for the current screen
m.lnScreen = 1
do while m.lnScreen # 0
* Define the window, draw the header information,
* and draw the buttons for the sub-screens
do scr_main.spr
* Draw the objects for the specific sub-screen
* that you are working with
do case
* Display the Address information
case m.lnScreen = 1
do scr_sub1.spr
* Display the Contacts information
case m.lnScreen = 2
do scr_sub2.spr
* Display the Notes information
case m.lnScreen = 3
do scr_sub3.spr
* More screens would be defined as required
endcase
* Process the READ
READ CYCLE ;
SHOW ReadShow() ;
WHEN ReadWhen()
Setup the navigation through the screens
Now that the main loop is in place, the navigation controls have to be set up to help move
through the sub-screens. This involves creating a procedure (NewScreen) to load the newly
selected sub-screen and setting up the hot keys to navigate through the sub-screens. The
following code is included with the initialization of the program:
* Define total number of screens that you have available
m.lnScreens = 3
* Setup the hot keys to move through the screens
ON KEY LABEL HOME DO NewScreen with 1
ON KEY LABEL PGUP DO NewScreen with m.lnScreen-1
ON KEY LABEL PGDN DO NewScreen with m.lnScreen+1
[You might also consider setting up menu options such as First screen, Next screen, and

Previous screen with the corresponding shortcuts Home, PgUp, and PgDn. This would provide
menu alternatives for the users, teach them about the shortcut keys, avoid the extra code
otherwise needed to make sure the ON KEY LABEL assignments are undone after the user is
finished with the screens, and eliminates the potential for ON KEY LABEL recursion. -- Ed.]
The following code gets placed after the main loop. In this procedure, you'll handle the wrapping
of the sub-screens (pressing PgDn on the last sub-screen moves back to the first one). Switching
the sub-screens is actually handled by issuing a CLEAR READ in the NewScreen procedure.
This is because the main program is in a loop controlled by m.lnScreen. To terminate the loop,
m.lnScreen is set to 0. Any other value will cause the main screen and the correct sub-screen to
be displayed:
procedure NewScreen
*****
* Program : NewScreen
* Programmer : Paul Russell
* Purpose : Move to a new screen
*****
parameter m.lnNewScreen
* Ensure that the parameter is valid
if type("m.lnNewScreen") # "N"
m.lnNewScreen = m.lnScreen
endif
* Loop around the end of the list if necessary
do case
case m.lnNewScreen < 1
m.lnNewScreen = m.lnScreens
case m.lnNewScreen > m.lnScreens
m.lnNewScreen = 1
endcase
* Set the new screen number
m.lnScreen = m.lnNewScreen
* Load the New Screen
CLEAR READ
return
Define the main screen
The screen shown in Figure 3 is the basis for the sample application. The Customer Name and
Customer ID are text fields that you always want to display. The Quit button is provided, in this
case, to allow you to get out of the application (you are usually better off using a menu selection
for this, but that's outside the scope of this article). The large rectangle is the area that will be
filled in with the sub-screen information.

The first key to making everything work is the set of buttons on the left (Page1, Page 2, and Page
3). These are graphical radio buttons. The image in each button is, optimally, 15 pixels high and
a bit wider than it needs to be for the longest label. Radio buttons are used, rather than push
buttons, so that the "pushed in" quality will be retained (if push-buttons were used, they would
only be pushed in for as long as the mouse button was pushed in).
The radio buttons use the variable m.lnScreen, and they call NewScreen as an expression with no
parameters to validate the button. The code in NewScreen then guarantees that the variable will
be correct and that it will be selected automatically. When a different radio button is pushed in,
m.lnScreen will be changed to that value, and the corresponding screen will be displayed.
The second key is changing the information that gets displayed in the screen, so that the old
information is removed and the new information is displayed. This is where the large rectangle
to the lower right comes in. This rectangle is defined as opaque and white with a black hairline
border. It's the same size and position in all of the sub-screens. Objects specific to the sub-screen
are then drawn on top of the rectangle. When a new sub-screen is drawn, the white rectangle will
be drawn first (covering up the old information), and then the new information will be drawn on
top. For this reason, it's often easier to have a "dummy" screen that only has the rectangle
defined and no objects on it. I'll explain how to use this "dummy" screen next.
Define the sub-screens
Once the main screen information has been defined, it's simple to copy the main screen to the
dummy screen and then remove all of the information except for the rectangle. Then you can use
this dummy screen as a basis for the sub-screens.
Copy the dummy sub-screen to each of the sub-screens your application will actually use and fill
in the appropriate field information. Don't forget that the only information in the subscreens that
you fill in is within the white rectangle.
Drawbacks
There are drawbacks with everything, and this style is no exception. Fortunately, you can
overcome most of them with a bit of imagination.
One major drawback is that the radio buttons require that images be created for them. This is to
ensure that they are graphical buttons and look like regular push buttons and not like standard
textual radio buttons. You can create an image using the Paintbrush program that comes with
Windows (in the Accessories Group) or the Paint program that comes with Windows 95. One
difference between this style and the tabbed dialog style is that this style requires more planning
because these bitmaps can't be changed at runtime (while it is possible to use FoxPro to turn text
into a properly formatted bitmap, I haven't written the procedure for this yet). However, this does
turn into an advantage because you can incorporate the graphical and textual elements in a single
place, and you'll immediately see how they look.
Another major drawback is that you can't display any @ .. SAY objects on the screen and expect
them to be refreshed. This is because the READ is outside the screen program (.SPR), and there's

no automatic way for it to reference the SHOW routine in the .SPR. For more information on
this, and for potential workarounds, refer to the sidebar, "Refreshimg @ ..SAY Objects."
The line of bitmaps contained within the radio button definition can get prohibitively long. In the
first application that I used this style for, the list of the 14 bitmaps that GenScrn created,
complete with the DOS PATH to find them, exceeded the FoxPro command-line limitation of
2,048 characters. To get around this, I used the GENSCRNX directive *:PICTURE in the
comment snippet of the radio button. I was then able to set up the list of buttons in a character
string at the beginning of the program. This also turns into an advantage, as you'll discover later.
The bulk of this style has to be coded by hand. There is no GENSCRNX driver for it and, with
the release of Visual FoxPro, this driver probably will never be developed.
The rectangles on the separate sub-screens have to be defined in advance and are included in
each sub-screen for reference when placing the objects and to hide the previously drawn objects.
If the space required for the objects in a sub-screen exceeds the size of the rectangle, then the
rectangle has to be expanded to the same size in all of the sub-screens. This is easy to overlook
during development, but it's easy to check by building and running the application, then moving
through all of the sub-screens, one after another.
Possible extensions to this style
While developing an application, I wanted to change the order of the radio buttons and the
corresponding sub-screens frequently (due to chasing loose requirements from the users and their
managers). For this reason, I changed the initialization of the program to enumerate the
sub-screens and then build the list of buttons on the fly -- when I wanted to change the order of
the sub-screens, I would just change the value in the enumerated buttons, and the program would
re-build the list accordingly.
In this article, I've shown a basic sample of this style. In one of my applications, I've used this
style to contain 20 sub-screens of information, with 10 buttons being displayed at one time. This
was possible because I included two extra radio buttons arranged horizontally at the bottom of
the list (see Figure 4). When one of these buttons is selected, the list of sub-screen bitmaps is
changed (because of the GENSCRNX *:PICTURE directive I mentioned earlier) and a CLEAR
READ is issued. When the program goes through the loop again, it re-draws the radio buttons,
this time with the new bitmaps. The value of the sub-screen is also increased or decreased by 10.
Using this extension, the number of possible sub-screens can easily be tripled or quadrupled (and
if a pull-down is used instead, there can be an almost unlimited list of sub-screens).
The user of one application wanted a more distinct way to see which button was depressed. We
decided that a box could be drawn around the text for the depressed button. Since the
*:PICTURE directive was already being used, it was a trivial matter to let FoxPro handle this
change for us.
FoxPro has a feature (see "Liven Up your Applications with 3D Graphical/Text Push Buttons" in
this issue) that allows you to set up three different images for each graphical button. The first is
the button in the normal state, the second is the button in the depressed state, and the third is

when the button is disabled. The Screen Builder allows only for the first of these, so you have to
get away from the limitations of the Screen Builder (in this case, it's done by using GENSCRNX
and the *:PICTURE directive again).
The code to define the list of bitmaps for this applications sets up two bitmaps for each button. In
this case, est_gi_p.bmp is identical to est_gi.bmp, with the exception that it has a single-line
border around the outside of the button. As different buttons are pressed, the border moves
automatically (see Figure 5):
m.lcPicture = "est_gi.bmp,est_gi_p.bmp;"+ ;
"est_je.bmp,est_je_p.bmp"
My users have become accustomed to the buttons and like being able to go where they want and
see what they want so much that they found the menu system to be the long way to get things
done. After filling in a complete order, users had to print three reports, and they were looking for
a faster way than to select the three reports individually from the menu. A push button was added
below the list of radio buttons. This push button had the same dimensions and almost exactly the
same appearance as the radio buttons, so the users felt instantly comfortable with it. But the label
on the button was "Print All." This button replaced the selection of three menu items so that the
users could quickly print the three reports with the single order.
Conclusion
A wide range, both of tools and of programming and interface styles, are available in the
development community. I see this daily in the hundreds of e-mail messages that I get over the
Internet. Developers always want to include the best in their projects. It's good that developers
are looking for alternatives because, when you see one, you can make the decision to use it right
away, never use it, use it but adjust it a bit, or remember that you saw it and try it later.
I hope that showing you this alternative prompts you to expand your tool set and join in the
at-work and online discussions about other ideas, as well.
Paul Russell is a software specialist with Software Kinetics Ltd., is chairman of the Fox Users of Nova
Scotia, and is an active member of the FoxPro sections on the Internet. He has been programming for
more than 10 years, with more than seven of those years of experience with the Fox product line. Internet
prussell@fox.nstn.ca, or russell@atl.sofkin.ca, CompuServe 102440,2125.
Sidebar: Refreshing @ .. SAY objects
When a screen is generated, an extra procedure is created to handle the READ SHOW clause.
All of the @ .. SAY (or "Output") objects that have the [ ] Refresh box checked are included
twice -- once in the main definition of the screen, and again in the READ SHOW clause. Later,
when the SHOW GETS command is executed, the READ SHOW procedure gets called. Using

this mechanism, FoxPro takes care of re-drawing the @ .. SAY objects. All you have to do is
issue the SHOW GETS command when you want them refreshed.
There are two problems with this style. The first is that the READ SHOW procedure is in a
different file and has a random name (generated by GenScrn), and the second is that if the screen
is generated with the #NOREAD clause, then no READ is generated (as expected), but also no
other clause that is directly connected with the READ is generated. This effectively means that
no READ SHOW, READ WHEN, or other such clauses are generated. These two problems
mean that you can't issue a standard READ SHOW command and have the @ .. SAY objects
refresh normally.
Getting past the first problem is relatively easy. It involves two steps: telling the READ SHOW
procedure what its name should be, and then calling it explicitly. Since the most common use of
the READ SHOW clause is to refresh the @ .. SAY objects, the following code could be inserted
into the SHOW snippet of all of the screens, including the main screen, to explicitly name the
READ SHOW clause:
#NAME SHOWSAYS
Then, in the ReadShow procedure, you can call the correct procedure in all of the relevant
screens (you'll notice that this code is remarkably similar to the main loop):
do SHOWSAYS in scr_main.spr
* Refresh the @ .. SAY objects in all of the sub-screens
do case
case m.lnScreen = 1
do SHOWSAYS in scr_sub1.spr
case m.lnScreen = 2
do SHOWSAYS in scr_sub2.spr
case m.lnScreen = 3
do SHOWSAYS in scr_sub3.spr
* More screens would be defined as required
endcase
Getting past the second problem, not creating the READ SHOW procedure at all, is a bit more
difficult. In this case, you have to replace the #NOREAD directive with a call to a GENSCRNX
driver. This driver is used to post-process the generated screen and remove the READ command.
In the Setup Snippet of all of the screens, include the following line:

*:SPRDRV6 NO_READ
Here's the GENSCRNX driver, NO_READ.PRG (it must be located anywhere in the FoxPro
PATH):
* Driver to remove the READ commands
* This is better than using #NOREAD because it retains
* the supporting procedures, like the SHOW snippet.
* This is best called as *:SPRDRV6
replace sprdata.spr with ;
strtran(sprdata.spr,chr(13)+chr(10)+"READ ",;
chr(13)+chr(10)+"* READ ")
replace sprdata.spr with ;
strtran(sprdata.spr,chr(9)+"READ ",chr(9);
+"* READ ")
This driver looks for the READ command at the beginning of the line and replaces it with a
commented READ command. Two REPLACE commands are included: the first for a
single-platform screen and the second for a multiplatform screen.
Without including both changes (the #NAME directive and the NO_READ driver), it's
impossible to include @ .. SAY objects in the screens and have them be refreshed. Instead, you
have to have all refresh-able objects as @ .. GETs.
Sidebar: Non-tabbed pages
Moving this style to FoxPro for DOS is also fairly easy, but there are some limitations because
of the nature of the character environment. When moving this style to DOS or UNIX, the radio
buttons along the left side of the sub-screens are changed to regular push-buttons. No other
changes need to be made to the basic idea. The functionality that gets lost is the ability to have a
bitmap (and therefore a graphic) represent the button, and there's no automatic way to change the
prompt on the button for the new sub-screen (it's possible, just not automatic). You also lose the
ability to have multiple "pages" of buttons, because there isn't enough room in most lists of
buttons to have the buttons.
One technique you might consider in a character-based environment to compensate for the lack
of visual clues such as the "always pressed" status of a graphical radio button would be to add
code to the NewScreen procedure that enables all the page push buttons, then disables the one
for the new page.
Moving this style to Visual FoxPro is easy and will work more smoothly. The sub-screens can be
defined as a tabbed interface, but without the tabs. The radio buttons can appear along the left
edge of the tabbed form, and the Valid event on the radio buttons would behave the same, setting

the new page as current and then issuing a THISFORM.Refresh call.
New Year's Resolutions
Les Pinter
I'm making up my list of resolutions for the new year. I know it's early, but one of my New
Year's resolutions last year was not to get behind . . .
I will learn to live with Windows 95. I tried it for two weeks, then reformatted my hard drive and
went back to NT 3.5. But most if not all of my clients will use it, so I will do the same.
I will register all of my shareware. I use WinZip every day, and it's only $30 or so. And
McAfee's Antivirus has saved my bacon more than once. I'll even buy the terrific PIM I've been
"test-driving" since a friend gave it to me six months ago. I know you'll all ECCO my
sentiments.
I will read every single article in both FoxTalk and that journal that won't sell me advertising. A
single idea from a single article that I read a month ago is saving me a half an hour a day. So I'll
pencil reading time into my schedule.
I will check out the collection of applications being developed by the
Foxfire!/Flash/FoxExpress/Capcon brain trust. You can bet your boots that this collection of the
best minds in our business, working together, will produce something worth looking into.
I will get on the Internet. Even though I'm told it's a big waste of time, there's got to be
something to any technology that doubled its user base during the last year. So I'll learn what a
gopher is and surf the web.
I will make my deadlines to FoxTalk. Honest, Bob . . .
I will give my Madrid DevCon speech in Spanish, and my Moscow DevCon speech in Russian,
even if my partner Dmitry has to cover his ears and leave the room.
I will check my e-mail every day. Mainly because it's in my CompuServe Forum contract. GO
PINTER . . .
I will read every book on Visual FoxPro that comes out. So far, Whil Hentzen's is the best Visual
FoxPro book, and after mine comes out in December (McGraw/Hill), Whil's will still be the best.
But there's something to be learned from every title.
Most of all, I will appreciate the wonderful job that I have. I earn a good living, and get to do
what I love most. In a way, it's just like high school. All you have to do is do your homework
and show up.
Les Pinter publishes the Pinter FoxPro Letter in the United States and Russia. 916-582-0595.
CompuServe 76434,104.

Fox World News
Micromega Systems has announced a new version of their FoxFire! Report Writer. Version 3.0
supports FoxPro for DOS, FoxPro for the Macintosh, FoxPro for Windows, and Visual FoxPro
and is fully customizable without changing source code. Other features include outer-join
support, top N values, and a data-on-file window for validating values. In addition, the cross-tab
reports have separate cross-footings and easier sorts. You can create spreadsheets or Excel pivot
tables via DDE, graphs with MS-Graph or Excel, and World Wide Web browsable reports.
Micromega Systems Inc., 832 Baker St., San Francisco, CA 94115, 800-453-6655,
415-346-1461, fax 415-346-6804, CompuServe 73354,1745. Single user standalone edition $99,
developer's edition $295.
Strategic Edge is shipping Query Maker, the distributable RQBE and report writer, for Visual
FoxPro. In addition to a new look and feel, this version features a new form layout report option,
a detail/summary report option, a report-column field, and filter builder improvements. In
addition, four more output options have been added: Visual FoxPro .DBF tables, ASCII text file
with tab delimited fields, ASCII text files with blank delimited fields, and Excel version 5.0
spreadsheets. Strategic Edge, 415-563-3755, fax 415-563-1907, CompuServe 74660,1422.
Application Developers is offering introductory, intermediate, and advanced classes in Visual
FoxPro 3.0. Introduction to Programming in Visual FoxPro is a two-day course that includes a
tour of the software, database design, importing data, designing forms, designing queries, and
designing reports. The intermediate Programming in Visual FoxPro is a two-day course that
includes developing maintainable apps, database design, the data dictionary, GUI development
principles, object-oriented programming, advanced form design, designing menus, distributing
apps, and using SQL in Visual FoxPro. Advanced Programming in Visual FoxPro is a one-day
course that includes advanced multiuser programming, advanced database concepts, advanced
class design and implementation, understanding OLE, and extending the development
environment. The classes are held in major cities across the United States and Canada.
Application Developers Training Company, 7151 Metro Blvd, Ste. 175, Minneapolis, MN
55439, 800-578-2062, 612-943-1363, fax 612-942-8452. Introductory and intermediate courses
$795. Advanced course $395.
Extended Systems has announced its Advantage Database Server version 4.0, previously
known as Advantage Xbase Server. The new version adds new server functionality, such as
transaction processing, new data storage capabilities, new data security features, and Windows
support through two new interfaces. Extended Systems has teamed with SuccessWare and
integrated the SuccessWare Database Engine version 2.0 (SDE2) interface into Advantage
Database Server. This gives you a navigational Windows .DLL interface. You can create
scalable .DBF applications. Advantage 4.0 also provides support for SQL data access through its
Level 2 ODBC interface. Extended Systems, PO Box 6368, Bozeman, MT 59771,
800-235-7576, 208-322-7800, fax 208-377-1906.