Session E-APP

Application Development:
Anatomy of the Visual FoxPro Development Cycle

Andrew Ross MacNeill
Melton Technologies Inc

Introduction

Take a peek inside the development of a Visual FoxPro application. There are a lot of new concepts and ideas that need to be considered as well as pitfalls and traps. Using the example of a transaction-based event-driven system, the session describes the building blocks of OOP as they are used in building an application framework. This is not a session about theory but about how to apply the OOP theory in practice and business development.

The application being designed is still in development - it’s not finished by any means. However it is nearing the final stages and has been released into a limited beta with its particular customers. Is this session the final word on VFP development? No but it offers a guideline of one application’s development cycle.

Many sessions cover the theory of application development. This session goes into a detailed description of the problems encountered in building an application in the initial version of Visual FoxPro. The application in question is an event-driven system, using the concept of events as transactions within a business system. Before the application was started, a lot of thought went into what could be tried with Visual FoxPro. A lot of this discussion took place during the beta and therefore couldn’t be realized in the final product. This session talks about things that worked and things that didn’t so as developers, you don’t need to make the same mistakes when working on your first, second or third application.

There are many different approaches to application design. This session discusses one of them but it also sheds some light on the others. The most important point to realize is that there is no "holy grail" in Visual FoxPro application design, regardless of what others may say. One area where strong suggestions are made is in the tools to use. Some tools, like CodeBook, are very specific and require a particular methodology. Others are generic tools that you can use anywhere in application design. If you find new tools, please share them with everyone. One of the benefits of user groups is the opportunity to share your thoughts. As you find out new tools, share your experiences with others.

This application is not based on a formal methodology. During its initial stages, the approach taken was based on Design Patterns but as other tools became known, the foundation grew. As better tools came along, new approaches were taken.

 

Design, Design, Design

This may seem like a redundant point but it’s not. Designing your application before you write a single line of code is more important in Visual FoxPro than it ever was in FoxPro 2.x. Why is it so important? In order to build a powerful Visual FoxPro application, you need a powerful set of class libraries. In order to have strong class libraries, you need to have some kind of idea as to how your application will work.

However, don’t take a company’s design methodology and instantly believe it will work for you. A common comment about building applications in Visual FoxPro is that your very first application will take six months and then you will throw it out and really start building it.

When starting to build an application, the most important component is getting everyone to agree on a single concept. Under database applications, it becomes increasingly important. The Conceptual design needs to discuss the entire approach to development, the application and the implementation of the product. The worst thing that can happen in development is a customer says "build me an invoicing system" and leaves. Both the developer and the customer will probably have two entirely different visions as to what the system will look like. Here are some areas that we seriously started looking into.

One aspect of designing Windows applications is that consistency needs to be retained throughout the entire application. Visual FoxPro makes it easy to create Windows 95 compliant applications and that is something that shouldn’t be just discarded in the design process. This isn’t just so your application can get a "logo" but so that end users who have never used your application before but have used Windows are able to work with your application much faster than otherwise. In fact, if you build vertical market applications, you may not want a Win 95 Compliant logo but even having some standard features in your software will make a world of difference.

Here is what is required to make an application Windows 95 "logo-compliant" (paraphrased from Microsoft):

  1. An application must use the Win32 application programming interface (API) and must be compiled using a 32-bit compiler that generates an executable file of the Portable Executable (PE) format.
    Since Visual FoxPro supports this, your application does, too.
  2. An application must support the Windows 95 shell and user interface. At a minimum, an application must meet the following requirements:
  3. An application must be tested on the latest version of Microsoft® Windows NT™. If the application uses features that are available only in Windows 95, the features must degrade gracefully in Windows NT. Conversely, if it uses features available only in Windows NT, the features must degrade gracefully in Windows 95. The application must run successfully with both Windows 95 and Windows NT, unless architectural differences between the two operating system prevent it.
  4. 4. An application must support long filenames and use them to display all document and data filenames in the shell, in title bars, in dialog boxes and controls, and with icons. In addition, an application should hide the extensions of filenames that are displayed within the application itself.
    Unless you use file names within your application, in which case you already support this, you can simulate this by using longer names in your Window titles.
  5. 5. An application should process Plug and Play events. For example, it should be aware of slow links and should react to system messages that occur when a new device is attached or removed.
    This is a hardware issue however, your error handler can deal with these issues if you want as well.
  6. 6. An application must support Universal Naming Conventions (UNC) names for paths.
    This means that it should be able to run on a network using paths like \\Network_server\APPS\FoxPro.
  7. 7. An application must support OLE containers or objects, or both. It must also support the OLE style of drag and drop. An application should also support OLE automation and compound files (with document summary information included).
    OLE objects are supported in the General field.
  8. 8. An application must support simple mail enabling using the Messaging Application Programming Interface (MAPI) or the Common Messaging Call (CMC) API. That is, it must include Send Mail functionality.

