Before you say “Who cares, I've already seen them…” or "Who cares, I don't use Visual FoxPro…", take a quick look at this article.

I think you'll discover some things that you didn't know; and if you don't currently use Visual FoxPro, you might even discover you, too, are looking forward to the next version of Fox.

First, for those readers who have never used Visual FoxPro, I'd like to provide a brief description of Visual FoxPro and how it fits into Microsoft's vision of application development. Visual FoxPro, one of the tools within the Visual Studio package, has been evolving over the past 15 years. Visual FoxPro has become a powerful object-oriented language that fully supports the Windows DNA architecture for creating multi-tier business applications that can be delivered over networks. It can be used to create any tier of an n-tier design, since it includes front-end design tools, the ability to create middle-tier COM components, and its own powerful data engine.

Visual FoxPro is especially powerful for creating middle-tier components, since it has extensive commands and extremely robust string manipulation features. Visual FoxPro has been used in very large scale mission-critical applications, like the management of the Euro Tunnel (the “Chunnel”), Visual CAD 911 software, and in JFAST, a system used by the U.S. military to track and deploy troops and equipment.

The newest version, which will be part of Visual Studio.Net, has been previewed at several major conferences, including FoxPro DevCon 1999 in Palm Springs, the Double Impact Mega Event in Hawaii, and most recently at the Visual FoxPro DevCon 2000 Connections in New Orleans and the Visual FoxPro DevCon 2000 in Miami Beach. The new features disclosed so far fall into three major categories:

  • Enhanced support for Window DNA and .Net development
  • Integration into Visual Studio
  • Increased productivity

Enhanced support for Window DNA and .Net development

Since Microsoft's Windows DNA and .Net development is their primary platform for building tomorrow's enterprise applications, it's important for Visual FoxPro to easily integrate into this framework. To facilitate this integration, several key enhancements have been made to version 7 of Visual FoxPro. Among them are:

  • Strong Typing
  • Implementing Interfaces
  • COM+ Events Support
  • Event Binding Support
  • OLE DB Provider

Strong Typing

Strong typing is the ability to assign a variable type to parameters, return values and variables. To support this feature, new language elements have been added to the DEFINE CLASS syntax as follows:

DEFINE CLASS ClassName1 AS ParentClass
    PROTECTED|HIDDEN|PropertyName1, PropertyName2
    Name([parm [AS type]])
    [AS type] [HelpString helpstring]
    IMPLEMENTS InterfaceName IN Typelib |
    typelibguid | ProgID

New to this command is the [AS type] enhancement. AS type allows us to designate the type of each of the parameters. The ability to create strongly-typed parameters is increasingly important when programming COM objects, since it allows the client to know the exact type of each parameter that the class is expecting to receive. Additionally, we will also be able to designate whether the parameter is passed by value (default) or by reference (indicated by an @ sign following the type information). To see an example of strong typing, see the examples in the COM+ Queued Components article in this issue.

Another use of the [AS type] portion of the command is to define that a Procedure does not return a value. This type is “void” (as it is in many other languages). The fact that all procedures in Visual FoxPro 6.0 return a value (True by default), is a problem when creating Queued Components. Since Queued Components are executed at a later point in time (asynchronously), no return value can be expected. This must be indicated by the method definition. Here is an example that suppresses the return value through the use of “VOID”:

PROCEDURE postTransaction(nMaxAmt AS Number, cCustomerID AS Number) AS VOID
    ** procedure code goes here

Again, additional information and examples are provided in the COM+ Queued Components article in this issue.

Similar to strong typing of parameters and return values, strong typing is also available for variables:

LOCAL oWord AS Word.Application

The fact that Microsoft refers to this behavior as “strong typing” is perhaps a bit of a misnomer to programmers familiar with other languages. This is because variables that have been assigned types in Visual FoxPro can be reassigned to other types at any point during program execution. Strong typing of variables is used within Visual Foxpro only for IntelliSense (see below for more details).

However, strong typing of interface information (return value types and parameter types) is important to indicate proper component usage to clients. Many of the BizTalk Server examples in this issue would not work without strong typing, which provides crucial information about the component.

Implementing Interfaces

You may have noticed another new feature in the above DEFINE CLASS syntax - the IMPLEMENTS portion of the command. Interfaces are simply the properties, events and methods of a COM object. Thus, the IMPLEMENTS keyword is just a simple way for a class to guarantee that it supports a given set of PEMS. Assume that you have an application that can be extended using custom objects. Those objects would need to fulfill certain criteria. For instance, the object may be required to have Execute() and Configure() methods. The application relies on those methods being present. In other words, it defines that the interface for the custom extension objects consists of those two methods. But, the application itself doesn't do anything with those two methods. It simply calls them, leaving it up to the extension objects to implement code for those two methods. Thus, the terminology “implementing an interface”.

