6

The LA Fox Developer Newsletter
January 1996
Simple Strategy for Learning
Visual Foxpro
by Tom Meeks

Recently, there has been some lively discussion on the Fox forums about strategies for learning Visual FoxPro. To the point that these discussions began, learning strategies for VFP 3.0 had been almost completely dominated by Object Oriented Programming purists. Fortunately, as an outcome of the discussions, some alternative approaches are now being explored and implemented.

The danger with an OOP dominated approach in initially learning Visual Foxpro is that OOP tends to overshadow other equally important issues and features. To be sure, we must master Object Oriented Programming to fully utilize the power of VFP; but, we certainly don’t have to be OOP gurus to do some very nice work with Visual Foxpro. OOP has it’s place; but, I’m convinced that it’s far more important to explore other aspects of this incredible product first.

Access 2.0 and Visual Basic 3.0 are highly successful products and they are Object Based, not Object Oriented. While Visual FoxPro is a powerful Object Oriented platform, it can be used as an Object Based language also. In other words, Visual FoxPro can be just as easy to learn as Access! The trick is to use a strategy that begins with an interactive, Object Based mode and moves toward full Object Oriented Programming in due course.

One likely place to begin exploring VFP is experimenting with free tables and the table’s ‘Properties’ that are now available from the View Window. Understanding the behavior of these new properties is the very foundation of successful VFP development. Most of the properties, including Table and Row Buffering, can be explored interactively from the View Window simply by USEing the same table AGAIN with different ALIAS names and watching how various settings affect data updates, etc.

NOTE: Use TABLEREVERTO and TABLEUPDATEO from the Command Box.

Once you have explored free table properties, the next logical step is to experiment with the DBC (Database Container). All of the features of the DBC, including triggers, stored code and Table/Field Validation can be tested from the familiar BROWSE. Don’t be in a hurry to create a form until you fully understand the DBC’s
capabilities, including the new built-in Referential Integrity.

Next move to a standalone form with one or two fields. You don’t even have to bother with integrating a table with the form to have a great time exploring the interactivity of Visual FoxPro’s new objects. For instance, place one spinner (Spinnerl) and one text box (TEXTI) on a new form. Double-click on the spinner and type the following lines into the spinner’s INTERACTIVECHANGE method.

THISFORM.textl Value = THIS.Value
THISFORM.textl .Width = THIS.Value + 100

Save and run the form. As the spinner value is changed, both the size and value of the textbox will change. Continue to experiment with all the controls except the GRID before adding any tables to the form’s DATAENVIRONMENT. In particular, explore changing things like Combobox lists based on the bahavior of other controls. For instance, create a Combobox and a checkbox. Set Combol.RowSourceType to 1-Value and add the follwing line to the INTERACTIVECHANGE method of the Checkbox control.

THISFORM.Combol.RowSource = lIF; (THIS.Value = 1 ,“Boat, Plane,Car”,”Dog,Cat”)

Toggling the checkbox changes the values and number of items in the Combobox. A little experimentation will reveal just how powerful VFP is for those pesky adhoc operations that were a nightmare in FP2.x.

The next step is to learn how to deal with objects that are ‘Bound’ to table fields. This is where we start putting our knowledge of table properties and buffering into practice within a form. Concentrate on making your code in the methods for the form and it’s objects as generic as possible by using THIS, THISFORM, THIS.PARENT and other naming conventions. At this point, we can create a simple application and we haven’t created a single
CLASS!

That comes next!

Once you have created a smoothly working form, with buttons for adding, saving, etc. it’s time to begin thinking about turning these working features into various CLASSES or templates so that you will never have to write all that code again. By this time, I’m certain that you will have seen that OOP really isn’t all that difficult and you will be ready to create solid, bullet-proof Classes.

(Con’t, page 8)
Page 6

6