Logo

Hacker’s Guide to Visual FoxPro
An irreverent look at how Visual FoxPro really works. Tells you the inside scoop on every command, function, property, event and method of Visual FoxPro.

These Are Not Your Father’s Power Tools

Civilization advances by extending the number of important operations which we can perform without thinking about them.
—Alfred North Whitehead, An Introduction to Mathematics, 1911

When you walk into a hardware store, there’s generally no question about what’s a power tool and what’s not. If it has a cord or uses batteries or gas, it’s a power tool. If you make it go by the sweat of your brow, it’s not.

In Visual FoxPro, the lines aren’t quite as simple. There are a number of items that could be called “power tools” or not. We choose to take a fairly broad view and include in our list anything that at least partially automates a task you’d otherwise have to do by hand.

We’re not going to give you step-by-step (or even general) instructions on using each of the power tools. We assume you’ve read the documentation or an introductory book. Instead, we concentrate here on the stuff you might have missed—shortcuts, neat tricks, and new ways of working.

As with everything else in FoxPro, there are various ways the Power Tools can be categorized. It turns out that, for the most part, the design team has done a pretty good job of pigeonholing the tools just by assigning them names, so we’ll use that breakdown.

Designers

Generally, Designers are tools that let you point and click to create something for which you’d otherwise have to write code. They let you work visually instead of worrying about syntax. They also let you see results as you go, although you might be seeing intermediate results (as in the Form Designer, where you can tell what the form looks like, but not how it works).

By our count, Visual FoxPro has 11 designers: Form, Class, Report, Label, Menu, Database, Table, View, Query, Connection and Data Environment. The Form and Class designers are quite similar, as are the Report and Label designers, and the View and Query designers.

There’s one more tool that’s not named “designer,” but we think belongs in this category. That’s the Expression Builder, which lets you design an expression. It’s certainly not a builder, and in some ways it’s just barely a power tool. (It’s kind of like a cordless screwdriver. It has power, but not much.) But, if we call it a power tool at all, it’s more of a designer than anything else.

Wizards

Not quite as magical or entertaining as Harry Potter, wizards are useful helpers to automate some of the more mundane tasks. They serve the same purpose as the Experts and Assistants that those other big software companies provide.

Wizards walk you through a task, taking care of the details so you don’t have to remember all the steps. They’re a one-shot deal—once you’ve run a particular wizard, you can’t rerun it on the results.

Different versions of VFP have different numbers of wizards. They cover a wide range of tasks, from laying out a form to documenting your code to preparing an app for distribution to scaling data up to SQL Server or Oracle. Rather than listing all of them here, we’ll point out that you can find out which ones you’ve got by examining the table Wizard.DBF in the WIZARDS subdirectory of the main Visual FoxPro directory.

The wizard system in Visual FoxPro is extensible in two ways. You can add your own wizards. You can also add formatting styles to be used in those wizards where it’s relevant (the various form and report wizards). Both of these topics are covered in “Builders and Wizards (and Bears, Oh My!)”.

We think the wizards are an area neglected by too many developers. Those of us who have grown up (and grown old) using the product dismiss them as “training wheels for newbies.” But, in fact, the wizards present simple, automated ways to perform some complex tasks. The Application Wizard and Application Builder, coupled with foundation classes, provide some real power. Project hooks also offer opportunities for wizard and builder creators, since it’s now easy to hook right into project management.

A couple of other notes about wizards. The Documentation Wizard is the replacement for the old FoxDoc application documenter. The Setup Wizard was eliminated in VFP 7, in favor of a special edition of InstallShield.

In all versions of VFP, the source code for the wizards and builders is provided with the product, so you can make changes if you don’t like the way they work. All the code is in a ZIP file in HOME() + "Tools\Xsource\".

Builders

Builders are like wizards, only much better. We can’t figure why wizards got the flashy name while “Builders” is so prosaic.

The simplest definition of a builder is a “re-entrant wizard.” They’re similar to wizards, in that they guide you through a complex task, letting you focus on the desired result rather than how to get there. Unlike wizards, though, you can go back again. You can apply the same builder to the same object over and over, until you get it just right.

Like wizards, builders are extensible; you can add your own. “Builders and Wizards (and Bears, Oh My!)” explains how.

