Home  TOC
FoxPro's Future

Jordan Powell

Published in FoxTalk

As this issue goes to press, Microsoft is getting ready to launch FoxPro and ship Access, the interactive database product it has been developing in-house over a period of years. The two products, each with its own distinctive personality, give the company a strong presence in the PC database world. It's a critical moment for FoxPro; the people who first envisioned the product are beginning to find their own place in the Microsoft corporate structure, and FoxPro itself needs to be re-defined, within a new context and a wider corporate strategy.

FoxTalk asked Jordan Powell, a beta tester of both Access and FoxPro 2.5 and a veteran member of the X-Base community, to apply his considerable perspective to these issues, and how they affect you as a FoxPro developer.

Where is FoxPro really going now that it is a Microsoft product? There's been a lot of speculation, some pessimism and probably too much misunderstanding about our future as FoxPro users. In this article I'm going to address FoxPro's future and hopefully give you some useful information about it.

The story so far

In the first place, realize that Fox Software came to a crossroads in 1992 and something was going to have to happen, Microsoft merger or not. Fox simply did not have the resources to do what it had to do to survive. FoxServer was not vaporware because Fox didn't care! It was vapor because Fox simply did not have the resources to do it and the cross-platform products. FoxPro for the Mac has been delayed mainly because their resources were simply insufficient to do both the Windows version and the Mac version simultaneously. They also lacked the marketing resources to sell FoxPro to the fortune 500 in a big way.

Borland, having bought Ashton-Tate, was going to both out-market and out-release Fox by sometime in 1993. Anyone who thinks that Fox could have continued without major changes and cash infusions of some kind is sadly mistaken about the realities of the DBMS market of the nineties.

Meanwhile, Microsoft was working on its Access DBMS which uses a modern variant of the BASIC language. It had to have been embarrassing for Microsoft to have such a glaring hole in its product lineup. They had no DBMS, and their partnership with Ashton-Tate failed to get Microsoft SQL Server off the ground. Some of the marketing types at MS realized that FoxPro was the best version of X-Base out there, and had been trying to talk Bill Gates into doing something about it. They knew that the X-Base language commanded a huge segment of the market and that a product which used the X-Base language would get them into the DBMS market in a big way. They had the marketing resources to put behind FoxPro, and Fox had some interesting and useful technology -- not to mention some very talented people, the kind Microsoft likes.

Obviously Bill Gates was eventually convinced that it was the right thing to do, and so was Dave Fulton of Fox, because the deal was done. Both Bill and Dave have commented about what a good match both people and philosphy-wise they and their companies are. Gates got an entr‚ into the large and lucrative X-Base market, along with some important technology and talented people, and Fulton got the resources he needed to really do FoxPro right.

Status quo: what's wrong with it...

So, what did we get? Did Microsoft buy Fox just to get Rushmore and then dump the rest? Is Access their real DBMS and will they eventually drop FoxPro leaving us high and dry? The answer, in my opinion, is no. Microsoft has no intention of "getting rid" of the FoxPro language or of making us all learn BASIC. I think that FoxPro is going to change after the 2.5 releases -- and I think it will change for the better.

Most of us know that the current event-driven coding model is seriously deficient. I asked Dave Fulton specifically about this. I asked if he realized that writing event-driven apps in FoxPro was too difficult and he said yes, he did. He likes many aspects of the Visual BASIC interface model, such as its development interface and debugging tool. I'd suggest that, if you want to see some of the ideas that will be coming to FoxPro, look at Visual Basic. Don't get nervous though; I'm not talking about the BASIC language part, just the development environment and programming model.

What do I mean by programming model? In FoxPro today, we have to wrestle with the vagaries of the behaviors of BROWSE, GETful and GETless READs and the ACTIVATE and DEACTIVATE clauses and so on to create a form. A form is not really a unified object, it is a collection of commands and clauses that are cobbled together and which must interact in some very complex ways. It is often difficult to figure out in the first place and then very difficult to debug when something goes wrong. The programming model is one of interacting bits and pieces of procedural code.

The reason for event-driven coding is the user interface. You want to create an interface that responds to user-initiated events. This is a complex job, made all the more so by the complexity of the FoxPro code that is required. What is needed is some way to simplify the code.

Access forms incorporate within themselves objects called controls, and they can also contain other forms (subforms) which can be datasheets, or what we call BROWSEs. Each object has a set of properties which can be used to control the behavior of the object with Macros (Access BASIC code). But there is no reason why the language has to be Access BASIC. X-Base with object-oriented extensions which allow it to refer to objects could also be used.

Have you ever been in this situation? The user is sitting in a data entry form with the cursor in the first field. The VALID clause for this field specifies that the field cannot be empty. What happens when the user clicks on the Cancel button? What I do now is look and see where the mouse cursor is, within the VALID clause and if it's on the Cancel button, I skip validation. Of course I have to remember to modify my code if I change the Cancel button's location on the form. In Microsoft Access, you'd assign the cancel property to the Cancel button on your form, and your job would be done.

Access forms have a property associated with them called BeforeUpdate. You can write code here that determines what will happen just before Access applies any update(s) to the record. The BeforeUpdate code will only "fire off" if there was a change to the form. If the BeforeUpdate code decides that the update should not take place, it can restore the original record, using a copy that it saved automatically before the editing began. There is no need for the programmer to save previous values in memory variables. It then cancels the event that caused the update attempt.