Another way of making an application easier to learn is following MS Office standards. MS Office standards are a little easier and more visual in nature.

  1. Use standard menu options. At the very least, File, Edit, View, Window and Help.
  2. Use MS Office style toolbars.

We also included neat features that were very easy to implement. They included:

Here is a sample of the form:

This has changed a great deal in the final version of the software.

The other decision that was made early on was an agreement on a common application form. A standard form was created that had a list of information on the left hand side and then a Page Frame on the right. The Page Frame only had three frames which related to three different ways of looking at information: General, Events and Show Me. General information was information directly related to a table, like Customer Name, Address, etc.
Event information listed activities that affected the customer. Show Me depicted information about the Custom in a graphical or tabular fashion. The end result was that not only did every form look similar, it also became a lot easier to train with.

There are two types of documentation: user documentation and specification documentation. User documentation was someone else’s area of expertise however, certain ground rules were laid:

  1. Three documents should be written: User Tutorial, Reference Manual and Tips.
  2. All documents should be written with standards so it can be converted into Help Files quickly.

The majority of the documents will be online which is fitting based on the trends in documentation today. Only the user tutorial was to be a consideration for hard copy.

One of the things that was proposed was following a standard of documenting our proposals for specifications. The template for this specification is included on the diskette. It is not designed for customers but for developers and team development. The application specification accompanies the logical data model diagrams as a structure for the overall application diagram. It provides a way of showing work progress during the early phases of development

 

Application Interface Specification

This document ... [introduction to the document].

Revision History
Date Author Description
[Today’s Date] [Your Name Here] Creation of document and template
     

 

Overview

The main purpose of the Overview is to provide an overall foundation for the specification. Each component of the application had its own specification, error handlers, security and more. The Overview section was designed to give the reader enough information to understand its purpose without getting into details.

[Describe the overall purpose of the item being described]

[Describe the basic issues that a person must understand to follow this document]

[Describe what you want to accomplish with the document and the item being specified]

[Provide a brief overview of the application features]

[Identify any outstanding issues]

 

Specifications

Because each component had its own set of specifications, this area was generally left empty. This allowed the writers to build their own set. For larger components that involved multiple components, a standard class specification wasn’t useful. Here is the basic one used for class specifications. Anytime there was special code or behaviour occuring, there would be a separate entry in the document

List Of Related Documents

Since there were so many different components to the application, a list of related documents was kept relatively up to date. This area wasn’t used as much as it could have been.
Filename Author/Owner Description
     
     

 

Building Base Libraries

The first step in building our base libraries was defining what was important and what was not. As a result, we had two sets of base libraries: one that was simply a duplicate of existing FoxPro base classes and another which was our set of base classes. The first set was actually written with code that said "If an object is ever created with this as the class, disallow it" , ie don’t let it be created. The other set was a subset of the first and that was the one that we worked with.

This diagram shows how the items appeared. In BASE.VCX, all of the generic features required in the application were added. We built into our base classes all of the standard behaviour to be expected by all objects. A Version method was added to all of the classes. It was decided to make the Version property a method so that it was easier to determine if things had been updated or not. By asking for x = THIS.Version( ), additional items could be done in the Development environment as well. We added every FoxPro class into our BASE class library, including separators, toolbars, options and commandgroups.

