Triggers for Printing
Much report writing is data-driven—you might want to print a number of different things in different situations, depending on the data in the report. This involves using conditional ProcScript that checks what is happening in the form and directs the print process accordingly.
In report components, the exec operation should contain a retrieve instruction to obtain data, and a print instruction to start the print process. No edit or display instruction is given because no online edit session of data is necessary.
|
Trigger |
Remarks |
|---|---|
|
The print trigger lets you control any print process initiated by the user. You can write ProcScript in this trigger which tests for certain conditions (such as the user's privileges), or you can leave it empty and add print processing code in other triggers. |
|
|
Never use this trigger for anything other than retrieve profiles. Uniface automatically activates the read trigger when the necessary data is not in the component. This is an automatic process that is mostly outside your influence, so you can never be completely sure when Uniface activates the read trigger. The I/O processing is similar for all components. however, in a default print process, Uniface fetches all hits from selected hitlists by automatically firing read triggers where necessary. |
|
|
The entity's getFocus trigger is used for checks before printing an occurrence. For example, at this level you can decide not to print the occurrence if certain conditions are not met. Each occurrence that is read is a candidate for inclusion in the print file. Before it is sent to this file, Uniface executes the getFocus trigger of the entity. |
|
|
The leavePrinted trigger is used for checks or actions which occur after printing an occurrence. Uniface executes this trigger every time an occurrence of an entity has been printed. Be aware that the occurrence is still active at that point. |
|
|
Uniface activates the lock trigger if data in an occurrence is modified. If the original data from the DBMS is modified in the form before or during printing, this can lead to lock conflicts which upset printing. If you are sure that you never want to write the data in the form back to the DBMS, you should disable this trigger and disable updates for all entities on the form. To disable updates during printing, create the form with behavior Limited. (Report components have behavior Limited by default.) |
|
|
The getFocus trigger in a header or footer frame is activated when the line in which the frame definition can be found becomes current: For a header frame, as a new page is started. For a footer frame, as its position at the bottom of the page is reached. For break frames, the printbreak statement implicitly activates the getFocus trigger for the break frame named in the ProcScript statement. |
Use the getFocus and leavePrinted triggers of entities, and getFocus trigger of frames to control what happens as your report is printed.
Trigger Execution Sequence
The sequence of trigger execution follows the component's data structures. In a component containing an outer entity and an inner entity, the global sequence of trigger execution is as follows:
-
exec operation. The retrieve ProcScript statement executes the read trigger of the outer entity. The print ProcScript statement starts the print process.
-
Outer Entity: read . This trigger builds a hitlist and returns to the exec operation.
-
Inner Entity: read . This trigger completes the hitlist with occurrences of the inner entity.
-
Outer Entity: getFocus. This trigger executes for each occurrence. If occurrences for the inner entity exist, the inner entity triggers are executed in between the getFocus and leavePrinted triggers of the outer entity.
-
Inner Entity: getFocus and leavePrinted. These triggers execute for each occurrence of the inner entity.
-
Outer Entity: leavePrinted. This trigger executes for each occurrence of the outer entity.