As with wizards, the exact set of builders supplied varies from one version to the next. However, in all versions, all but one of the supplied builders relate to creating forms and their controls. The exception is the Referential Integrity Builder, which helps you set up appropriate triggers in your databases.

As with wizards, you can find the list of installed builders by examining a table—in this case, Builder.DBF. It’s also found in the WIZARDS subdirectory.

On the whole, we find we’re using builders a lot less than we anticipated when we first saw them introduced into VFP. We suspect that’s generally true, and that most people who use builders regularly are using homegrown builders, not the ones that come with the product.

It’s actually quite easy to write simple builders that use SYS(1270) or AMouseObj() to get a reference to an object and then do something to it behind the scenes. The hard part is putting on an attractive interface and making them work in general, rather than specific, cases.

Managers

Actually, that should read “manager”—there’s only one of these, the Project Manager. But it’s a humdinger. The Project Manager is where you’ll live when you’re working on an application. It organizes the components of your application and gives you quick access to the other power tools. And, of course, it lets you build an APP or EXE file.

System Dialogs

There are a whole bunch of FoxPro dialogs you can incorporate into your applications. We think of these as power tools because they save you from having to write your own dialogs. We mentioned the Expression Builder above—it’s accessible via the oddball GETEXPR command. The rest of these are, more sensibly, function calls. Here’s the list. Before you spend too much time trying to write your own dialogs, you might want to look through this list and consider using one of these. See the Reference section for details on using each.

Doing It the Windows Way

Back in FoxPro 2.x and even in VFP 3, using the system dialogs through the GetWhatever functions listed above seemed incredibly forward-thinking. But the proliferation of ActiveX over the last few years means that, for a lot of those tasks and a whole bunch more that aren’t listed above, there are better ways. For example, the Common Dialogs control gives you access to the native Open File, Save File and Printer dialogs, with a lot more control than is offered by GETFILE(), PUTFILE() and SYS(1037).

ActiveX controls are available for all kinds of things. You can replace the status bar, put a calendar onto a form, use treeviews and listviews (the main interface elements of Windows Explorer), or even put a Web browser into your application. A lot of ActiveX controls come with Visual FoxPro, more get installed by other things you might have on your system, and thousands are available for sale, usually in packages of related items.

The fact that ActiveX controls get installed on your development machine by just about every application you install these days does raise one problem. Most controls have pretty strict rules about licensing and redistribution. When you’re designing a form, it’s hard to know whether you have a particular control because it came with VFP and, therefore, you can distribute it with your apps, or it’s there because the last applet you downloaded brought it along, and you have rights to use it only on your machine. Be sure to check this stuff out before you base your whole interface metaphor on some cool control you found lurking. (You can look at the help file that comes with a control by dropping the control on a form and right-clicking, and then choosing Help. At least some of them give you a clue about what can be distributed and what can’t.) Also, check the root Visual FoxPro directory for a file called Redist.TXT that indicates, in accordance with your license agreement, which files can be redistributed. We found the VFP license as Eula.TXT in the Visual FoxPro 7.0 Professional – English subdirectory of the VFP root.

OOP Tools

One of the most powerful of the power tools is the Class Browser, which lets you explore and manage the contents of class libraries. VFP 6 brought us the Component Gallery, which organizes not just class libraries, but all kinds of files. The big secret is that the Class Browser and the Component Gallery are really the same tool (which is why there’s a button in each that switches to the other). Properties control which face it puts on when you call it.

In its Class Browser guise, this tool lets you look at the structure of classes as well as perform maintenance on class libraries. The Component Gallery provides tools for organizing all kinds of files into logical groups. For more on these tools, see “Hacking the Class Browser and Component Gallery”.

The Object Browser is a long-awaited tool that makes its debut in VFP 7. The Object Browser peers into a COM object’s type library, and displays the properties, events, methods, interfaces, constants and other information needed to work with COM objects, whether you created them in VFP or they are a shrink-wrapped application. This is a real boon to those of us who have been automating Microsoft Office—you don’t have to rely on the Object Browser in the Office application (and the VFP version is a nicer implementation).

It’s worth noting, by the way, that the Browser/Gallery and the Object Browser are written in VFP. (In VFP 6 and later, source code is provided.)

