FoxPro provides a system variable, _Builder, where you register the name of the program that will execute when the Builders are invoked. When you call a Builder, the product looks to the contents of _Builder and tries to run this program. By default on installation, _Builder is set to BUILDER.APP and is placed in the directory where FoxPro is installed.
To call a different Builder program, change the value of _Builder:
_Builder = "c:\mydir\mybldr.app"
BUILDER.APP is a basic driver program which performs various "housekeeping" duties, including saving and restoring many environment settings. Its fundamental task is to find the Builder appropriate to run at the moment it is called, invoke that Builder, and then clean up and return you to the Form Designer.
BUILDER.APP looks to a registration table called BUILDER.DBF (and its memo file, BUILDER.FPT), which by default is installed in the \WIZARDS subdirectory. The registration table is where the Builders that ship with the product are registered and the place where you register any custom Builders you write. The basic registration approach is the same as used for registering Wizards and the structure of the Builder registration table is the same as the Wizard registration table:
Field Name |
Data Type |
Description |
Name |
Character |
Name of the Builder |
Descript |
Memo |
Description of the Builder |
Bitmap |
Character |
N/A for Builders |
Type |
Character |
The internal call invoked by VFP |
Program |
Memo |
Any specific program or app to invoke a specific Builder |
Classlib |
Memo |
The VCX file that contains the Builder |
Classname |
Memo |
The class name of the Builder |
Parms |
Memo |
Parameters(s) passed to _BUILDER if necessary |
Note the registration table's Data Type field which contains the word that identifies the Builder class. For the Builders that ship with FoxPro, these map to the BaseClass property of the native controls on which these Builders are designed to operate.
When BUILDER.APP is called, it looks first to the Class and then to the BaseClass properties of the selected control(s) on the form being designed. BUILDER.APP then looks to the Type field of the registration table to find a Builder match type. If it finds only one, it simply invokes that Builder. If it finds more than one applicable Builder, it will bring up a list offering users a choice of Builders. If no applicable Builders are found, it will state that there are no registered Builders for this type and return you to the Form Designer.
The registration table's Program, Classname and Classlib fields offer one way to register builders. If your specific Builder is in the form of an .APP, put the name of the .APP in the Program field and BUILDER.APP will run this application. If the Builder is a class in a class library, put the class name and class library name in their respective fields, and BUILDER.APP will create an instance of this class and show it.
Another and completely different way to register a Builder is to give a subclassed control a custom property named "Builder," and register the desired Builder for this control class in this property. If the property exists and has a value, BUILDER.APP will attempt to run this program, bypassing the normal registration table process entirely.
Because you can add a custom property such as "Builder" only in the Class Designer, the control cannot be a native BaseClass control, but instead needs to be a class residing in a class library.