The bulk of the work in starting a FoxPro application has already been accounted for with the class aApplication. The main programs really boil down to stub programs that perform a few tasks. They are:
• Set the default path.
• Set the search path.
• Add include files (optional).
• Create an instance of the application object, aApplication.
In the next two sections I’ll create two main programs, one to load the framework files and one to start the application.
Main_Frame.prg
When working on the framework, you’ll want to load only the framework files. In practice, when developing applications, Frame_Main merely serves as the container for the class aApplication. The class definition is not repeated again here. In the source files provided, the class definition begins after the line oApp.SetRead().
Refer back to the requirements document. One requirement is that the application must run wherever launched. FoxPro provides us with a system function that returns a value specifying in which directory a program was started. Using JUSTPATH() returns the path portion of the start directory.
SET DEFAULT TO JUSTPATH(SYS(16,0))
The search path is set using relative paths. Again, the ability to start the application wherever launched is not compromised. Another key point is that none of the application folders are loaded here. Main_Frame should only be run while working on the framework.
SET PATH TO ";
.\,;
.\Meta\ ,;
.\FrameSource\ ,;
.\SysData\,;
.\Test\,;
.\Tools\ ;
54 Build Your Own Framework with Visual FoxPro
Following is the code of the main program in its entirety.
*-- First Task, set default directories and search path SET DEFAULT TO JUSTPATH(SYS(16,0))
The program required to start an application is similar to the one for the frame. Some differences exist. The differences are listed here and are explained following the code.
• Path
• An extra include
• Declare oApp as aApp
• Set procedure to framework main
*Main - Application
SET PROCEDURE TO "Main_Frame.prg" ADDITIVE
Chapter 5: Beginning Development 55
RELEASE goApp PUBLIC goApp
ON SHUTDOWN goApp.OnShutDown()
goApp = CREATEOBJECT('smpApplication') IF VARTYPE(goApp) = 'O'
goApp.SetRead() ENDIF
DEFINE CLASS smpApplication AS aApplication OLEPUBLIC cAppName = "Hello World"
FUNCTION OnLaunchApp()
MESSAGEBOX("Hello World",0, APP_NAME + ' of ' + BOOK_NAME) * Return .f. &&For testing. Returning False will close the app.
ENDFUNC ENDDEFINE
The SET PATH statement is similar to the one found in Main_Frame except that the framework folders SysData and SysSource are no longer included in the search path. Instead, the search path includes the application folders AppData and AppSource. Notice that by changing the search path, you can change the data used by the application. Changing the search path is one way to switch between pristine, test, and live data as mentioned earlier in the chapter.
A second difference is that the application’s main program is creating an object defined in a separate program file, Main_Frame.prg. Before you can instantiate the application object, Main_Frame must be loaded into memory. This is the only file ever loaded outside of the aApplication or smpApplication classes.
SET PROCEDURE TO "Main_Frame.prg" ADDITIVE
Placing the ON SHUTDOWN call inside the application class works. However, a dependency exists between ON SHUTDOWN and CREATEOBJECT, namely that both rely on the presence of goApp. Don’t set a trap for application developers who want to use a different variable name for goApp (for example, oApp).
ON SHUTDOWN goApp.OnShutDown()
A sample application (the obligatory “Hello World”) has been included for this chapter. It illustrates how to use the OnLaunchApp() method of the application class to start an
application. Notice that I used the application object properties cAppName and cFramework to build the MessageBox() caption.
FUNCTION OnLaunchApp()
MESSAGEBOX(THIS.cAppName,0, THIS.cFramework)
* Return .f. &&For testing. Returning False will close the app.
ENDFUNC
56 Build Your Own Framework with Visual FoxPro
Overwriting the default behavior of OnLaunchApp() is an example of how you can tailor the aApplication class to meet the needs of the application developer.
Summary
Much has gone into the setup of this framework. The benefit of your hard work is that the application developer has a well-defined, flexible approach with which to begin each application. Flexibility is easily obtained by subclassing aApplication and overwriting or extending the methods provided. If further modifications are required, I have provided two template methods that are clear and easy to comprehend.
Updates and corrections to this chapter can be found on Hentzenwerke’s Web site, www.hentzenwerke.com. Click “Catalog” and navigate to the page for this book.
Chapter 6: Creating a Class Library 57
Chapter 6 Creating a Class Library
A class library is a set of reusable classes, programs, and functions. It is the
foundation—the lowest level on which your framework is built. Factors to consider when structuring your class library include creating a single point of entry into the framework, understanding the role inheritance plays in extending behavior, and giving the
application developer the ability to tap into the power of your class library. This chapter illustrates how to properly structure your class library.
You start the process by creating a set of base classes. Visual FoxPro 8.0 provides 43 classes for you to build upon (Textbox, Label, Custom, Session, and so on). Each subclass of the FoxPro base classes is the most general and least specialized class in your class hierarchy.
Consider the text box, which is a general tool for collecting and presenting data. It does not know which data format to use, whether the data entered into it is valid or when it is appropriate for users to view the data it contains. A text box is not a specialized class.
In this chapter, you will learn how to apply the concept of inheritance to your class structure. From your base classes you begin the process of specializing each class by further subclassing your base classes. You will learn where to add functionality; that is, methods (behavior) and properties (state) in your class structure to maximize the benefits of inheritance while minimizing some of the risks associated with a poorly designed inheritance structure.
This chapter illustrates these concepts with detailed examples. The final segment of this chapter concludes with a review of how your class design affects the application developer and a recommendation of the approach you should consider.