Odds and Ends

The remaining power tools can’t be easily categorized. In fact, we’re not exactly sure what they are. But they add power to our development efforts, so here they are:

The updated Debugger probably ranks as a power tool, though the old one available in VFP 3 certainly doesn’t. For sure, the Coverage Analyzer is a power tool. Both the Debugger and the Coverage Analyzer are discussed in “Productive Debugging.”

The tools we’re not sure have power are GENDBC (which generates code to re-create a DBC), the Converter (to bring FoxPro 2.x projects and screens into VFP), and the Data Session window (the window formerly known as “View”).

Some of the power tools are helpful to use while working in the code editor. The Document View window displays all the procedures, functions, #DEFINEs and preprocessor directives in the code window. Making its debut in VFP 7, Document View replaces the Procedures/Function feature. The Document View is a dockable window, and offers more display options than its predecessor. However, unlike its predecessor, it’s available only from the Tools menu, and is no longer on the right-click menu—an oversight we’re none too happy about.

Also added in VFP 7, IntelliSense is another feature that makes life easier while coding. IntelliSense is that wonderful feature that we’ve been drooling over in other Visual Studio products: It automatically completes code, offers syntax help, displays object members, slices, dices, chops and makes julienne fries. It’s such a robust tool, we’ve given it its own chapter, “IntelliSense and Sensibility.”

Another couple of tools useful while coding are bookmarks and shortcuts. Still more power tools added in VFP 7, these tools let you mark code to come back to later. You can cycle through them using a variety of methods, including keyboard combinations and right-click menus. Bookmarks are temporary and go away when you close the editing window. Shortcuts are persistent, and also add a record into the Task LIST DATABASE (FoxTask.DBF by default, but you can change that with the _FoxTask variable). The Task List application (TaskList.APP, or you can point to your own app with the _TaskList variable) lets you post a due date, track whether you’ve read or completed the item, and opens the appropriate editing window with the cursor set to that line. For more information on the Task List feature, see “Using the Task List Manager” in the Visual FoxPro Help.

The Tools subdirectory of VFP contains a number of other goodies, including Ted’s favorite, Filer, which gives you a cousin of Explorer’s Find dialog inside VFP. There’s also HexEdit that provides a hex editor (surprise), letting you twiddle bits and bytes by hand. Be careful with that one. The Tools directory also contains the Transformer, which lets you move older applications to VFP.

VFP 7 adds a few more tools. The Accessibility Browser is a tool to help you develop applications that are more accessible to people with disabilities. The Automated Test Harness is a tool to create and play back scripts so you can test your application. Both of these use Microsoft’s Active Accessibility technology (MSAA) to perform their functions. Find the Accessibility Browser, AccBrow.APP, in the Tools\MSAA directory, and the Automated Test Harness, AATest.APP, in Tools\Test; both directories are under the VFP installation directory.

In addition, definitely not power tools, but more like a filled toolbox, VFP 6 and later include a ton of classes for all kinds of tasks (the FoxPro Foundation Classes, in the FFC subdirectory of the VFP home directory) and an extensible application framework. Use the Component Gallery to check out the parts that Microsoft has supplied. One of the most overlooked tools in the toolbox is the Solutions samples (found in the Samples\Solutions subdirectory of the VFP home directory). This application is really a series of programs that demonstrate many of the features and intricacies of Visual FoxPro. There’s a ton of code there to examine; it covers most controls, forms, Foundation Classes, reports, toolbars, the Windows API, and much more.

A Tip O’ the Hat

Here are our hints for working more productively. We start out with those that apply pretty generally, then hone in on tool-specific tips.

Right-Click

Just about everywhere in VFP, in just about every mode, right-click brings up a menu of context-specific choices. Beginning in VFP 5, that context menu even lets you do things like highlight a block of code and run it on the fly. Wherever you go, try a right-click and see what happens.

Do be careful—on many of the right-click menus, the first choice is “Cut” and it’s pretty easy to choose it by accident. Worse yet, Undo doesn’t always undo the cut. If you’ve created an ON KEY LABEL RightMouse in some of your routines, you’ll probably want to ditch it about now, especially if it ends with KEYBOARD "{ENTER}".

