The Interactive Use of Visual FoxPro

Section I The Interactive Use of Visual FoxPro

Visual FoxPro has several significant differences from other development tools and programming languages: its native data engine, a gorgeous object-oriented language, and a flexible and easy-to-use mechanism to switch between native and remote data sources. One other difference that is often overlooked is a throwback to Visual FoxPro's heritage as a dBASE II clone. dBASE II was the first widely used personal computer database program, and it owed its popularity to a dual personality. The one side, of course, was an easy-to-use but very powerful programming language. The other was the ability to interactively manipulate data tables as easily as spreadsheet users massaged numbers or word processors handled text. In this section I'll show you how to use Visual FoxPro's interactive abilities. Once you're used to accessing and manipulating your data within your development environment, you'll never want to switch to another language.

Chapter 1Introduction to the Tool

It has often been said, "The choice of a programming language is not a matter of life or death. It's much more important than that." And I have often repeated that truism, because, naturally, it's true. However, Visual FoxPro, despite the reverential tone that will carry through most of this book, is still just an instrument to be used to build software applications. Given that point of view, I'm going to introduce you to VFP as a tool for software development. When you're done with this chapter, you'll understand what you can use VFP for, and how to make your way around inside of it.

When I started using a personal computer (right around the time they invented fire, according to my kids), the computing world was a simpler place. There were "mainframes"-room-sized machines that provided processing power for hundreds or thousands of terminals throughout a company. There were "mini-computers"-refrigerator-sized machines that provided computing services to a department or a small company. And then there were our "personal computers"- typewriter- or TV-sized boxes whose processor was used by only a single person at a time.

The applications that ran on these personal computers were fairly straightforward. You had your "word processing" and "spreadsheet" applications, both of which empowered a user to automate repetitive tasks that dealt with words or numbers.

The third major genre of applications was commonly referred to as "database programs," but there were actually two types. The first was an end-user application, much like the word processing and spreadsheet applications. The other was actually a combination of programming language and a local database storage mechanism. The market leader in the 1980s was a program written by Wayne Ratliff called dBASE.

By the end of the '80s, however, hardware and software lines were getting blurred. Mechanisms to connect multiple PCs in local area networks were becoming commonplace. At the same time, personal computers were getting more powerful and were able to run a wider variety of more demanding applications.

Software development techniques were evolving at the same time. In the '80s, the mode of application development was to write huge, monolithic applications. This approach evolved in the early '90s to the use of a generic framework that would then be customized and tailored for specific needs. The framework would contain elements common to each of these monolithic applications, and application-specific modules could be built on the framework for the custom solution desired.

As we approach the 21st century, the style of application development is evolving again. Developers saw how useful the reusability of a core foundation was, but the end result- executables of many megabytes in size-was inflexible. And flexibility has become more and more important as the pace of business changes has accelerated. The reusability was important, but the pieces needed to be smaller and applicable across a larger range of uses. The huge, monolithic application needed to be broken down into components.

The Fundamentals of Visual FoxPro 6.0

At the same time, the use of object-oriented languages and techniques has increased to the point of becoming generally accepted and popular in many circles, thus providing the tools and conceptual framework for building components.

Today's computing environment

Estimates of the size of the computer industry (including software and services) range anywhere from "a trillion dollars" to "half of the money in the universe." Despite this pervasiveness, it's difficult to explain to someone not in the industry what you do. This is fairly remarkable, when you think about it, because other large industries have their people easily pigeonholed. The automobile industry, for example, has mechanics, line workers, used-car salesmen, detailers, and so on. And any of those individuals can explain where they fit in the bigger picture in a manner that's easy to explain even after three or four beers.

You've probably had the same experience that I have: A well-meaning relative comes up to you at a family gathering, his face takes on a serious look, and he explains, "I was working on my computer last week, and all of sudden, the screen went blank. Can you tell me why that would happen?" No hint of what type of computer, what type of software, or what he was doing. But because "you're in computers," he expected you to know.

The computing environment has gotten so complex that even within the industry, it can be difficult to find common ground with an industry peer. While, obviously, it would be beyond the scope (or intent) of this book to delve into the myriad areas of computing, it's well worth examining in more detail the environment that Visual FoxPro lives in.

First of all, we're only going to be looking at the Windows 95/98 and Windows NT platforms running on IBM-compatible personal computers. Earlier versions of FoxPro ran on other operating systems, such as Windows 3.1, DOS, UNIX, and the Macintosh OS. Second, the delivery mechanisms have expanded beyond people's imaginations. In the early '80s, applications were single-user, period. When LANs became stable, multi-user applications became cutting edge and then commonplace, although there are a remarkable number of single-user systems still in use (and still being designed). As the LAN was supplemented by WANs, client-server architectures, and notebook-toting road warriors, the dispersion of data became more and more common, but the application still sat in one place.

