Load, Unload

These events are the first and last to fire for a form or formset (though DataEnvironment events occur before Load and after Unload).

Usage

PROCEDURE oObject.Load
PROCEDURE oObject.Unload

In VFP 3, despite documentation to the contrary, Load and Unload do not receive the optional nIndex parameter when the form or formset is contained in an array. In VFP 5 and later, Load does receive the nIndex parameter, but Unload does not. Go figure. (None of this is a big deal since there’s no reason ever to use Control Arrays.)

When dealing with contained objects, the Init of the inner objects fires before the Init of the container. This means, for forms, the controls within the form fire their Init before the form itself and that the form’s Init runs before the formset’s. This presents a problem for data-bound controls. Opening tables in the form’s Init is too late. The controls need the tables open earlier.

One solution is to use the form’s data environment and let it handle all the table opening, relations, SETs and so forth. However, form classes don’t have a data environment, and it’s complicated to get SCX-based forms to use your own DataEnvironment subclass. So, some people avoid the data environment entirely and handle table management themselves.

Enter Load. It fires before the control’s Inits and lets you open tables, establish relations, and so forth, so the controls have access to the data they need. You can also handle form-wide settings in Load. Remember that many of the SET commands are scoped to individual data sessions, so things like SET TALK OFF need to occur in every form that uses a private data session. (We suggest having the Load method of your master form class call a custom method to take care of this stuff. Then, all your other forms can inherit from that class.)

Unload serves the same role at the end of the form. The form’s Destroy fires before the Destroys for the individual controls, so tables can’t be closed there. You can do it in Unload (or in the data environment.)

In forms created by converting FoxPro 2.x screens, the Load method is the one that accepts parameters. (These are forms with WindowType = 2 or 3.) Any parameter statement in the Setup snippet of the 2.x screen is moved to the Load method automatically in a functional conversion.

The Unload method also is the place to return a value from a modal form. If you put a RETURN statement in Unload and call the form with DO FORM whatever TO variable, the returned value ends up in the specified variable. One warning here—by the time Unload fires, the controls on the form have been destroyed and their properties don’t exist anymore. You can’t return the Value of some control, for example. Instead, in that control’s Destroy event, save the Value to a form property, then return the form property in Unload.

Example

PROCEDURE Load
* Set things up
SET DELETED ON
SET TALK OFF

RETURN

See Also

DataEnvironment, Destroy, Form, FormSet, Init