If you’re having problems with right-click menus always coming up as “Move Here/Copy Here/Cancel,” instead of something context-appropriate, the problem is that FoxPro is detecting your click as a MouseDown-Drag-MouseUp. Try rearranging your mouse setup, tweaking on the driver, or being really, really careful not to move the mouse as you press the button. There really are more options on the menu!

Drag and Drop

Again, drag and drop is widely supported in VFP and, beginning with VFP 6, even between VFP and other applications. You can drag a class from the Project Manager to the Form Designer to put an instance of that class on the form. You can even drag a table from Explorer into the Command Window, and it gets opened and BROWSEd. As with right-clicks, try dragging and dropping all over the place and see what you get.

Layout Toolbar

The Form, Class, Report and Label designers all work with the Layout toolbar. This handy contraption lets you line things up neatly and match object sizes. It sounds so easy, but was so hard to do in 2.x.

Always On Top

The Property Sheet, the Class Browser/Component Gallery, and torn-off tabs in the Project Manager can be made “always on top.” In VFP 3 and with torn-off tabs in all versions, push in the pushpin and you can’t put anything on top of that window. In later versions, right-click and select “Always on Top.” If you’re still working in 640x480 mode and probably even in 800x600, you’ll never want to do this. As we mention in “Hardware Recommendations,” 640x480 is probably an unrealistic video mode for working in Visual FoxPro, and this nice feature illustrates the problem well.

Sittin’ on the Dock of the Tray

Dockable windows take on new features in VFP 7. In addition to the pushpin “Always on Top”, now you can dock many of the windows just about anywhere you want to dock them. The Command Window, Property Sheet, Data Session, and Document View windows are all dockable. So are the various Debugger windows. There are three kinds of docking modes: normal, linked and tabbed.

Normal docking docks the window to any boundary of the VFP window. Drag the title bar of the window to any of the boundaries of the VFP window, and it docks there.

Linked docking links two windows together so they are both viewable, but share the same window. You might dock the Command Window to the Project Manager and display them side-by-side. Drag the title bar of one window to a boundary of the other window to stack them or display them side-by-side, depending on which boundary you select.

Tabbed docking maximizes your space on the screen by docking windows together but making only one visible at a time through the use of tabs. Since you probably don’t use the Project Manager at the same time as the Property Sheet, you can dock these two together and tab between them. Drag the title bar of one window to the title bar of the other to get a tabbed dialog with the tabs at the bottom of the window.

If you happen to find this behavior annoying (because you keep docking windows when you simply want to move them out of the way), you can turn this behavior off for each window by right-clicking the title bar and unchecking the Dockable option.

Note that in VFP 7, the Project Manager uses the VFP 6 version of docking, and still uses the pushpin to keep it always on top.

That’s One Option

The Tools, Options dialog includes an amazing array of choices for configuring both your working environment and the results. Spend some time experimenting there.

Be aware that the changes you make in this dialog are in effect only for the current session (except for Field Mapping and the IDE page, which are persistent). To make the others stick, click on Set As Default in the dialog. But watch out! Even though you can see only one page at a time, Set As Default stores the current settings for all the pages. (This stuff is stored in the Registry.) We haven’t found a way to store just a few settings, short of editing the Registry, which is not one of our favorite tasks. Also, check out the SYS(3056) function for rereading those settings.

Query/View Field Lists

You almost never need to visit the Fields page in the Query and View designers. Instead, use the top pane, which shows the tables in the query or view. You can double-click on fields there to choose them. Beware—the result depends on which page is on top. With the Join, Filter, Update Criteria or Miscellaneous pages on top, fields are added to the Fields list. With Order By topmost, the field is added to both the list of selected fields and the ordering list. When Group By is on top, the field is added only to the grouping criteria. (The set of pages is different in VFP 3, but the results are the same.)

You can also add fields to the various lists by dragging and dropping. You can even add multiple fields by highlighting them, and then dragging them into the destination list.

Double-clicking in the Selected Fields list of the Fields page removes the field from the Selected Fields list.

Class Browser Tricks

The Class Browser isn’t just for classes. You can open forms there, too. Just choose Form or All files from the LIST FILES of type dropdown in the Open dialog. If you choose Project or Application and then pick one of those, the class libraries and forms for that project are opened. You can also browse objects of other types, such as ActiveX controls.