Nowadays, however, the application is becoming distributed as well. The increased use of the Internet has changed the delivery mechanism of both the data and parts of the application. The user interface may well reside on the user's machine while the data processing engine stays centralized on a server in a different location. This evolution has provided one final push to building applications from components.

While existing applications remain monolithic, applications being designed today look different. The data may reside on a server, and its integrity and access is protected by a data engine. The business rules of the application-the actual work the software does-is contained in a separate layer, and that layer is not only logically separate, but may physically reside somewhere other than the database server. And the data may be presented to the user through a variety of mechanisms-a rich, highly interactive front end written in a development tool, or a simple, non-interactive view of the end result through a browser.

Visual FoxPro holds a unique place in this environment. Some tools excel at serving data to a large number of requests in a secure environment. Other tools can build robust, terrifically compelling user interfaces. But only VFP plays well in all arenas. VFP has a native data engine, which means you have to do very little work to build a LAN application with a local data store. But its extensive programming language and powerful object-oriented capabilities make it an excellent choice for building modules that do processing of any kind. Thus, VFP is capable of building complete applications that can run on a single machine, a LAN, a WAN, or a client-server infrastructure, but it's also an excellent tool for building components-particularly the middle-layer, business-rules components described earlier-that work in a distributed environment.

Installing and starting Visual FoxPro

Visual FoxPro is one component of Microsoft's Visual Studio 6.0 package, but it's also available separately, much like Excel is available both by itself but also as part of Office. Installing VFP in either case is similar; Visual Studio enables you to install all of VS or just selected components. By default, VFP is installed in the Program FilesMicrosoft Visual StudioVFP98 directory, and places Microsoft Visual Studio 6.0 and Visual FoxPro 6.0 menu options on the Start menu.

If you haven't already, you will want to install all of the MSDN help files-and if you have the disk space (about a gigabyte), install all of MSDN, not just the VFP-specific topics.

The main program is called VFP6.EXE in the VFP98 directory. (Visual Studio 6.0 was initially going to be named Visual Studio 98, and each of the tools was going to be named with a "98" moniker as well. Evidently the "98" didn't get completely expunged, as all of the directories under Visual Studio contain a "98" as part of the tools' names.)

To start VFP, click Start, Microsoft Visual Studio 6.0, and then click Microsoft Visual FoxPro 6.0; or click Start and then click Microsoft Visual FoxPro 6.0. You can also put icons on the desktop and taskbar to act as shortcuts. See details in Chapter 16, "Customizing the Development Environment." Upon selecting the VFP menu option or icon, VFP will load. The first time you run Visual FoxPro, a splash screen appears and offers you a variety of choices, such as exploring sample applications or creating a new application. Each time I reinstall and then load VFP, the first thing I do is check the "Don't display this Welcome screen again" check box. (Should you ever need to, you can display this screen by running the VFP6STRT program in Program FilesVisual StudioVFP98 or wherever you installed VFP.) Once past the splash screen, you'll be presented with the screen in Figure 1.1.

The Visual FoxPro interface

At first glance, the VFP interface might not seem very interesting: a menu, a toolbar, and an empty window named "Command." But before I go into more detail, let me mention a couple of things. I'm a big fan of customizing the environment to make my life easier, and the interface in Figure 1.1 differs from the default Visual FoxPro development environment in two ways.

First, I've customized the title bar to display the version of VFP and the current default directory. Knowing which version of VFP is running is pretty handy if you flip-flop from one version to another during the course of your day. And the current default directory is even handier-knowing whether a file is in the current directory or if you have to prepend a path before accessing it becomes second nature instead of a matter of trial and error. Second, I've added a couple of menu pads to the basic menu so I can quickly access features or functions that I use often. In effect, I'm running my own version of VFP-customized to suit the way I

The Fundamentals of Visual FoxPro 6.0

work, just as you write applications customized to suit the way your users work. I'll explain how I made these changes, as well as suggest some other customizations you might want to make, in Chapter 16, "Customizing the Development Environment." I just mentioned it now because I didn't want to have to rip out all of these changes from my development environment while writing this book just to provide pristine screen shots.

The Command window

Remember that empty window from a minute ago? That empty window is one of the coolest features of Visual FoxPro. The Command window is used to enter commands that tell VFP what to do. You don't have to use the Command window for everything-there are menu options that correspond to many common tasks. However, you'll find that you have much more discrete control over the commands, as well as more flexibility, because the menus are limited in scope and depth. For those of you with long memories, you might remember when Windows

3.0 started to replace DOS, but some people didn't want to switch-they thought they were more efficient with a command-line interface than having to "mouse around" all day. Visual FoxPro gives us the best of both worlds-precious few other tools do that.

