Session D-BOSS

The BOSS and FoxExpress 2.6

Mike Feltman
Neon Software


The BOSS! - An Example of Developing an Application Using FoxExpress 2.6

 

 

The BOSS is an application that was created using FoxExpress 2.6. It also happens to be the in-house application that Neon Software uses to perform day-to-day operations. The beauty of The BOSS is that, while it is a fairly complex application, it was developed completely using FoxExpress 2.6. The purpose of this document is to take a look at how The BOSS was created.

In creating The BOSS we had needs that were specific to how we run the business. For example, there are times when we need to do mass mailings based on categories of customers. Another example is our need to track when we ship a software product, such as FoxExpress, to our users. Because of some of these needs, we added additional features to the application that could not be generated with FoxExpress. Lets take a look at how we addressed these specific needs using FoxExpress.

Before a screen could be created for Customer Information, the table(s) associated with the customers were created and added to the data dictionary. Through the data dictionary many options were selected. All of the fields were given descriptive screen prompts, format codes were specified and various lookup validation was selected.

Once the data dictionary setup of the customer table was complete, the was created as a main screen through FoxExpress. Other than moving some objects around and incorporating some boxes, the screen was ready to go.

After working with the Customer screen for a while, we ran into a problem with duplicate customers and the need to store additional information about customers, such as customer e-mail addresses and sales territory . FoxExpress supplies a built in method to check for duplicate entries into a single field, but not to check for duplicate entries based on the combination of multiple fields. In addition, in order to accurately check for duplicate customers, variances in how the individual operator entered the customers information needed to be accounted for as much as possible

In addition, we needed to categorize customers in some situation and that a particular customer could belong to more than one category. Neither of these items could be automatically generated through FoxExpress.

Creating a custom duplicate checking method for customers was actually quite easy from within FoxExpress and several features in FoxExpress made it easier to do than it would be without FoxExpress. We did the following:

  1. Added an additional field to Customer table that was the concatenation of all or a portion of several other fields in the customer table. We chose this approach so that an index could be created and a SEEK() could be used for performance reasons.
  2. Added a custom Add procedure that would allow the user to enter the fields necessary to check for duplicates only. A separate screen also made it easier to add the code necessary for the duplicate check and makes it clear to the user what fields need to be entered. Once this information was entered, the procedure checks to see if the customer is a duplicate. If so, the user is informed of this and allowed to select whether or not they would like to save the information. If the customer is not a duplicate, or the user chooses to save anyway, the values the user entered are transferred to the normal data entry screen and the user may continue the rest of the data entry.
  3. Added a custom Save procedure that would check the uniqueness of a customer before saving after an Edit.

In order to categorize customers, a table of categories needed to be created. We called this table Groups. The relationship between Customers and Groups is many-to-many since each customer can belong to more than one group and each group can contain more than one customer.

A third table, Customer Groups was established to store what groups each customer is a member of. Finally, we needed a data entry screen. Although we could have created a screen that allowed the user to simply enter the group name for each group they wanted to add a customer to, we knew there would be a relatively small number of groups and it would be easier for the user to select all the groups they wanted to add the customer to from a list of available groups. FoxExpress does not support a screen wizard for creating a screen of this type. This is how we did it:

  1. For the Groups to Customer side of the relation, we simply used a external window scrolling list screen. This side of the relationship was not as important as the other.
  2. For the Customer to Groups side of the relation, we had to look at what tools were available to us. We knew there was a template screen that allowed a user to select multiple options. This screen is used for Packing and Reindexing tables. The screen is called Multipop. We added a Groups push button to the Customer Information screen and wrote our own code to bring up the multipop screen. This code did the following:

Most of our users tell us that FoxExpress generates approximately 80% of an application, large or small, without changing a single line of code. Unfortunately, the other 20% are the items that are very specific to an application and are most likely more difficult to write. You must remember that FoxExpress generated applications are 100% FoxPro code and with a little creativity and liberal borrowing from other portions of your application, you can customize many of the pieces of your application and take advantage of the customization features in FoxExpress to meet your needs.