It might not be obvious that you can use the keyboard to navigate through the Class Browser (and its symbiotic twin, the Component Gallery), but in fact, a combination of tabs and arrow keys does let you get pretty much everywhere.

You can test VFP classes while you’re looking at them. Highlight the desired class in the hierarchy, and then drag the icon that appears just above the hierarchy onto the screen. An instance of the class is created as a member of the screen. You can access it as _SCREEN.<classname>1. For example, if you drop the icon for a class called Yowza onto the screen, you can address it as _SCREEN.Yowza1.

The Class Browser gets close to providing Visual FoxPro with “two-way tools.” Click the View Class Code button and a window opens, showing an equivalent class definition in code. Although the code generated isn’t always executable as-is (it takes some shortcuts), it’s great for debugging and documentation, not to mention its value as an aid to help you understand how things get put together.

The Browser is itself an object with properties, events and methods. You can change all kinds of things about its behavior by modifying its properties or invoking its methods. Check out the various Class Browser topics in Help to see what properties are available.

Like so much about Visual FoxPro, the Class Browser is extensible. The button that looks like it’s got blocks on it gives you access to “add-ins”—programs that you register with the Browser and can then activate from inside it. Use the Browser’s AddIn method to register an add-in—check Help for the details.

Take a really good look at the Browser itself. It’s a tremendous example of what you can do with Visual FoxPro. (Try resizing it—notice how everything gets neatly rearranged. Also, in VFP 6 and later, note the splitter that lets you size each panel as you like.)

Report/Label Designer changes

The Visual FoxPro Report and Label designers look an awful lot like their FoxPro 2.x counterparts, but there are some neat features hidden inside.

First, although the RD and LD haven’t been OOP-ified, they do have a data environment. We’re not real clear on how a non-object can contain an object, but when data environments initially were introduced, we didn’t complain because it meant we didn’t have to write driver programs for reports. Instead of using a program to set up the data for a report, you could do your setup in the data environment. Like forms, reports can operate in a private data session. However, after having time to work with this feature for a while, we find that we still write a driver program/form to build a cursor from which the report is run. This is mostly to create de-normalized tables to exploit the features of the Report Writer and overcome some of its limitations.

Again, although report objects don’t have PEMs like their form counterparts, reports and labels themselves have acquired a set of events. Each band of the report now has the ability to execute a function “On Entry” and “On Exit.” Think of these as GotFocus and LostFocus for report bands—they’ll let you display thermometers (without resorting to tricks like FOR UpdateTherm() in the REPORT FORM command that actually runs the thing) or update data as the report executes. Double-click on the band bar (the gray bar with the name of the band on it) to bring up the dialog that lets you specify these.

Perhaps the most welcome change to the Report Designer in VFP is the ASCII keyword to the TO FILE option of REPORT FORM. Finally, you can send reports to a text file without worrying about printer-driver garbage!

Project Manager Mania

You’ll spend a lot of time in the Project Manager. It’s incredibly versatile.

You can choose whether double-clicking an item opens the item for editing or executes it. The Tools, Options dialog’s Projects page has option buttons for the two choices. It also lets you decide whether you want to be prompted to use wizards every time you create something new. That page also lets you configure your interaction with a source code provider. (See “A Source is a Source, Of Course, Of Course” for more on source code control.)

The Project Manager can be collapsed into something resembling a toolbar. In that state, you can open a single tab or tear off the tabs to put them where you want them. In either case, the tab can be resized. The PM remembers each tab’s size. It can also be docked to any of the edges of the FoxPro window, and VFP 7 adds the ability to dock it to another dockable window, like the Command Window—either side-by-side with the Command Window or with each one as a tab that takes up the full size of the window. See “Sitting on the Dock of the Tray” for more information on docking.

You can provide a description for any item in the project using the Edit Description option on the Project menu (and the PM’s context menu). The description you enter appears in the bottom panel of the PM when the item is highlighted. No more frantically trying to remember what “Arpmt02.PRG” does. For classes, the description shown in the Project Manager is the same one you can enter in the Class Designer’s Class Info dialog. You can enter it either place and see it in both. (Consider using a project hook to force you to add a description at the same time you add an item to the project.)

