Utilizing Object-Oriented Programming Methodology …Utilizing Object-Oriented Programming...

Utilizing Object-Oriented ProgrammingMethodology to Maintain Modification

First Release: December 1999Last Modified: January 2000

The information contained in this document represents the current view of AccountMate SoftwareCorporation on the issues discussed as of the date of publication.

This document is for informational purposes only. ACCOUNTMATE MAKES NO WARRANTIES,EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Copyright © 1999 by AccountMate Software Corporation. All Rights Reserved.

Visual AccountMate Modification Guideline

Utilizing Object-Oriented Programming Methodology to Maintain Modification 2

Purpose

This Modification Guideline provides information about the additional steps thatneed to be performed during software customization, so only minimal work isrequired to upgrade the modification from one Visual AccountMate (VAM) build toanother.

Audience

The primary audience for this Modification Guideline is any AccountMateBusiness Partner (BP) who customizes Visual AccountMate by modifying itsscreen forms from the Source Code. This includes BPs who modify VAM on acase-by-case basis for endusers, as well as BPs who create their own add-onmodules, by modifying other VAM screen forms, that integrate with one of moreVAM modules.

Program Versions and Builds Affected

This Modification Guideline applies to all versions (Version 1.x to Version 5.x)and builds of Visual AccountMate products (VAM/LAN, VAM/SQL and VAM/400)that were developed with Microsoft’s Visual FoxPro.

Introduction

AccountMate may release several new builds (either major or minor) for its VAMproduct lines each year. Both the groups described above need the ability toeasily carry their modifications forward when AccountMate releases a new build.When new builds are released, BPs working with endusers for whom theyperform custom modifications lose revenue through two primary channels: (1)accrual of unbillable time for work spent carrying these modifications forward and(2) potential loss of sales because effort is not focused in that area of theirbusiness. BPs with add-on modules lose revenue because they are spendingtoo much time maintaining their modifications rather than focusing on developingnew features, as well as more sales, for their modules.

Most software customization in VAM involves modification of AccountMatescreen forms (.SCX) by adding, deleting and/or moving form controls andchanging program code to include additional business logic. At the same time,AccountMate may continue to change the same screen forms to include newfeatures and/or correct program errors. When both the BP and AccountMatechange the same screen form, how to effectively consolidate the changesbecomes an issue. Many BPs have been modifying VAM screen forms byadding program “hooks” to the .SCX files to call their modification code, which isstored in an external file such as a .PRG file. When new builds are released,



BPs have to add these program “hooks” back into the updated screen forms thathave been changed by AccountMate. Depending on the size of thecustomization project, it may take anywhere from minutes to hours to consolidatethe changes. In a worse scenario, BPs would modify AccountMate screen formsby making changes directly to the form controls. This modification approachcreates too many changes (in terms of number of places modified) to a screenform and thus increases the time needed to consolidate the changes in futurebuilds. Although some third party development tools can compare thedifferences of two versions of the same screen form, BPs could only use thesetools to report the differences. They still need to manually consolidate thechanges.

In Visual FoxPro object-oriented programming environment, form controls areinstantiated (or “inherited”) from some visual classes with the Form Designer.(Form controls can also be instantiated programmatically from non-visualclasses.) As long as the form controls’ characteristics and behavior (i.e.,properties, events and methods) are not modified in a screen form, any changesto the visual classes will automatically be brought forward to the screen form.

Solution

The ultimate solution to ensure efficiency in carrying modifications forward withnew builds is to isolate the modification from the AccountMate screen forms.This allows BPs to maintain their changes in one place, while AccountMatemaintains its own changes in another place. To achieve this, you need to treatan AccountMate screen form as one single object that you are not going tomodify. You can save an AccountMate screen form as a visual class, use thevisual class as the form base (i.e., form class), and continue to make changes onthe form with VFP’s Form Designer. This approach leaves only a BP’smodification on the form (.SCX). When AccountMate releases a new version ofthe same form, you just need to rebuild the visual class (i.e., the form class) bysaving the form as a visual class again. No change is needed on the screenform, unless there are conflicts between BP’s changes and AccountMate’schanges.

The step-by-step process to implement this solution is outlined below.