The VFP interface is a complete development environment (or "IDE," for Integrated Development Environment). You can create, test, debug, compile, and ship entire applications completely within this IDE-you don't need additional tools. If you've used other components of Visual Studio such as Visual C++ or Visual InterDev, you'll notice that this IDE isn't the same as that IDE for those tools. This is because of the long heritage of FoxPro-it's been around a lot longer than any of the other components of VS, and the IDE has been tuned to provide a complete environment. However, given the move of VFP toward a component builder in Visual Studio, it wouldn't be surprising to see the VS and VFP interfaces converge.

Unlike any of the other tools in Visual Studio, the VFP IDE performs two functions. You can use Visual FoxPro to work with local databases in an interactive fashion, just as you use Excel and Word. You can open tables, add, edit and delete data, sort and query, and produce reports, as many personal computer users did on a daily basis with VFP's predecessors. Of course, it's probably overkill to use VFP just for that purpose, and, for most end users, it's probably too difficult to use strictly for interactive use. Other tools, such as Microsoft Access, are far better suited for end users to manage their personal databases.

The advantage that VFP's interactive access to data provides, however, is for the developer. Having had direct access to data during development makes life so much easier than if you had to execute a separate program in order to get at it. How many times have you wanted to run a sample query but couldn't, because you didn't know what data was in the table given you by your customer? In VFP, just open the table, look through it, and pick out what you want to use as sample data. Need to add a few records to test a new feature? Open the table and append them manually. Quick and simple. With this extra power, of course, comes responsibility. The data isn't protected from accidental changes in interactive mode-even from you! I'll discuss ways to safeguard your data from mistakes later.

Good enough? So what's the second function? Well, not only are you able to issue commands that access data from the Command window, but you are able to execute virtually any command and return the value of any expression from within the Command window. (The exceptions are primarily commands that are part of a logic structure, like IF or DO CASE.) This means you can quickly test commands and functions interactively, instead of having to (1) enter them in your program, compile, run, and see if your attempt was correct; or (2) create a dummy program for testing, and also go through a compile and run sequence just to validate the command or function. With the Command window, simply type the command, press Enter, and VFP will either execute it or respond with an error message that explains what went wrong.

Now let's move on to the rest of the interface. I'm going to assume you're fairly comfortable with the Windows interface. However, I've found that many developers don't know all of the names for the controls and functions they use every day, so I'm going to review them quickly.

Windows, menus, and toolbars

A Windows 95/98 or Windows NT window has a bar at the top of the window that's a different color, contains an icon and a text string on the left, and controls at both ends. The bar is the title bar. Clicking the icon opens a menu called the Control menu. The menu options in the Control menu allow you to manipulate the window. The controls at the right of the title bar allow you to (from left to right) minimize, maximize, and close the window, effectively duplicating the Control menu options.

The string of words across the top of the screen under the title bar is called a menu. Each word is called a menu pad; clicking a menu pad or pressing the Alt key and the underlined letter in the menu pad displays a drop-down menu. Each line in a drop-down menu is called a menu bar or menu option, and can be executed by clicking it, moving the highlight to the desired menu option and pressing Enter, or pressing the underlined letter in the menu option.

The Fundamentals of Visual FoxPro 6.0

If a menu pad has an exclamation mark in front of the word, selecting that menu pad won't cause a drop-down menu to display; instead, it'll launch a function directly. If a menu option has a series of three dots (an ellipsis) following the text string, selecting that menu option will bring forward a modal screen prompting the user for additional information.

Just as is the case throughout the Windows interface, pressing the right button on the mouse ("right-clicking") will open a drop-down menu at the location of the mouse pointer in many areas of Visual FoxPro. What to call this menu is a subject of heated debate at industry conferences, and will likely cause the next World War. I've heard it referred to as the "shortcut menu," the "right-click menu," and the "context menu." I'll use the last term because it describes most clearly what the menu does: provides menu options in context to the current mouse position. You can use a black marker and write in your own preference throughout this book if you like.

The string of buttons under the menu is a toolbar. Visual FoxPro has 12 different toolbars, each of which has buttons that relate to a specific area of functionality. Moving the mouse over a button in a toolbar displays a small rectangular box with a description of what the button does; this box is called a Tool Tip.

You can force a toolbar to display in several ways. First, selecting the View, Toolbars menu option will open a dialog listing all available toolbars. Check the toolbar(s) of interest and click OK, and the selected toolbars will be displayed. Right-clicking in an empty region of any open toolbar will display a toolbar context menu, with the list of all available toolbars. The toolbars already displayed will be listed with checkmarks next to them. Finally, certain toolbars are by default automatically displayed when specific functions are executed. For example, when a report is previewed, the Print Preview toolbar automatically displays.

You can customize toolbars, adding and removing buttons as well as creating your own toolbars. Details are in Chapter 16, "Customizing the Development Environment."