Let's look at an example to make this clearer. In the Spring 2000 issue of CoDe Magazine (page 12), Markus Egger described Loosely Coupled Events with COM+ by providing an example that created a publisher (the ‘wife’ class) and a subscriber (the ‘husband’ class). The husband class subscribed to the wife's TakeOutGarbage event. In that example, the husband class was created in Visual Basic, since Visual FoxPro 6 does not support the IMPLEMENTS keyword. Using that same scenario, let's see how we can create this husband object with Visual FoxPro 7. The TakeOutGarbage method code in the husband class in Visual FoxPro 7 would be very similar to the Visual Basic code found on page 16, and would look like this:

DEFINE CLASS Husband AS Session OLEPublic
    IMPLEMENTS Garbage IN wife.garbage
    PROCEDURE Garbage_TakeOutGarbage (What AS String)
        ** Code goes here...

In this example, we are guaranteeing that our husband class has ALL the same properties, and methods that make up the garbage interface in the wife object (in this case there is only one method: TakeOutGarbage). By using the IMPLEMENTS keyword, we are also insuring that any parameters passed are of the proper type. In fact, if we did not include the AS String to define the What parameter, COM would produce an error, since our interface does not match the interface we claim it matches (parameters are part of the interface definition).

All of the methods belonging to the implemented interface start with the name of the interface, followed by an underscore and the actual method name. In order to implement the method TakeOutGarbage from the garbage interface, our method needs to be called Garbage_TakeOutGarbage.

This class can have additional properties and methods and can, in fact, implement multiple interfaces. The component that defines the interface contains only abstract events and methods - there is no code in that object (in our example the wife object). Here is how the code for the wife object would look in Visual FoxPro 7 (compare to the Visual Basic code that appears on page 14 in the Spring 2000 issue):

DEFINE CLASS Wife AS Session OLEPublic
    PROCEDURE TakeOutGarbage(What AS String)

As discussed above, the TakeOutGarbage method is an abstract method. It simply defines the interface.

IMPLEMENTS is an extremely important functionality that allows Visual FoxPro components to work well in a COM environment. It is possible to use a component that doesn't have this functionality (as is true for Visual FoxPro 6), but for many COM+ features, it would be necessary to first create a wrapper object using a language that can implement interfaces, such as Visual Basic.

COM+ Events Support

COM+ Events allow applications to publish events to the COM+ Event Service and to allow an infinite number of subscribers to these events. Since the publisher has no knowledge of the subscribers, the events are said to be “loosely coupled”. What this means is that you could create a component that goes out to the web every 15 minutes and gets the current stock quotes, then raises an event if it sees that one of your stocks has changed more than 10%. This object would be a publisher. You could then program several subscriber objects to react to this event.

For example, you might want to bring up your web browser and navigate to your stock page so that you can buy or sell that stock. You might also create a component that automatically sends an e-mail to your spouse telling how rich (or how poor!) you are about to become. It doesn't matter what language is used to create these components, as long as they can be registered with the COM+ Event Service. For an object to support COM+ Events, it must be able to implement interfaces. As discussed above, since Visual FoxPro 7 will support the IMPLEMENTS keyword and strong typing, it can create both publisher and subscriber objects. For additional information about COM+ Events, see Markus Egger's article on page 12 in the Spring 2000 issue of CoDe Magazine.

Event Binding Support

Visual FoxPro 7 will have the ability to bind to a COM Server's events. This means that developers will be able to write code in Visual FoxPro to run whenever an event occurs. Typical examples of COM Server events are those that occur in the Microsoft XML Parser (Microsoft.XMLDOM), ADO, and the Microsoft Office tools like Word, Excel and Outlook. For example, Event Binding Support will allow the developer to run code when an XML document has finished loading and the data is available, by writing code to be run when the OnDataAvailable event occurs. Or similarly, FoxPro code could be run whenever Outlook's NewMail event is raised. Event Binding Support tremendously expands the types of VFP programs that can be created.

This is a three step process. First, you create a class that implements an interface of the object to which you are binding. Then, you create an instance of both the object you created and the object you are binding to. Finally, you must ‘bind’ the two using the EVENTHANDLER(oCOMObject, oVFPObject) command. These two objects are said to be “tightly coupled,” since they must both be in memory, statically coupled by the EventHandler() function. A good example of binding to an ADO object is on the Microsoft site at:

OLE DB Provider