Step 1: Save AccountMate Screen Form as a Visual Class

In the example below, the Customer Maintenance form (ARMCUST.SCX) isused. This is the form that is originally received from AccountMate’s AccountsReceivable or Sales Order Source Code. After opening this Visual FoxProscreen form, save it as a visual class by using the Save As Class… Option onthe File menu. This will save the entire form, including all the form controls, as avisual class. The only element that cannot be save as part of visual class is theform’s Data Environment.



Figure 1. Saving AccountMate Form as a Visual Class

The original name of this form is ARMCUST.SCX. In order to maintainconsistency and reduce confusion later on, the form name “armcust” is used asthe new visual class name. The visual class can be saved in any visual classlibrary.

In the case of a form set, the entire form set will be saved as a visual class.Simply select the Entire form set option rather than the Current Form option onthe Save As Class window (Figure 2).

Please note that “armcust” is a container class; and components of a containerclass cannot be deleted at design time.

This step only needs to be done for the forms that you will be modifying, NOT allthe AccountMate forms. To simplify the maintenance of these visual classes, it isnot recommended to create too many visual class libraries. In this example, youcan just save all the visual classes into a visual class library called “mod.vcx”. Ifyou will be modifying many AccountMate forms and thus will be creating manyvisual classes, you may want to create a visual class library for each module,such as ”ar.vcx”, “ap.vcx”, etc.



Figure 2. Inputting the Form Name as the Visual Class Name

Step 2: Delete All Form Controls from the Screen Form

In this step, the process of deleting all the objects that are part of original form“armcust.scx” begins. These objects include the page tabs, labels, text boxes,check boxes, etc. To delete all form controls, select all of the form controls, byselecting the Select All option on the Edit menu, and press the <Delete> button.

In the case of a form set, all forms needs to be removed. When you are down tothe last form on the Form Designer, use the Remove Form Set option to removethe form set. If you bring up the Properties dialog box, you should see only 1object – the form itself.



Figure 3. Selecting All Form Controls for Deletion

A blank customer maintenance form now exists which has replaced the originalarmcust.scx. However, all the “non-default” properties, events and methods stillremain with the form. Since these properties, events and methods have beensaved in the visual class, they do not need to be kept with the screen form.

The following few steps will guide you through the process to remove the form’sproperties, events and methods.



Figure 4. An Empty Customer Maintenance Form with No Form Controls

Step 3: Perform Screen Form Changes with the VFP Browse Window

Visual FoxPro screen forms are saved in a table format. Therefore, the .SCX filecan be opened and browsed as a regular table. What remains in the .SCX filenow are the Data Environment and the form object itself. Since the DataEnvironment is not saved with the visual class, it will be kept in the screen form.As the form’s non-default properties, events and methods are saved with thevisual class, they should be removed from the .SCX file.

VFP screen forms are saved as in a table (.DBF) format; and each object on thescreen form is saved as a record in the .SCX file. To perform the above changesto the form object, the record for the form object should be located. The followingcommands can be used in the Visual FoxPro Command Window to open thescreen form as a table and to locate the form object.

CD C:\VAMUSE forms\armcust.scxLOCATE FOR baseclass = “form”BROWSE

Step 4: Change the Form Class

Since the original screen form has been saved as a visual class, that visual classwill now be used as the “base” to create the form object, which includes the pagetabs and all other controls on the form. Type the following command in the



Visual FoxPro Command Window to change the Class value from “efrm” to“armcust” (the visual class name established in Step 1).

&& after locating the record for form classREPLACE Class WITH “armcust”

Please also note that the Class property is read-only at both design time and runtime.

The two following figures show the value of the Class field before and after thechange.

Figure 5. Value of Form Class Before Change



Figure 6. Value of Form Class After Change

When the form class is changed, the class library that contains the class shouldalso be changed. Instead of using “efrm” of the EDITCTR.VCX, you are nowusing “armcust” of the “MOD.VCX” (as established in Step 1) as the form’s baseclass. The class library name is saved in the Classloc field of the form record.Type the following command in the Visual FoxPro Command Window to changethe Classloc value from “..\editctr.vcx” to “..\mod.vcx”.