Hint: You can create classes of any object in Visual FoxPro via the Command window, including objects that don’t "appear" to have a visual representation. Example: CREATE CLASS appSeparator OF BASELIBS.VCX AS Separator. This works for creating classes for Pages, Options and Command Group commands.

Additional tools eventually made it into the application libraries as they did, a new set of libraries were created for each one. This was very important for team development. Separate libraries made it easier to split the work between the individuals. It also brought out an important aspect of Visual FoxPro development.

Developer Tip: If you create larger class libraries (ie greater than 100 classes), do not add the library to the Controls toolbar. Visual FoxPro will take too long to show the toolbar and may even crash. When dealing with these kinds of libraries, use the Project Manager Classes tab to drag and drop the classes onto a form.

Here is a list of the ways the class libraries were broken down:
Name of Library Purpose
BASE Base Object Library
BASE2 Application Objects, including base class for Application class.
Basically each Visual FoxPro object had one related class in BASE2.
CONTROLS Contained various controls to be used in application
SECURITY Security Class Library that included all aspects of security
ERROR Error Handler
DATA Data classes for handling, processing and preprocessing of data
COMMANDS Contained individual Command custom classes
FORMS Contained individual form classes. This was separated from BASE2 to make it easier to get access to.

 

Data Model

One of the most important components of any database application is obviously the data. In Visual FoxPro, it is important to realize that an application is not limited to DBF files any longer. Visual FoxPro makes Client/Server development much easier and because of that, external sources of data need to be taken into consideration.

The best tool we found creating our data model was FoxCase or xCase. This is a third party tool that creates Visual FoxPro DBC files and the associated DBF files. It also checks for model integrity.

The other tool we used frequently was Visio Technical Edition. This provided templates for various OOP modeling structures that we used. In fact we used Visio more for Object modeling than data modeling.

This was team development from the beginning. Different ideas, different approaches all played a part in building the data model. The first step was to create a Logical model. This model didn’t take into consideration Visual FoxPro’s powerful features - it simply identified entities and some key attributes. When it came time to implementing Visual FoxPro, it was agreed that as long as any physical model could be related back to the logical model, at least a foundation had been built.

 

Data Classes

There are numerous ways of handling data management in Visual FoxPro. It is possible to rely 100% on dropping database fields into forms and letting FoxPro and the DBC container manage the process. However, when building an application, it helps to have a bit more structure to it.

Flash’s CodeBook model suggests that applications contain "business objects" that are basically the equivalent of a form container with all of the various fields for a business object, i.e. table. A major benefit of this is that in order to refer to a single business object, the developer drops the class onto a form and the class contains all of the various labels and text boxes required for editing. Another great benefit of this is that users get a consistent approach to single data.

A problem with this is that with large sets of data, it is very difficult to put everything into a single business object class and therefore, you must create separate classes for the same table. Another drawback is that it is difficult to pull out individual field information from the business object.

 

The approach taken was to build container classes that included a label to identify what the item was and then the visual interface for the object. In most cases, this was a Text box but in other cases, such as when working with Child tables, it was a combo box or a picture or icon. For some child tables, Grids were used. As this was a container, other custom commands were able to be contained within the container so that it was an all-encompassing data object.

The biggest drawback with this approach was the time that it took to build the classes and the number of classes that had to be built. The class library held over 500 classes which made it imperative to use the Project Manager instead of the toolbar to work with the option.

A major benefit however, was that a "form editor" was able to be built that allowed users to create their own forms. By making use of this approach, users were able to select the fields they wanted without having to worry about any validation.

 

Event Management

The application being designed was written to coordinate business events. Without going into too much detail about the overall application, the approach used to handle event management is shown here.

The Event Manager Class is a composite class made up of various objects that identify how it reacts. When an event occurs, it is "registered" with the Event Manager that then determines the various Event Handler Objects to work with. An Event Object is verified against an Event Handler object by using its VerifyStructure method. Each event object within the class has a similar structure to the main event class but may react differently by using a different DefaultMethod.

The following diagram shows the breakdown of how system and business events could coexist within the same event handler.

There were several structural issues involved in the building of the Event Manager:

