The LA Fox Developer Newsletter

December 1998

Better VFP (Con’t from page 5)

little classes. That’s one powerful feature of the FoxPro language they really love.

MSDN: Would you say FoxPro developers are loyal to the
product?

RIVARD: Oh, yes. That’s clear. They’re loyal because they love the product. But there’s also something outside of Microsoft that keeps developers loyal to Visual FoxPro. That’s the FoxPro developer community, which is very tight-knit. FoxPro developers help one another a lot. They answer questions for each other. They tend to be big supporters of each other, because they know the more FoxPro developers who do well and understand the product, the better it is for their own business. FoxPro developers are kind of an entity unto themselves in this way. They’re different from other developer communities. Most have spent years with the product, and they’re always championing new features they want us to put in the next version.

MSDN: Where does Visual FoxPro get its speed?

RIVARD: Performance becomes interesting when you start thinking about it as a feature, as something to be designed into a product. That’s what happened in early versions of FoxPro, before I worked on the product. From the beginning, it was designed to be fast.

In the old xBASE market, the speed ota database engine was critical. Speed was the benchmark that xBASE competitors measured their products against. Because speed was such a big deal, a lot of effort always went into making FoxPro fast. We’re still working on that. Because Visual FoxPro uses a local database engine, it basically runs on local tables. Most of the processing happens right in memory on your PC’s own CPU. This gives us the advantage of being able to code the product to perform as quickly as possible. Visual FoxPro is limited only by the speed of the machine it’s running on. FoxPro grew up in the days of slow, clunky machines running MS-DOS and Win 16. It was optimized for these machines. As we get faster and faster machines, we inherit that old architecture. But that old architecture still works really well, since it lets Visual FoxPro do all of its processing locally, in memory. We try to buffer as much information as possible in memory, without hitting the hard drive. This gives Visual FoxPro its speed.

MSDN: What are the most significant new features in Visual FoxPro 6.0?

RIVARD: We focused on a lot of key areas in version 6.0. I divide them into two camps: interoperability and RAD (rapid application development]. By RAD, I mean features that help developers get things done quickly. For interoperability, we improved our COM server support. Now you can create Fox automation components that run in MTS [Microsoft Transaction Server]. With Visual FoxPro 5.0, there were some technical problems with that.

A lot of developers using Visual FoxPro 6.0 and MTS are able to deploy solutions that run on Web servers or do back-end server processing. They can achieve a lot better performance and interoperability. For better interoperability, we also added OLE drag-and-drop to the forms package in Visual FoxPro 6.0. This is one feature you would expect all Microsoft products to have, but FoxPro didn’t grow up with it, so we had to plumb it in. We had a drag-and-drop model before that was not OLE drag-and- drop, which meant it didn’t interoperate with Microsoft Office, Visual Basic forms, and other important things.

Now Visual FoxPro includes standard OLE drag-and-drop. Our customers really love this. It’s a much easier model than our previous one.

MSDN: What did your team add to Visual FoxPro 6.0 to improve developer productivity?

RIVARD: We added a huge amount of sample code or library code and predefined a slew of base classes, which we call the FoxPro Foundation Classes. These ship in a subdirectory named FFC. A couple of our key developers on the Visual FoxPro team came up with these classes to try and speed development. With Visual FoxPro 6.0, you can go grab these base classes and use them to add functionality to your application in a whole bunch of different areas.

This was one of the important features developers asked us for. They wcnted to be able tc cr3ck open the Visual FoxPro 6.0 box and rightaway get a very high-level toolsetto start building applications. Developers also asked us for a wizard-like tool to help them get started building applications. So we created the new Application Wizard in Visual FoxPro 6.0. The wizard makes it easy to create a simple running application with a framework developers can build on.

Developers who are new to Visual FoxPro can use the Application Wizard to get started. Experienced FoxPro developers can use it to learn about new features. They can try plumbing them in with the wizard.

The other thing we did to improve developer productivity was add a new Component Gallery. Ken Levy, one of our star developers, wrote this. He’s well known in the FoxPro community. The Component Gallery is like a space where developers can organize their work in Visual FoxPro 6.0 and have it interoperate with the rest of the Visual FoxPro IDE. In creating this gallery, Ken pressed the limits of what our object manager and OOP language can do. He would always come to me and say, “I need it to do this, I need it to do that.” It was a great for me, as a developer, to see the kinds of intricate and complex things he was trying to design into Visual FoxPro 6.0.

Our users will just see that there’s a new Component Gallery in Visual FoxPro 6.0 that does all these great things. They won’t see that under the hood, it’s a very complex piece of code. The gallery really made Visual FoxPro 6.0 a lot better.

(Con't page 7)

Page 6