Builders let you run any application code you want, on demand, at design time, within the Form Designer or Class Designer design surfaces. The implications of this will be explored by FoxPro developers for months to come, and there will be a lot of great ideas for how to tap into the power of Builders.
Time permitting, we'll take a look at issues you'll want to consider when writing your own Builders and at some sample ideas for how to take advantage of Builders to leverage them in your development work.
When your Builder runs, you'll undoubtedly want to offer users the chance to cancel the changes they made through the Builder and revert the selected control(s) back to their original state. To do this, you need to save the initial state by going into the Builder and restoring properties on exit.
Most Builders should be re-entrant, i.e., the controls in the Builder should reflect the initial state of their corresponding properties when the Builder is invoked. For example, if a command-button Builder offers users a way to a button's caption, the Builder is called "Print". The Builder's interface should reflect the current value when the Builder appears. This requires code in the Load and Init methods of the Builder to query the existing value of the property in the underlying control, and to set the value of the Builder's controls.
Every control has a native Error method that gets called in the event of an error.
The Properties window is quite robust and can often handle expressions for properties that normally expect non-character settings. Because the controls in the Form Designer are, in many ways, "live" controls and because a Builder is trying to update property settings directly, i.e., outside the Property window, some special handling is necessary to give such properties expression values. The design-time only methods ReadExpression() and WriteExpression() allow Builders to do this.
ReadMethod() and WriteMethod() are two other useful design-time methods that Builders can use to write code to control methods.
When multiple controls are selected, the Builder may want to apply a change to all of them. In this event, the Builder needs to cycle through the array of selected objects.
Builders can use various techniques to receive or discover references to other objects that exist, when they are running and make changes to those objects.
Builders offer a natural opportunity for Rapid Application Development (RAD). The Builders that ship with the product are an efficient, convenient way to set the most common properties of controls. Custom Builders you write and register can provide an essentially unlimited opportunity to accelerate the development process for common, repeatable application components. Custom Builders automate your development process to some degree, thereby offering many opportunities for the faster writing of safer, more consistent processes.
Builders can look to metadata as well as users for new values of property settings and methods.
Builders don't have to be visual; an example of a useful Builder with no UI might be to take selected objects and apply a standard set of formatting and style conventions to all of them. A Builder might also run through the method code in the selected controls and ensure that a desired naming convention is used. Corporate standards for applications may thereby be enforced through such tools.
Builders could be written to support the different needs of different developers, or groups of developers, within a large programming effort. By registering the Builders appropriately, some developers could get some Builders, while others get different Builders.
Builders are a natural vehicle for third-party add-on tools. If you offer a particular development methodology, you might create a suite of Builders to help your customers use your tools and to automate some of the standard tasks that they perform.