Sequence of execution of methods
The nature of the user interface in MorphX is event driven. This means that when an event recognized by MorphX occurs, the X++ programmer can modify the system’s default behavior if necessary. A table does not have a visual representation on it’s own. The only way to work with the data in your tables through the user interface, is through a form. Both forms and tables have methods that are executed in response to the actions performed by the end user. Below are descriptions of typical sequences of events that occur in a normal MorphX application.
When the end user… This sequence of table methods is called…
runs a form which is using a table as a data source. ----- HelpField
inserts a new record via a form using CTRL+N ----- InitValue
Jumps from field to field when entering data in a record by using the Tab key ----- ValidateField, HelpField
Enters a new record via a form and leaves the current record, for example,
by using the arrow keys to move to the next line in a grid ----- ValidateWrite, Write, Insert
Modifies an existing record via a form and leaves the current record,
for example, by using the arrow keys to move to the next line in a grid ----- ValidateWrite, Write, Update
places the mouse pointer over the current field in the current record in a form ----- TooltipField
Form :
This gives the information of method calls in the form level while
-
Opening the Form.
-
Creating/Updating/Deleting the record in the Form.
-
Closing the Form.
Sequence of Methods calls while opening the Form
Form — init ()
Form — Datasource — init ()
Form — run ()
Form — Datasource — executeQuery ()
Form — Datasource — active ()
Sequence of Methods calls while closing the Form
Form — canClose ()
Form — close ()
Sequence of Methods calls while creating the record in the Form
Form — Datasource — create ()
Form — Datasource — initValue ()
Table — initValue ()
Form — Datasource — active ()
Sequence of Method calls while saving the record in the Form
Form — Datasource — ValidateWrite ()
Table — ValidateWrite ()
Form — Datasource — write ()
Table — insert ()
Sequence of Method calls while deleting the record in the Form
Form — Datasource — validatedelete ()
Table — validatedelete ()
Table — delete ()
Form — Datasource — active ()
Sequence of Methods calls while modifying the fields in the Form
Table — validateField ()
Table — modifiedField ()
When you open a report, the following methods are called in the order that they appear in the table.
Method
|
Description
|
init
|
Initializes the report and its objects. This is the earliest method that can be overridden among those executed when a report is constructed and run.
Override this method to add initialization tasks, such as the following:
- Validation of the argument objects received
- Initialization of supporting classes
- Dynamic changes to the design
If your changes require access to the objects of the report, add your code after the super() call.
Caution Do not delete the super() call from this method. The super() call initializes all the objects of the report.
|
run
|
Runs the report. This method is executed when the user clicks OK on the preliminary specification dialog box of the report (which enables the user to select where to send the report, and so on).
The default version of this method does the following in the sequence shown:
1. Calls prompt.
1. Creates a basic design if it does not already exist.
1. Arranges the fields.
1. Calls fetch.
1. Calls print.
|
prompt
|
Prompts the user to select a print medium and other information.
Available mediums include paper, the screen, a print archive, .rtf, HTML, ASCII, .pdf, and text (UTF-8).
To disable the print medium selection, override the method, and then remove the call to super().
Caution Do not mistake this method for the method of the same name on a query.
|
fetch
|
Fetches records from the database. The fetch method instantiates a query, opens the query prompt, and then fetches the records.
During the execution of the fetch method, the next and get methods are executed in pairs on the query of the report. The send, the header and/or footer methods, and the progressInfo method are then executed. The cycle continues with calls to next, get, and so on, until all the data has been fetched.
The following are reasons for overriding the fetch method:
- The report is not based on a query.
- Some of the fetched data must be processed (this can also be done on the send method).
- The report is based on a temporary table.
|
print
|
Prints the report to the selected print medium, such as a printer, file, or screen.
|