&& after locating the record for form classREPLACE Classloc WITH “..\mod.vcx”

The two following figures show the value of the Classloc field before and afterthe change.



Figure 7. Class Library Name for Form Object Before Change

Figure 8. Class Library Name for Form Object After Change

If the new visual class is a form set, the Baseclass field should also be changedfrom “form” to “formset”, so it will continue to be inherited as a form set.



Step 5: Remove Form Properties

All the form properties have been saved with the visual class “armcust”;therefore, the properties originally saved with the screen form can now beremoved. However, you still want to maintain the Name property in the form.This allows the form to have a different name from the visual class. It alsoeliminates the necessity of changing any program code that references to theform name (e..g, “EfrmCust”). The form properties can be removed directly fromthe memo value of the Properties field.

If this is for a form set, the form name property contains the name of the form thatyou did not remove. Since the form was changed to become a form set in theprevious step (i.e., change in the Baseclass field), its name should also beenchanged to reflect the original name of the form set (e.g., “FrsInvc” for the InvoiceTransaction form).

The two following figures show the value of the Properties field before and afterthe change.

Figure 9. Value of Properties Field Before Change



Figure 10. Value of Properties Field After Change

Step 6: Remove Form Methods

Similar to the form properties, all form methods need to be deleted from thescreen form (.SCX). All form methods, including user-defined methods, havebeen saved in the visual class “armcust”. As screen forms are saved, VisualFoxPro compiles all method codes into object codes to be used at run-time.

Please note that Visual FoxPro executes only compiled code at run-time. This isalso why running screen forms (.SCX) externally does not create any significantperformance difference.

Type the following command in the Visual FoxPro Command Window to removethe values in the Methods and Objcode fields.

&& after locating the record for form classREPLACE Methods WITH “”, Objcode WITH “”

The two following figures show the value of the Methods and Objcode fieldsbefore the change. Both fields will become empty after the change.



Figure 11. Value of Methods Field Before Change

Figure 12. Form’s Object Code Before Change

Step 7: Final Screen Form Ready for Modification

At this point, the screen form is left without non-default properties and methodsand is instantiated from the new visual class “armcust”. This form is ready formodification.



Figure 13. Screen Form Using the New Form Class as Base Class

All the modification will continue to be saved in the .SCX file; and only themodification, whether interface changes or coding changes, will be saved in this.SCX file. You have now successfully separated your modification fromAccountMate’s source code.

Step 8: Repeat Step 1 for Updated AccountMate Forms

After receiving a new screen form from AccountMate when a new build isreleased, simply repeat Step 1 by saving the form as a visual class, using thesame visual class name previously used. As long as the modified form continuesto have “armcust” class as the parent class, any changes on AccountMate’supdated screen form have now been merged with the modification. It is notnecessary to make any additional changes to the modified form.

This step is needed only for forms that AccountMate updated and on which thereis modification.

Limitations

The original form (with many objects) is saved as a container class. When acontainer class is added to a screen form, no part of the container class can beremoved. When you need to remove objects in a container class, you can eithermake these objects disabled (Enabled property = .F.) or invisible (Visibleproperty = .F.). Please note that when you make an object invisible, the object is



still visible at design time. Also, be very careful when you disable an object atdesign time. The object may become enabled at run time when it is built fromclasses in AccountMate’s EDITCTR.VCX class library. As indicated in thetechnical manual, the Enabled property of these classes is changedprogrammatically in the Refresh() event, depending on the form’s EditModeproperty.

Since the save form’s Data Environment cannot be saved with the visual class, itremains to be part of the .SCX file. Whenever AccountMate makes changes tothe Data Environment, the changes have to be brought forward (from theupdated screen form) to the modified version of the screen form manually.

There may be conflicts between AccountMate changes and BP’s modification.As you receive a new build, you should review the updatedAccountMateComment() method on each form that AccountMate changed anddetermine if any of the AccountMate changes will cause any conflict with yourmodification.

Utilizing Object-Oriented Programming Methodology …Utilizing Object-Oriented Programming...

Documents

Transcript of Utilizing Object-Oriented Programming Methodology …Utilizing Object-Oriented Programming...