The Version button in the PM’s Build dialog gives you access to the same version information used by commercial applications. You can set up your app with version number, copyright, and so forth that’ll show up when the user chooses Properties in Explorer. You can also grab this version information to use in your application’s About dialog using AGetFileVersion() in VFP 6 and later or the FoxTools’ GetFileVersion() function in VFP 5.

Expression Builder Tricks

The Expression Builder has its own set of preferences, hidden away under the Options button on the misnamed “Builder.” These preferences are saved in the current resource file, and allow the Builder’s popups to be restricted to just those functions you’d like the user to be able to manipulate. You can also specify whether system memory variables are visible, and how aliases get added to expressions. Because anyone can access these options, it’s not exactly foolproof security, but it can be an aid to guide the user. See the Reference section’s entry on GETEXPR for more on this command.

You can also replace the Expression Builder with your own dialog by setting the _GETEXPR system variable. The program you specify runs any time the built-in Expression Builder would be called and when GETEXPR is executed.

Toolbar Techniques

Right-click in any toolbar and you get a list of system toolbars. Choose one and it appears.

Double-click in a docked toolbar to undock it. Double-click in an undocked toolbar and it redocks wherever you last docked it (by default, at the top).

Toolbars sometimes seem to disappear. Usually, the problem is that they are docked somewhere off-screen (or far enough off that you can’t find them). We haven’t found a command to fix this, but you can do it by brute force. Use the View Menu to close the toolbar in question. SET RESOURCE OFF and open the resource file. Find the record for this toolbar (Id=”TTOOLBAR” and Name is the toolbar’s name). Delete the record and pack the file. Close the resource file and SET RESOURCE ON. When you bring up that toolbar again, it’ll be in its initial, default location.

Toolbars are customizable. Bring up the Toolbars dialog from the View menu, and click the Customize button. You can drag the standard buttons onto any toolbar to customize it to your liking.

Form Designer Hints

If you’re designing forms for users who work at a lower video resolution than you, make sure you don’t make things too big. The Forms page of the Tools, Options dialog lets you set a maximum design area to any of the most common Windows video modes. Limiting a form to 640 x 480 doesn’t prevent you from creating forms with insufficient room because of all of your added menus, status bars, toolbars and other miscellaneous ornamentation, so you should still test your application in the lower resolution for ease of use. (Try to keep form height to 390 pixels or less to account for all these factors.)

Always test your applications in both large and small fonts so that, no matter which way your users set up their machines, things look right. (We’re pretty sure Microsoft doesn’t always remember to do this, since Tamar habitually uses large fonts and frequently finds graphic glitches in MS apps.) On this front, don’t ever, under any circumstances, use 8-point MS Sans Serif or any other non-scalable fonts in your forms. They don’t scale properly between large and small fonts. Stick to TrueType or OpenType fonts.

If you’re always annoyed by the Prompt to Save Changes dialog when you run a form right from the Designer (well, gee, what else would you want to do?), get rid of it by unchecking that item in the Tools, Options dialog. (Thanks to our good friend Mac Rubel for this one.)

There are two ways to set the tab order for controls. One is by clicking on each control in the order you want it. The other is by using a list with movers. You choose which method you want in the Tools, Options dialog—again, the Forms page is used.

Know the grid of lines that appears on the background in the Form Designer (or for form classes in the Class Designer)? You can control that. By default, the grid lines are 12 pixels apart in each direction. In VFP 7, they really are 12 pixels apart. In VFP 6 and earlier, the grid was drawn at double the scale. You can change that for a particular form by using the Set Grid Scale item on the Format menu, or for all new forms using the Forms page of the Tools, Options dialog. This option is not only used for the Snap to Grid feature, but it is also used when you copy and paste an object with the Ctrl+C, Ctrl+V shortcuts—the copy appears one grid increment to the right and below the original.

When you’re writing code in a method window, right-click and choose Object List to avoid having to type long object references. Just choose the object you’re interested in and an appropriate reference is added at the cursor position. In VFP 7, you can still use the Object List, but IntelliSense helps you choose not just object references, but also helps to select its members. VFP 7 adds some new options to the right-click menu. You can toggle a breakpoint from within the code window (or double-click in the selection bar on the right of the code window), add a bookmark that persists for only this VFP session (or Shift+double-click the selection bar), or add a task list item (or Ctrl+double-click the selection bar).

