The Class type is important here. If you have a VFP Custom class – e.g. you are running an imported scx as an scp – then the order is as Cyril says and load comes first (more here).
If you are talking about the Lianja Object Model (LOM): Pages, Sections, Fields/Gadgets etc. then load follows init.
Lianja where it’s start ?
first Page in the App is the starting point in terms of display. Prior to this, the setup.prg (if exists) will be run, the init, load and ready events will be run (http://www.lianja.com/community/show…ence-of-events) along with any database open event / table open trigger scripts. The first visible Page is also dependent on Page read roles (http://www.lianja.com/community/show…ence-of-events) – the user will see the first Page they have permission to ‘read’.
Which event is best suited for deinitializing variables / setting flags etc?
Destroy comes last after Unload – Page1 Unload, Page1 Destroy, Page2 Unload, Page2 Destroy, … , App Unload, App Destroy. Public variables are released and the database is closed after the App Destroy delegate has run.
The events are called in that order: init, load, ready, activate with the App first:
– first Page
— first Page’s first Section
— first Section’s Fields
— first Page’s second Section
— second Section’s fields
– second Page
If a variable is required by a particular component it would normally be declared/initialised in its init or the init earlier in the hierarchy. The database is available to the load events. For visual properties, such as the section.collapse(), wait until the internal loading and display have completed – put them in the ready event for the component.
The ‘Change’ (xxx_changed()) delegate is called when a record is modified – after ‘After Data Update’ (xxx_afterupdate()).
The ‘After Data Changed’ (xxx_datachanged()) delegate is called on Form Sections after the data is read – as you move through the records.