Visual FoxPro 7 will provide a full-featured OLE DB Provider. The current version of Visual FoxPro provides only an ODBC driver for outside access to FoxPro tables (DBFs) and databases (DBCs). This new version will be robust, scalable and fast, increasing the ability of other applications, like ADO and Microsoft Office, to read and write to FoxPro tables. Those who have tried to use Visual FoxPro data through ADO will appreciate this enhancement.

Integration into Visual Studio.Net

The next version of Visual FoxPro will be integrated to enable the developer to create and debug Visual FoxPro components and Web services from within the Microsoft Visual Studio.Net development environment. This will allow developers to utilize common tools and knowledge between the development languages of Visual Studio.

Visual Studio.Net will provide the ability to create a Visual FoxPro COM component within the Visual Studio New Project dialog. Then, a .DLL can be created from a single program file that contains an OLEPublic class.

With the current version, developers must completely debug their code before compiling it into COM components. In other words, the developer cannot debug from Visual FoxPro into a COM component, or debug from other languages into a Visual FoxPro component. However, with version 7, the Visual Studio development environment fully supports the debugging of COM components and Web Services into and out of Visual FoxPro.

Increased Productivity

There will be several new enhancements to the Visual FoxPro 7 development environment and language that will greatly increase the productivity of the developer. These enhancements not only reduce the amount of code that the developer must type, but also provide a greater degree of control over user actions. These enhancements include:

  • IntelliSense Technology
  • Editor Enhancements
  • Dockable Windows
  • Document View Window
  • Database container events
  • Object Browser
  • Task List
  • Active Accessibility programming interface support

Information about each of these enhancements can be found at:

IntelliSense Technology

IntelliSense Technology in Visual FoxPro 7 will be similar to that which exists today in Visual Basic and Visual Interdev. IntelliSense automatically fills in properties, events, methods and parameters as the developer types. This increases the speed of development by decreasing the amount of code that the developer must type, as well as saving time usually spent referencing documentation. The IntelliSense technology in Visual FoxPro 7 will consist of the following features:

  • Auto List Members. Displays a drop-down list of valid members (properties, events, methods, and objects) for a specific object reference. For Component Object Model (COM) components, the information is read from the type library. Of course, all Visual FoxPro classes are supported as well. Figures 1 and 2 display this feature.
  • Auto Quick Info. Displays an Item Tips-like window for commands, functions, properties, methods, and events. The information in this window includes a list of function parameters or command arguments, as well as their data types, if available.
  • Auto List Values. Displays a drop-down list of valid property settings. For example, if a property is of type Logical, a list containing True or False is displayed. For properties in type libraries, Visual FoxPro will support enumerations.

Early tests show a very impressive IntelliSense implementation that goes beyond the capabilities of Visual Basic and Visual Interdev. For instance, Visual FoxPro IntelliSense can handle members of collections just fine, while other tools are limited in that respect.

Editor Enhancements

Figure 1 - An example of IntelliSense technology in Visual FoxPro
Figure 1 - An example of IntelliSense technology in Visual FoxPro
Figure 2 - Visual FoxPro 7 will have the ability to both tab and dock windows to conserve screen real estate
Figure 2 - Visual FoxPro 7 will have the ability to both tab and dock windows to conserve screen real estate

The following is a list of enhancements made to the editor in Visual FoxPro 7:

  • Provide bookmarks and shortcuts to make it easy to return to code (bookmarks are temporary, while shortcuts are permanent.)
  • Either tabs or spaces to indent code.
  • Customization of comment strings.
  • Hyperlinks in code to link to Web sites or shared documentation.
  • Dirty File Indicator to indicate when code changes have been made.
  • Support for display of white space in code.
  • Set breakpoints by clicking in the margin of the code window.

Dockable Windows

In today's programming environment, screen real estate is at a premium. Very often, the developer is left wishing for more room on the screen. Dockable windows help manage the screen real estate, since tool windows can be docked on the side of the screen and can remain visible while the main design and code windows are maximized.

Visual FoxPro 7.0 not only supports windows docked at the edges of the screen, but also allows docking windows together, either in a linked or tabbed fashion. In a link-dock scenario, two or more windows are docked together side-by-side or on top of each other. In a tab-docked configuration, two or more windows overlay each other. Tabs at the bottom of the window provide an easy way to switch between windows. Figure 2 shows the Command Window and the Document View Window tab-docked together.

Document View Window

Visual FoxPro programs can be large! Very often, large PRG files or class libraries total several hundred lines of code, with a large number of individual methods. This can be a navigation nightmare.

In Visual FoxPro 7, the new Document View Window allows the developer to quickly and easily navigate through the various methods by displaying them in a quick access list. The developer can simply click on a method name to jump to the code. Figure 3 shows an example of the Document View Window.

