The LA Fox Developer Newsletter

December 1998

Better VFP (Con’t from page 5)

little classes. That’s one powerful feature of the FoxPro lan-

guage 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 develop-

ers 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 under-

stand 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 champi-

oning 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 architec-

ture 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 applica-

tion 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 Applica-

tion 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