Introduction in Fox Pro

Any journey is best begun with a roadmap.

When Whil approached us to do this book, the most significant feature that he wanted us to include was 'wisdom.' We immediately wondered why he would use such a word in the context of recruiting us to do a book. However, after a moment's reflection (and much to our relief- we thought we were really going to be on the spot!), we realized that wisdom is not the same as intelligence, nor is it the same as knowledge. Wisdom is acquired only through experience. Usually that experience is painful, because valuable experience involves making decisions that later turn out to be mistakes. After making mistakes on a development project, we're faced with another decision-to either live with and work around the mistakes, or to back up and redo a great deal of work to correct the mistake.

We have made our fair share of mistakes over the three years we've worked with Visual FoxPro, and in the process have come to an understanding of what does and does not work well in solving certain problems that confront us when creating applications. The purpose of this book is to share with you some of the things we have learned.

One challenge of learning to be an effective Visual FoxPro developer is wading through the multiplicity of available choices when you're confronted with a particular problem that needs to be solved in the context of a particular application. Visual FoxPro's Xbase heritage means that almost every feature, command and function that has been added to any Xbase dialect from the early '80s to the present has found its way into the product. Add to that the features, commands and functions appropriate to an object-oriented language, and you have three Thanksgiving dinners worth of stuff.

It isn't easy to whittle down the commands, functions and features by eliminating those that the documentation claims are for 'backward compatibility' only. In many cases these items have, indeed, been replaced by better, more appropriate techniques. But the fact remains that some are unique in their functionality and in certain circumstances cannot be duplicated using any other feature. As an example, ON KEY LABEL and VARREAD() have certainly been well replaced by KeyPress and ActiveControl. However, TAGNO() and PCOUNT(), included in FoxPro 2.6 to provide dBase compatibility, have no other equivalent function or technique. Fortunately, in the case of PCOUNT(), Microsoft has acknowledged that this function provides functionality unique from that provided by PARAMETERS(), and has begun fully documenting this function.

Beyond the sheer number of commands and functions, the complexity of some of the objects that we have to work with can be very intimidating. The combo box has 143 different properties, events and methods. 143! Sheesh! In FoxBASE+, a table field had a data type (one of five-character, numeric, logical, date and memo), a size, and a position within the table. In VFP6.0, we have a choice of 11 different data types (the original five, plus general, currency, datetime, double, float and integer, plus two variants of these, the character binary and memo binary). We also have a choice of whether the field accepts null values, and nine different properties for each field if the table is included in a database-Caption, Comment, DefaultValue, DisplayClass, DisplayClassLibrary, Format, InputMask, RuleExpression and RuleText.

The developer has so many different features to choose from that it can become difficult to decide exactly which ones to use, which ones to pass by, and which ones to avoid at all costs. Further, there are almost always two ways of doing anything in Visual FoxPro, and frequently more than that. Given such a surfeit of choice, opportunities abound for doing things the hard way-or in a manner inappropriate to the situation-and causing a lot of frustration, to say nothing of creating an application that may be well nigh unto unmaintainable.

Hence this book. We've tried to put together a list of what we feel are the most important issues facing the Visual FoxPro developer, and to show you how we've chosen to deal with these issues.

Who this book is for

This book is intended for developers who are fairly familiar with Visual FoxPro. If you're looking for a good introduction to Visual FoxPro, we highly recommend Whil Hentzen's Programming Visual FoxPro 3.0, and his contribution to this series, The Fundamentals: Building Visual Studio Applications on a Visual FoxPro 6.0 Foundation. If the material in either or both of these books is familiar to you, then you're ready for this book.

To get the most out of this book, you should be able to put together a simple application; hopefully you've already created an application or two. These don't necessarily have to be production applications, but the simple kind of thing we all create when we're learning a new language-with a database, a menu, a couple of forms and a report.

This book is not for those who are brand new to Visual FoxPro. If your experience is entirely with FoxPro 2.x, dBase, Delphi, C++, Visual Basic, PowerBuilder or any other language, you need to get up to speed with one of Whil's books mentioned above, or an equivalent.