You can run a form directly from the Form Designer using the ! button on the Standard toolbar. If you’re like Tamar and prefer the keyboard to the mouse, use Ctrl+E. In VFP 3, that was it for this capability, but it keeps getting better and better. In VFP 5, another button was added that lets you go back to the Designer from the running form. In fact, anytime you run a form from the Form Designer, closing it takes you back to the Designer. But, in VFP 5, you had to make sure that the form window itself was on top in order to click the ! button. Not anymore. In Version 6 and later, not only can you click ! no matter which window is on top (the form, the property sheet, or a method code window), but when you return to the Form Designer, the last method code window you were working in is still open and it’s on top.

Speaking of methods, the METHOD keyword of MODIFY FORM and MODIFY CLASS is a real time-saver, too! If you’re repeatedly in the run-test-crash-code cycle, consider using MODIFY FORM YourForm METHOD YourMethod if you keep going back to tweak on the same chunk of code.

Draw Me a Map

One of the truly powerful changes in VFP 5 was the addition of field mapping. In VFP 3, when you dragged a field from the Data Environment or the Project Manager onto a form, you got a text box based on the VFP base text box class. When you dragged a table, you got a grid based on the base grid class.

However, using the base classes is a bad idea. It’s always better to use a subclass at least one level down the hierarchy in case you need to make some global changes (like getting rid of MS Sans Serif, 8).

Field mapping lets you specify the classes used when you drag a field or table onto a form. It also lets you specify the form class used by default when you issue CREATE FORM. You set up your mappings in, where else, the Tools, Options dialog, save them as defaults, and forget about it. (We tend to forget about it so much that we’re occasionally surprised to find ourselves working with a test form that isn’t based on VFP’s form class.) You can use a project hook to swap the settings you want in and out when a project is opened and closed. However, if you open multiple projects at the same time and they have different settings, there’s no way to ensure that the right settings are in place as you move among the forms. VFP 7 offers a workaround with the new Activate method of the project hook. You can swap every time you switch projects. The only problem is that Activate doesn’t fire if the project is docked.

A View To Kill For

The Data Session window was formerly called the View window, way back in FoxPro 2.x. You can bring up this window by using the SET command, which used to bring up a View window with all the SETtings, which were moved to the Tools, Options dialog.

Opening a table through the Data Session window opens it in a new work area, even if an alias is already highlighted. Open tables are listed in reverse order of being opened—that is, the most recently opened table appears at the top, and the one you opened first shows up last.

The Properties button gets you to the Work Area Properties dialog, which can change such properties as buffering and indices. You can even modify the table from here.

Color Us Happy

Another big change introduced in VFP 5 was syntax coloring. This means that, as you type code, whether in an editing window or the Command Window, it gets colored based on VFP’s interpretation of it. You can control the colors used with the Editor page of the Tools, Options dialog.

The syntax coloring mechanism appears to be a simple lookup, not a sophisticated parser. So, it can’t tell that you’re using a keyword as a table name. For that matter, it can’t even tell that a comment has been continued to a new line. Nonetheless, we love it, and when on occasion we’re forced to use older versions of FoxPro, we find it hard to read the dull black code we see there.

Edit Me This

Aside from syntax coloring, the editor was seriously enhanced in VFP 5. The context menu includes the ability to comment or uncomment a block of code, as well to indent and unindent a block of code. Starting in VFP 7, you can set the character string used to denote a comment, through the Tools, Options dialog. VFP 5 and 6 require you to edit the Registry—the key you’re looking for is:

HKEY_CURRENT_USER\Software\Microsoft\VisualFoxPro\7.0\Options\EditorCommentString

Substitute the appropriate version number in there. It works for VFP 7, too.

VFP 7 added a number of other options to the context menu, such as changing the case, and toggling bookmarks, tasklist items, and breakpoints.

In VFP 5 and VFP 6, a dialog is available on the context menu to teleport you instantly to any function or procedure within the code. In VFP 7, this was replaced with the Document View tool, available only through the Tools menu. The Document View window has some enhancements over its predecessor, most notably being modeless, allowing you to sort by type of entry, and displaying preprocessor directives. The nice color icons really help you zero in on exactly which item you’re searching for.