Figure 3 - The Document View Window
Figure 3 - The Document View Window

Database container events

Visual FoxPro 7 provides hooks into the various events of the database container and tables, such as the BeforeOpenTable event or the AfterRenameTable event. These DBC events have several uses, including:

  • Decrypting and encrypting data during table opening and closing operations.
  • Preventing users from accidentally changing or removing important database objects such as tables, views, and stored procedures.
  • Verifying a user's credentials when a table is opened.
  • Providing third-party tools with hooks into database development activities.

These Database container events can be created through the Database Designer interface or from within program code.

Object Browser

Visual FoxPro 7 has a powerful new tool called the Object Browser. The Object Browser provides an easy way to explore the Classes, Constants, Enums, Events, Interfaces, Methods and Properties of any registered COM object. Understanding how to interface with various COM objects will become increasingly important as applications grow more sophisticated. For example, to bind to a COM event or to create a subscriber object as described above, you must understand the interface that the object implements. It is also necessary to be aware of each method in the interface, as well as the parameters and return values required. The Object Browser not only displays that information, but also creates the source code necessary to implement the interface.

The Object Browser shows COM server information in great detail. It shows the objects in a COM component and also shows all of the interfaces that are not directly exposed. This is important when using components such as the XMLDOM parser. The Object Browser that ships with Visual Basic allows looking up the methods and properties attached to the Microsoft.XMLDOM object, but it does not display the type of objects the methods return. The Visual FoxPro Object Browser, however, will guide you to the appropriate interface when you explore that method.

Unlike early bound languages, Visual FoxPro cannot use constants defined in type libraries. However, the Object Browser can display the constants and even create source code to use them via #Define statements.

Figure 4 displays information about the Microsoft Excel object inside the Object Browser.

Figure 4 - The Object Browser
Figure 4 - The Object Browser

Task List

Visual FoxPro 7 provides a Task List Dialog as a way of keeping track of outstanding programming tasks. The programmer simply adds a comment in the program where he wants to return later. Then, he can right-click on the comment and pick the “Add Task List Shortcut” item from the popup window. Figure 5 shows a program with a Task List Shortcut attached, as well as the Task List itself.

Figure 5 - A program containing a Task shortcut and also the Task List Manager
Figure 5 - A program containing a Task shortcut and also the Task List Manager

Active Accessibility programming interface support

There are many handicapped computer users are blind, hearing impaired, or have restricted mobility. Active Accessibility is part of the Windows Operating System and is accessible through COM. Visual FoxPro 7 will support the Active Accessibility programming interface and enable Visual FoxPro applications to be written specifically for users with special needs.

This feature also has the nice side effect of exposing all Visual FoxPro interface elements (internal or user-created) through a COM interface. Using these features, Visual FoxPro can be controlled for tasks such as automated testing.

Other Enhancements

Besides these major new features, Visual FoxPro 7 also has a number of minor enhancements. Many functions and commands have been updated. Messageboxes have timeouts (See IntelliSense in Figure 2), there is a new InputBox() function, there are a number of language enhancements concerning the creation of COM components, and so forth.

There also have been a number of enhancements in user interface objects. Buttons and other controls can have the hot-activate or flat look (see the toolbar in Figure 4), and menus can have icons and hidden items with the little chevron at the bottom to show them (allowing the developer to create Windows 2000-style smart menus).

What VFP 7 is not

The Microsoft .NET Framework (.NET) is more than just an updated version of Visual Studio, but rather a brand new way of developing software. Prior to the release of .NET, each of the Visual Studio development tools have had their own compilers. Even though they ship in the same box, they have always been separate programs that were not truly integrated together. Currently, when you create an application with one of these tools, you must also install that program's specific set of .DLLs on the client computer in order to run your application. .NET changes this methodology.

.NET is a well-defined application framework that provides your programs with various system and network services, multi-language development, and code reuse. With the .NET framework, however, programs written in VB, C++ and C# (a new language with its roots based on C++) are first compiled into Microsoft Intermediate Language (IL), which is then compiled and run by the Common Language Runtime (CLR). With the exception of C++, which will still have an option to compile with the native compiler, all .NET applications will automatically be compiled in the CLR.

Microsoft has recently announced that Visual FoxPro 7 will not target the CLR. However, because of the added features above, Visual FoxPro 7 will be able to easily interface with components created using the .NET Framework. Visual FoxPro will remain a strong development tool for creating parts of or entire n-tier applications. It is also the only .NET language with its own native data backend, making it ideal for applications that do not need to be in a distributed environment.

So, when Visual Studio.NET comes out, give “the Fox” a try. You might just find that it allows you to easily create a portion of your program that would have been difficult with the tools you have been using in the past.