Everything in the Event Manager was a container. This was done to separate the implementation from the interface. Every handler had a consistent interface - what was different was the actions each handler performed. This was handled by using Standard Methods and then having the standard method call the default action of another member in the Handler container. Here are the standard methods used:

Execute - scanned through every object in the container, looked for property called DefaultMethod and then ran that method. This allowed greater flexibility in making changes as the objects in the containers could have originated in another class library.

DefaultMethod - returned the name of the custom method that an object used to perform its default action.

VerifyStructure - Whenever an event occured, it was transformed into an object. (usually done with a SCATTER NAME command) The VerifyStructure method verified that a particular handler could in fact, handle a particular event.

This approach works well in any environment and is based on the foundation for Design Patterns. The power in this approach is that other handlers can be added to the environment in no time at all and as one handler is improved, it doesn’t require stopping other development. It works well in a strong team environment.

 

 

Review

Well, halfway thru it all, the documentation side falls apart. Why? One, because we’re developers and we don’t like to document our work. Realistically though, it’s difficult to build a next generation application if you have to stop and document your work. It’s required. What usually ends up happening is a document provides a spring board into the overall module and then we have to go back and update the document. Is this a good approach? Maybe but more likely not. Unfortunately, there’s no way to enforce documentation or is there?

Visual FoxPro is built around providing easy to use tools. The difficulty with tools is that each user has to learn to use them in day to day activity. It’s like coding standards. Originally, we decided that all code would be written in expanded style (no MODI COMM or DIME statements) But when working, it can be very distracting to have to rewrite your work while you’re on an inspiration kick. There’s nothing stopping a development team from using powerful tools to ensure documentation is done. Here are some of our tricks that we tried to use:

CEE - Cobb’s Extension Editor (freeware)

This is a great tool that allows you to build "macros" that automatically expand. When you type DIME, it automatically expands it to DIMENSION. To aid in commenting code, if you type HEADER, it asks you to fill in the blanks and inserts the following into your program:

CEE is also good for doing block commenting and uncommenting.

XILIGHTS - Color-coded Editor (shareware for Standard Edition)

This is a nice little addon that color-codes all of your code so you can see the difference between comments, FoxPro keywords and your own variables.

Visual FoxPro is still a very young product and all of the tools required to make it a perfect development tool aren’t available yet. Here are the few tools and OCXs that we found were the most helpful:

ScrollBars.OCX - made creating a visual environment wonderful ('Michael Loeckle, 75051,734)

Object Explorer - made debugging of our objects very easy (Markus Egger 100337,1062 )

FoxCase - see section on Data Modeling

Visio - see section on Data Modeling

Windows 95 - this provided a great deal of inspiration when stuck on an interface issue

However, the best tool we had was Visual FoxPro. It is a wonderful tool for application development. We were able to build and rebuild components very quickly across the board.

 

Did they really help? Well, yes and no. They provided a mechanism for changing the interface very easily but they also provided an overhead that was very difficult to work with. The most important rule that could be learned from Design Patterns however is:

SEPARATE IMPLEMENTATION FROM INTERFACE

In Visual FoxPro terms, this means put any visual interface item into a container and call methods from within the container. This allows you great flexibility if you ever decide to change your application.

As I stated in the introduction, there are many different approaches to application design. The most important point to realize is that there is no "holy grail" in Visual FoxPro application design, regardless of what others may say. The best thing you can do is find your tool of choice, document it, build on it and share your experiences with others. This makes application development more of a fun adventure, rather than a difficult journey.

 

 

SPEAKER

Andrew Ross MacNeill is Software Architect at Melton Technologies Inc. (MTI), a company that exists in various countries but most noticeably through CompuServe. Andrew is the author of GENMENUX as well as several other public domain tools. A MS Certified Professional, Andrew was the recipient of the Microsoft Most Valuable Professional award for 1995 and has written several articles for various FoxPro magazines around the world. He has spoken at several conferences, including the first German developers' conference in 1994. Andrew can be reached on CompuServe at 76100,2725 or 76100.2725@compuserve.com for those who use the Internet.