Although the script associated with a task may be designed to operate in a particular fashion, it is sometimes convenient if that behaviour can be modified. To this end the details for each task contain a set of optional fields which can be used to modify that task's behaviour. These fields are:
|Initial Passthru||This field contains the identity of a different passthru task. The first time the main task is called it will immediately suspend itself and pass control to the passthru task instead. When the passthru task has been completed it will return control to the main task which will carry out its normal processing using any parameters that may have been returned by the passthru task. These will appear in the
This mechanism is typically used for tasks of type LIST where it is required that a SEARCH screen be processed first. Any type of task can be used as the passthru task, but note that if it is a POPUP then the normal processing described in this FAQ will not be performed.
NOTE: If a task's session data is removed, such as by the keep data on exit option, then all memory of any previous activity for the task will be lost and any future activation of the task will be treated as if it were the first activation.
|Selection (fixed)||A task which is activated from the menu bar does not have a parent task, therefore cannot have any context passed down to it in the
Please note the following:
|Selection (temporary)||When a task of type LIST is activated it is possible for a child SEARCH screen to be activated in order to filter the data which is retrieved from the database by including additional search criteria. This temporary selection criteria will be loaded into the
Note the following:
|Settings||This provides the means to send parameters to the component in order to affect its behaviour. These parameters will be made available in $GLOBALS['settings']. The format is
Multiple entries may be defined by separating them with '&' as in
Any entries defined here will be available to any script which is run during the execution of this task, and will also be written out in the
Other settings may be used, but they will be ignored by the framework and therefore must be dealt with by custom code.
|Order By||This is only relevant for those tasks which retrieve multiple occurrences from the database. If used at all the contents of this field will be used in the ORDER BY clause of the SQL SELECT statement, so it should contain a valid field name, or a list of names separated by commas.|
|Keep Data on Exit||
This switch has the following options:
This should only be used for tasks of type LIST, POPUP or TREE which are suitable for restarting from the previous state. It will be ignored for enquire, update and delete forms where a new selection is always passed down from the previous form. If used in an ADD form it will cause the data for the previous addition to be loaded as default values, which could cause confusion.
A task can be in one of the following states:
When a task is active or suspended data is stored in the SESSION array so that if it is reactivated later it can resume processing from where it left off.
When a task is terminated, either by pressing the SUBMIT or CANCEL/CLOSE buttons, the default behaviour is to erase this data so that the next activation can start afresh. This behaviour can be altered by changing this switch from 'NO' to 'YES'.
NOTE: If control is passed to another task by any means other than by the use of the SUBMIT, CANCEL or CLOSE buttons then the data for the current task will remain in the session file. This data will be reused on the next activation unless it is overridden by new selection criteria.
|Run at End||This identifies the task which is to be run when the current task ends. For example, to implement the business rule "after viewing a sales order the user must always add a comment to that sales order" you set the run_at_end field of the "view sales order" task to "add a comment".
This facility has the following limitations:
|Run at Cancel||This identifies the task which is to be run when the current task is cancelled without performing a database update. For example, to implement the business rule "if the user is asked to add a comment to an order, but cancels, then a default comment must be added" you set the run_at_cancel field of the "add a comment" task to "add a default comment".
Note that if the run_at_cancel task has any user dialog it opens up the possibility that it may be cancelled before it completes its task.
If the main task performs a commit (database update) before it terminates then it wasn't cancelled, so the run_at_cancel task will not be run.