Controls

Windows uses a set of objects so the user can interact with a program. Commonly used controls (but by no means all of them) are shown in Figure 1.2.

Navigation between controls has a number of tricks many people aren't familiar with. The currently selected control is said to "have focus" and can be identified in one of several ways, depending on which control it is. Controls that take data input will show a cursor bar in the control if it's empty, or a highlighted block of information if the control isn't empty. Controls that don't take data input will show a dashed line near the border of the control (as the control that says "Command1" in Figure 1.2.) You move from one control to the next by pressing the Tab key. This is a matter of some consternation to users of character-based programs (either on the PC or on "big iron" machines) because they expect the Enter key to move the cursor. (Note that you can often change the default behavior of a control to display the focus differently by setting a property for that control.)

Starting with the top of the left column, the following controls are displayed:

Label: Typically read-only, a label is used to display static information to the user.

Text Box: Allows the user to enter and edit a short string of information with a maximum number of characters. This information can be a string of text, a number, or a date.

Edit Box: Allows the user to enter one or more lines of information, such as a
paragraph of text.

Command Button: Clicking it or pressing Enter when the button has focus allows the user to execute an action.

Option Group: An option group is made up of one or more option buttons. This control used to be called a set of "radio buttons," fashioned after a car radio that allowed only one button to be pushed in at a time. When the Option Group control has focus, you can move the focus within it to a specific button by using the cursor arrows. Pressing the spacebar when a button has focus selects that button (fills in the dot and removes the dot from the previously selected button). Pressing Enter will select the button that has focus and then move the focus to the next control, as if you had pressed Tab.

This is actually a bit confusing. Suppose you had a two-button option group, and the first option button had focus and was selected (the dot was filled in). Pressing Enter will just move the focus to the next option button (not the next control). Because the current button already was selected, pressing Enter didn't change its status. Now the

The Fundamentals of Visual FoxPro 6.0

focus is on the second button, but the first button is still selected. Pressing Enter now will cause the second button to be selected (the dot will get filled in), and the focus will move from the second button to the next control (the control that says Check1). I only make a big deal out of this because, someday, you will run into a user who claims your application has a bug in it because one of the option groups isn't working "properly." It is incumbent on you to understand how they're supposed to work.

Check Box: Allows a user to select ("check") or deselect ("uncheck") it as a way of turning a flag on or off, or otherwise communicate binary information. Pressing the spacebar will change the state of the control (from checked to unchecked or vice versa) but keep the focus on the check box, while pressing the Enter key will change the state of the control and move the focus to the next control.

Combo Box: The combo box actually has two flavors. Both of them open up (or, more precisely, "drop down") when activated to display a list of choices. One flavor-the Dropdown List-allows the user to select from the predefined list of choices. The other flavor-the Dropdown Combo-also presents an edit area where the user can enter her own data in lieu of selecting a choice in the list. Once the combo box has received focus, you can drop the list down by clicking the arrow or by pressing the spacebar. (This second mechanism is little-known, but very handy to mention when a user complains that to make a choice from the combo box she has to take her hands off the keyboard.) You can navigate to a specific choice by using the mouse or by typing the first few characters of the desired choice. (If the list of choices is sorted in alphabetical order, this works much better, but it's not an absolute necessity.) Pressing Enter when a choice in the list is highlighted selects that choice. The combo box will close and the selected choice will be displayed in the closed combo box. If you entered information into a drop-down combo, the information you entered will be displayed in the closed combo box.

List Box: Allows the user to select from a list of choices, and differs from the drop-down combo in that more than one choice is visible at a time, and that more than one choice can be selected. Once the control has focus, the user can type the first few characters of the desired choice to highlight it, just as with the combo box. If the appropriate properties are set for the control, the user can select more than one item in the list using the mouse or, if he's a glutton for punishment, a combination of the cursor and spacebar keys, or rearrange the order of the items in the list box.

Spinner: Allows the user to enter a numeric value or visually adjust a numeric value up or down using the arrows on the control.

Grid: Similar to a spreadsheet, the grid allows the display (and edit) of a tabular arrangement of data. The grid is powerful because it provides a window into what could possibly be a larger table of data than would ordinarily fit on a form. The grid is almost an entity unto itself, with customizable columns, rows, and headers.

Page Frame: Sometimes referred to as a "tabbed dialog," the page frame allows the user to easily flip between multiple pages of data on the same form without having to call up additional forms.

Conclusion

The Visual FoxPro interface conforms to many standards of the Windows Interface Guidelines, and doesn't require a great deal of training if you're comfortable with Windows. However, the Command window is a unique feature in VFP-allowing interactive access to data as well as the execution of nearly every command and function in the language.

The Fundamentals of Visual FoxPro 6.0