The BeforeUpdate code below would be used in Access to determine whether the user wants to save changes. If the answer is "No", the update is cancelled and the form is restored to its original state:

       Function UpdtRec ()
       If msgbox("Save Changes?",36,"Record Changed") = 7 Then
          Sendkeys "{esc}"
          DoCmd CancelEvent
       End If
       End Function
  

Remember, this BeforeUpdate code will only be executed if one or more controls (controls here are equivalent to GETs for memvars) has been updated. It displays a dialog box which asks if the user wants to save the changes s/he made. If the answer "NO", then Sendkeys (equivalent to keyboard) sends an escape which causes the form to revert to its state before the user's updates. The event which caused the update attempt is cancelled by CancelEvent. Record-locking needed for the edit, and the determination of when an update has been made, are also handled internally. I think you can see how much simpler this is than what is currently required with FoxPro. [Editor's note: See the convolutions necessary in Davis DeBard's An Updated UPDATE(), in this issue.]

There is no reason why the KEYBOARD command couldn't be used and why CancelEvent couldn't be made a part of FoxPro's version of X-Base -- and there is no reason why FoxPro could not use Access-type forms.

The difference is the application of an object-based approach to make event-driven applications easier. Object orientation carries several advantages, including encapsulation. As you saw, the code for handling the behavior of the form object in Access is all included (encapsulated) within the form itself. The form's properties control its behavior when it is updated, opened, closed, when the user moves beween records and so on. If there is a problem with a form's behavior you know exactly where to look, based on what event the bad behavior is associated with. It makes no difference what other forms are on the desktop; each knows how it should behave.

Designing applications in terms of objects also makes it easier to translate real world problems into code. An invoice maps into a form, for example. Rather than translating the invoice into a set of procedures you just decide how the invoice form should behave and write code snippets to make it do so.

I think that it's safe to say that the adoption of the models used in Microsoft Access and Visual BASIC is not a threat to FoxPro, but rather a guarantee that it will survive the nineties and that our work will be easier and more pleasant.

... and what's right about it

Lest you get the idea that I think that all of the technical advances are in Access, let me assure you otherwise. The Rushmore technology, FoxPro's seamless SQL implementation, and the fact that you can use FoxPro's powerful record-by-record approach along with the SQL set-based approach represent a truly outstanding feature set. FoxPro's tool based integrated development environment, while it needs improvement, was also a major step forward.

Anyone who saw Brian Jones' FoxPro logistics model at DevCon had to be greatly impressed. As Brian says, "FoxPro 2's data manipulation and interfacing capabilities bring new tools to the table, tools that permit us to approach a class of problems generally left to other languages and platforms." I know that Bill Gates and the Access development team left DevCon with a new respect for X-Base, having seen Brian's work, as well as other FoxPro capabilities they saw being used.

My interactions with Microsoft have left me with a positive but watchful attitude. I think that Bill Gates understands that FoxPro users have a strong view of what FoxPro is and should be. At Devcon he said that X-Base, along with C and BASIC, was a Microsoft language and that integrating object orientation into the language must be done with care, by people who are familiar with the language. He also said that Microsoft is committed to using user input to "fill in the details". As he stated it, Gates' vision now is one of connectivity, the ability to reach out and access differing file formats, different database servers, mini and mainframes systems and so forth. It is not to force the world to use BASIC, rather it is to give them the ability to use whatever data they want with whatever language they prefer.

Dave Fulton is now a Microsoft Architect for Databases and reports directly to Gates. As I understand it, Architects are responsible for implementing the Gates vision in their respective areas. Dave Fulton seems to be thinking along the lines of providing language-independent tools, along with language-specific implementations that will allow easy access to the tools.

By mid-1993 at the latest, the transition from Fox to Microsoft should be complete, and we should begin to see the benefits. I think that by the spring Microsoft should be telling us where FoxPro 2.x or 3.0 will be going and what will be in it, in general terms. We should know approximately when a database server solution should be expected and what general form it will take. The event-driven programming problem should be well on its way to being solved as well.

Your chance to exert influence

When Microsoft comes to your user group or company, tell them what your concerns and problems are and demand eventual results. Right now Microsoft is exhibiting a strong interest in our input -- and that should never change. For our part, we have to give them meaningful input and hold them to their promises and to being responsive to our needs.

If you have suggestions for Microsoft you can leave them on the Wish line at 206-936-WISH or on CompuServe in the Foxforum, and I strongly encourage you to do so. I am optimistic about what Microsoft is going to do for us but I am not all starry-eyed about it. We must keep them on track, hold them to their commitments and promises and watch carefully to make sure they get it right.

We are on the threshold of a great period of growth for FoxPro, in my opinion. I think that the increased money, marketing, design, and testing resources that Microsoft will bring to bear on FoxPro will eventually result in major improvements. But we are going to have to accept some inevitable changes, such as I have described.

About the author:

Jordan Powell is an independent consultant specializing in custom solutions for businesses. He strongly believes that computer systems should empower their users and focuses on using computer technology to help business work better and more efficiently. He has been using X-Base since 1982. He can be reached on CompuServe, ID 74206,2521.

See also: People That Helped FoxPro to Become a Legend: Jordan Powell

Home  TOC

If you have any information that can help us to compile this history, please, send us a message. Thanks!