In the last version of this book, we said that if you hate having BAK files all over your disk, right-click in an editing window and choose Properties. You can still do that, but you’re better off using the IDE tab of the Tools, Options menu (more on that in a bit). The dialog there lets you decide whether backups should be created on every save. (This one is a bit of a toss-of-the-coin. We rarely go back to those files, but when we do, we’re really glad they’re there. Of course, more often, we don’t realize that we’ve fouled up until we’re several saves beyond the critical mistake. That’s just one feature of Visual SourceSafe that we love: It steps in as a backup on steroids, even in a single-developer environment.)

The IDE tab also lets you decide what font your editing windows use, so you can blow things up if, like us, you’re starting to find 10-point type a little hard to work with. You can also decide whether to show line and column positions while editing. We like them on for PRG files, but off for TXT, where we generally have word-wrap on. You can even set the size of a tab for indentation. In versions prior to VFP 7, that one’s a mixed bag because the Tab key inserts actual tabs, not spaces. You might not want those in your code. However, VFP 7 offers an option to insert spaces when the Tab key is pressed.

The right-click dialog saves your settings to the FoxUser table. This is nice because you can save different settings for each program. You can choose to save BAKs for IWantBaks.PRG and leave it off for IllNeverBotchThis.PRG. Okay, so you can do that, but do you want to? You can override these local settings by using the IDE tab of the Tools, Options menu. Anything you set here will take precedence over what’s set in FoxUser. So, when you keep setting line and column positions on, but forgetting to set them as defaults for PRGs, you can go to the Tools, Options IDE tab, and set it the way you really want them. And you don’t have to blow away your FoxUser file to do it.

Another VFP 7 addition is the ability to display white space. Just what do they mean by displaying space that’s already white? If you’ve used Word, and clicked the button with the paragraph symbol on it, you’re familiar with this idea. When white space is displayed, you see a representation of each unprintable character, such as tabs, spaces and paragraph markers. Now you have the same option in VFP. You’ll see that a dot represents a space and “»” represents a tab. Note that what you see varies with whether word-wrap is on or off. Paragraph markers (¶) display when you have word-wrap on. As with the Tools, Options dialog, it’s a good idea to check out Edit Properties every now and then to remind yourself what’s there.

Macro and Cheese

Visual FoxPro includes a keyboard macro recorder that lets you record, edit, play back, store and retrieve sets of keystrokes that you can use to speed the development process. Many old geezers like Ted still have macros for some of their favorite WordStar commands like {SHIFT+END}{BACKSPACE} for Ctrl+K (clear to the end of the line), and {HOME}{SHIFT+END}{DEL}{DEL} for Ctrl+Y to erase the current line. Tamar once created a macro that replicated her favorite feature from a long-ago word processor—it switches the last two characters typed, so that you can quickly change MOID to MODI. The keystrokes you need are {SHIFT+LEFTARROW}{CTRL+X}{LEFTARROW}{CTRL+V}. Other clever ideas are to minimize the keystrokes you have to type for common sequences—for example, storing “CREATEOBJECT()”{RIGHTARROW} so you need only one key to get there. Play with the macro recording tool, available on the Tools menu, and check out the commands PLAY MACRO, SAVE MACROS and RESTORE MACROS for some ideas on what to do with these.

IntelliSense, introduced in VFP 7, can take the place of many of these macros. See “IntelliSense and Sensibility” for more information.

Keep Exercising the Interface

We are all creatures of habit, to one extent or another, and we all tend to get into routines. Click here, drag there, call up the menu for this. And occasionally we’ll gripe that it takes too many keystrokes to get some common task done. Inevitably, a coworker will point out a button on a toolbar that does exactly what we need, without the clicking and dragging. For example, many developers use the Form Controls toolbar, but miss the Form Designer toolbar that gives you access to the Data Environment, the Code Window, the Color Palette, and many of the other tools you need to build forms. Consider, too, developing your own toolbars or menu pads to provide the features you need. If you are constantly calling up a particular tool, consider creating a toolbar button for it. Add it to the Standard toolbar or write your own. This is your development environment—spiff it up to make your coding its most productive.