Init, Destroy

These events fire when an object is created and when it’s released, respectively. They’re similar to the constructor and destructor methods of other OOP languages, but differ from those because they don’t actually perform the construction or destruction themselves.

Usage

PROCEDURE oObject.Init
[ LPARAMETERS [ nIndex , ] [ ParamList ] ]

PROCEDURE oObject.Destroy

For all objects except forms and formsets, Init and Destroy are the first and last events to fire. Forms and formsets also have Load and Unload events that bracket the others and let you handle opening of tables and the like. If the data environment is used, some of its events fire even before and after Load and Unload, respectively.

Init is a good place to do things that can’t be done at design-time, but need to happen right away. It’s also a good time to send messages to an object’s members, especially if they’re based on parameters passed to the container.

Init lets you short-circuit creation of an object. Returning .F. from Init creates the object reference, but sets it to .Null. Canceling creation of one object in a container doesn’t prevent the container from being created, however.

When dealing with containers, the Inits for the contained objects fire first (from the inside out) and the Init of the container fires last. On a form, this means that all the controls’ Inits fire before the form’s Init.

Destroy happens in the other order. The container’s Destroy fires first and it takes all the others with it, from the outside in.

This one's a documentation bug, not a product bug, we think. Like many other events, when the control that triggered it is a member of a control array (an array property holding references to objects), Init accepts a numeric parameter indicating which member of the array fired the event. Help doesn't show the nIndex parameter for Init. Destroy, on the other hand, is documented as accepting an nIndex parameter, but it's really hard to tell because it never fires at all.

Init is also the method to which you can pass parameters when you create an object. For all objects except forms and formsets, this makes a great deal of sense since Init fires first. With forms and formsets, it’s somewhat inconvenient because a lot of things happen before you reach the Init. But, we’re pleased by the consistency anyway.

There is one case where Load, rather than Init, receives parameters. When you’re dealing with a formset converted from FoxPro 2.6 (with WindowType = 2 or 3), parameters go to the Load Event, not to Init.

You’ll often want to hold onto the parameters passed to the Init method. Since the actual parameters themselves are released when the Init method ends, the trick is to create properties of the object and use Init to save the parameter values to the properties. Our example shows how.

Example

* This Init might be for a button.
PROCEDURE Init
LPARAMETERS cCaption, nTop, cSomethingElse

This.Caption = cCaption
This.Top = nTop
* You need to have added a custom SomethingElse property
* to the button for the next line to work.
This.SomethingElse = cSomethingElse

ENDPROC

See Also

Load Event, Unload