I've been working with a commercial framework for Visual FoxPro. There's a third-party book about this framework, as well as a Help file and some tutorials, so I've been able to get some quick results. Nevertheless, when working with this product, I often feel like I'm programming with gloves on.

If all I want is "standard" stuff, the framework has tools to create it for me. But whenever I want to do anything a little bit differently, I can't just knock out the code like I usually would. Instead, I have to dig into the book, Help file, examples, or even the class libraries that comprise the framework to figure out how this particular task is accomplished through the framework, rather than working around it.

Overcoming a steep learning curve

This exercise has led me to think about the learning process in software development. I've spent many years learning VFP (and FoxPro and FoxBASE+ before it). More than a dozen years of experience with the product means that I have large chunks of both syntax and semantics at my fingertips. When I want to do something straightforward, I can generally sit down at the keyboard and know exactly which commands to use. Obviously, more complex tasks require more forethought, but it's rare for me to encounter a problem in VFP for which I need to look up more than syntax (and, of course, with IntelliSense in VFP 7, I rarely even have to do that).

Several years ago, I became intrigued by Automation. Since then, I've spent a a lot of time writing code to automate Microsoft Office products. Although I've barely scratched the surface of the various object models, I've reached the point where I can write a great deal of fundamental code without looking up more than syntax. My last few client projects have involved writing VBA code within the Office products, and my experience automating them from VFP has made this transition fairly easy (though I don't think I'll ever remember to put THEN at the end of an IF statement).

My experience with VFP and Office products means I've been able to work with other object models comfortably. But somehow, using this framework is much more difficult. If I spend enough time with it, I'll reach the point of comfort, but the learning curve is still steep.

Why bother?

Why is learning a framework different from learning the object model for an automation server? I think it's because a framework requires you to rethink the whole structure of your application—and even the process by which you create it.

When you automate a server, it's a side process in some sense. You're still writing VFP (or VBA) code; you're just using it to talk to another object and you can view the server's commands much like UDFs you've written yourself.

Working inside a framework means getting your head around the way someone else has structured an application. It's much like maintaining an existing application. You have to get a feel for the way the application is organized. At first, you only make little changes, to see what repercussions they have. The longer you work with the application, the more confident you become in your knowledge of its structure and operation.

If it's this hard to do, why bother learning a framework? That's easy. The framework contains code to handle all kinds of things I need in almost every application I write -- things such as conflict resolution, validation of data, and so forth. Never writing that code again seems worth some initial struggles.

If you've already implemented your own framework for your applications, and it does what you need, stick with it. If you haven't, you'd be well-advised to look at the various frameworks available. You'll find ads for many of them in FoxPro Advisor magazine.

Still haven't upgraded?

You probably know VFP 8, code-named Toledo, is in development. (See the August 2002 Advisor View column for some new features.) In fact, all Visual FoxPro DevCon 2002 attendees will go home with a copy of the beta. However, it will be some time before it hits the street.

If you haven't upgraded to VFP 7, what are you waiting for? As I said in the July 2001 issue, IntelliSense alone is worth the upgrade. Besides IntelliSense, VFP 7 includes increased support for XML, the ability to create and consume Web Services, better tools for COM development, improvements in interface creation, and more. (For a detailed list, check out "What's New" at http://msdn.microsoft.com /vfoxpro/technical/documentation.asp.)

So, don't wait for VFP 8. Upgrade to VFP 7 now, download the service pack from http://msdn.microsoft.com/vfoxpro/downloads/updates.asp, and find out what you're missing.