Neither is this book for those looking for information about how to implement an application framework. We both strongly believe in using a framework of some kind, but creating a robust framework suitable for use in a multi-programmer shop is beyond the scope of this book. We do discuss many of the issues that must be addressed in a framework, but the focus is on resolving these issues in a logical and design-influenced manner.

Likewise, if you're already into your second or third production Visual FoxPro application, and have a fairly well-developed framework in use, this book should serve as an interesting discussion of issues you've probably already resolved, and an opportunity to see how others have approached the same problems.

The right way to do things

It's important to understand that we're not necessarily trying to tell you the right way to do things; we just want to share the ways that have worked well for us. We will discuss the issues that have influenced our design decisions, so you can decide for yourself how best to create your applications. This is not to say that we don't have some strong opinions about how applications should be created, and we'll try to make sure that we offer some rationale for those opinions. Many people trying to come to grips with the Brave New World that Visual FoxPro represents are a bit intimidated by the 'purist' attitude displayed by more experienced Visual FoxPro developers, which can very easily sound condescending. We are both very pragmatic developers, but have learned the value of what some of the purists have advocated. If we sound 'purist' on some issues, please understand that we've painted ourselves into many a corner by ignoring some of that purist hogwash; we've lived to regret it and to 'tell the tale.' Then again, sometimes even we don't agree on the best approach to a particular issue!

Good design has always been important to producing quality, maintainable, scalable software. It assumes a much greater importance in an object-oriented programming language because the consequences of a design decision are much greater in an object-oriented system. This is a two-edged sword. The very thing that can make our lives easier, speed the assembly of the application and improve the maintainability and consistency of the code, can also make our lives a living hell, and make our applications a virtually unmaintainable mess.

This is not a book about object-oriented design. However, as we discuss the various areas of building an application we will by the very nature of the book, discuss how design decisions affect the implementations currently being discussed.

How this book is organized

This book is organized around several issues that we feel present the greatest difficulty to folks who are ready to begin their first production applications, or who have already embarked on or even completed a production application, and are finding it harder than they think it should be.

We have decided not to present a complete, functioning application as part of this book. We made this decision for several reasons. First, it frees us from having to create a single, monolithic application framework; we can instead explore different ways of getting the job done, without regard to how we did things in another part of the book. Second, you're probably aware of the old saying that the last 10 percent of an application takes 90 percent of the time and effort, and we wanted to devote more time and effort to discussion and demonstration of how to create applications, rather than putting the finishing touches on a demonstration app.

As a result, each chapter centers on a different piece of application construction, and explores that issue in the context of creating a portion of an application. All demonstration code is designed to work with modified versions of the 'Time and Data' data set that ships with Visual FoxPro 6.0.

Copies of the database as used in these examples, as well as our sample apps, are available from the Developer's Download Files from the Hentzenwerke Publishing website www.hentzenwerke.com.

A note about the Source Code

For a book, as with software, 'shipping is a feature'. Because the two authors of this book were most comfortable working with their own foundation classes and database features, we decided to include source code in two separate directories of the Developer's Download Files, rather than spending the time collaborating on a single database and set of foundation classes. Each chapter with source code will refer you to the directory where the example code is located.

The authors and our technical editor have tested all example code. This does not mean that it is completely bullet-proof. As you well know, only rigorous field testing can completely wring the bugs out of a piece of code. There hasn't been time or personnel for this level of testing, nor is it our intention to create robust code that you can cut and paste into your own applications. Many of the foundation class features are in use in production applications, but the example code is intended as just that - examples of ideas that have worked for us, and that would be refined, alpha- and beta- tested if they were going to be used in a production application.

As a result, do not be too dismayed if you find a bug in our code. We do it all the time. We would expect that any bugs that remain in the code at this point will not detract from the ideas that the text and the sample code are presenting.

Take note

Then there are times when we have something of special interest, or maybe a related topic, or maybe two different opinions to present. We've offset that in the text and slapped a 'Note' icon on it.