When Should You Use the Power Tools?

Always.

Okay, would you believe:

Almost Always.

We used to say (and believe) “always” as the answer to “When should you use the Power Tools?” But some changes, both in the product and, more importantly, in the development world, mean that there are some valid reasons to write code by hand. Let’s look at what the Power Tools are, and then we’ll come back to the question of when not to use them.

What’s a Power Tool?

Long, long ago, in a land far away, Xbase was a command-line language. A not-very-user-friendly dot greeted you on an empty startup screen, and you were left to your own devices to create screens, reports, menus and other interface elements. Programmers spent their hours with graph paper, trying to calculate how many fields could be fit on a page, how many characters in each prompt. Hours were wasted drawing, erasing and redrawing these prototype screens, and more hours consumed trying to transfer them from paper to screen.

Evolution brought primitive tools—first to reports, then to menus and screens. Like many of the innovations introduced into the language, third-party add-on tools were first on the scene, adding desperately needed features into the product. These third-party tools allowed you to develop a sample screen, perhaps in a template language, and offered a method to translate these templates into your Xbase language of choice.

FoxBase was one of the first Xbase languages to add template generation into the product. The first attempt, with the FoxCode product, introduced yet another template language and a generator to write FoxBase code. Although it worked quite well, learning yet another language just to code screens was a burden, and acceptance was not universal. The FoxPro product broke new ground, in bringing everything under the FoxPro language’s domain. Design tools built FoxPro tables (in the standard DBF format) and then generation programs, also written in FoxPro, read these tables and created executable FoxPro code. Although this may seem like an inefficient and time-consuming process, in fact, the open nature of the generation process allowed FoxPro programmers to intervene in the process, customizing the underlying tables and generation programs to extend the results of the generated objects in ways that Fox Software, and later, Microsoft, never anticipated. One of the most famous of these, Ken Levy’s GENSCRNX program, allowed additional capabilities within screen programs, such as screen elements becoming visible under only certain conditions, or 3-D effects added without programmer painting.

The overall concept behind the Power Tools is pretty straightforward. You use a visual design tool to lay out the form, label or report you want. The tool saves your design into a series of DBF records. These DBF records can then either be generated into code, in the case of 2.x forms or menus, or interpreted at runtime, in the case of labels and reports. The open nature of this design-generate cycle leaves the doors open to innovative developers who can take the core “engines” and drive them in ways not anticipated (or perhaps needed) at the time the tools were designed. This idea of allowing extensibility of the core product in new ways was a key concept behind FoxPro 2.x, and it continues in Visual FoxPro with its accessible design storage, user-extensible data structures, and open Wizard and Builder engines.

With Visual FoxPro, Microsoft turned the tables a bit, but still leaves us with lots of room to customize the process to our own ends. In the 2.x model, we used built-in objects, placed them on an input or output form, and then added code to get them to behave the way we wanted them to. We needed to intercept the generation process to customize the objects beyond the basic options that were provided for us. In the VFP model, we are not limited to using the objects that Microsoft wants us to use. Rather, we can create our own powerful custom controls, pre-programmed to do what we need them to do, and use them on our forms. We don’t need to create our objects by handcrafting them; they can come from pre-built Visual Class Libraries. We don’t even have to set their basic options ourselves—we can build our own Wizards to do that. After creating these objects, we can run our custom Builders on them to tweak them the way we’d like them. (See the “Builders and Wizards (and Bears, Oh My!)” section, which details these wonderful tools.)

“I hand-coded it myself before, and I’ll hand-code it now,” a few diehards out there say. Well, let’s see if we can give you a few more reasons to reconsider your stand…

Cross-Platform Transportability

Most VFP developers snicker at the thought of cross-platform transportability, now that it has become clear that Microsoft intends to release and support Visual FoxPro on its Win32 platform only. But cross-platform does not mean all the versions of Windows. The tables of the Power Tools are not just for the use of the Power Tools, but can be used by developers as a repository of design information. Having forms, menus and reports designed with the Power Tools gives us access to their designs, in our FoxPro programs, so that we can generate the HTML, SGML, XML, or whatever-ML an application may call for. Power Tools store design metadata, a commodity that promises to become more valuable over time.

Upgradability

There have been numerous versions of Fox to date, and we hope to see quite a few more. Each upgrade has added capabilities, features, language enhancements, and has also occasionally required some changes to the basic structure of some of the Power Tools’ tables. This can be performed automatically as part of the upgrade; but don’t expect Microsoft to come out with a code parser to graze through your volumes of code and try to introduce new features into it. Processing tables, on the other hand, is far easier. A Power Tool user will find it easier to get to the next upgrade.

Enhancements

There are a number of third-party add-ons (some for sale, some for free) for Visual FoxPro. Many of them—new custom visual classes, business rules managers, Builders, Wizards, and so forth—expect and perhaps require your code to be properly encased in the Power Tool format. Don’t miss out on the great work of others. Avoid the ‘Not Invented Here’ syndrome and leverage the work of others into delivering the best application for your clients. See “Resource File” in “Back ‘o da Book” to get an idea of what kind of tools are available.

So Why Not Use The Power Tools?

Men have become the tools of their tools.
—Henry David Thoreau

The ability to build COM components, added to VFP 5, lets FoxPro play with the big boys. We can build objects that other applications can just plug in and use. In Service Pack 3 of VFP 6 (a really strange place to introduce something new and monumental), the Session base class was added.

Session was born to be the basis for COM components. It’s a lightweight class with a private data session. Session got even better in VFP 7. When it’s used for a COM object, its native PEMs are protected by default, so you decide which of them to expose to the outside world.

What does this have to do with the Power Tools? Well, Session is one of the base classes that can’t be subclassed in the Class Designer, but can be subclassed in code. On top of that, several other features (such as specifying COM attributes) added in VFP 7 apply only to code classes.

The result is that, while we still believe that the Designers are the right place to create your forms and any classes that are meant for use within VFP, manual construction is your best bet for building COM components. The good news is that VFP 7 introduced several new tools and features that make working with classes in PRG files a whole lot easier. Be sure to check out Document View, shortcuts and bookmarks.

The rest of this section digs into the Power Tools, including the ones that ease manual construction.