Related Topics
Form Events are actions that occur on a form, to which you can add custom actions of your own. Many events fire automatically as part of the form's natural life cycle. For instance, when a form is first opened, an event called Form Creation is fired. Some events, on the other hand, are manually fired. A Button control, for example, has an event that fires when the button is clicked, and this event is built into the Button control automatically. Additionally, form input controls can also be set as an Event Field in the properties you configure on the Form Controls tab of the Form definition. These controls will fire an event when the data in the control is changed. Any time an event fires, you can configure an action to run on the event, such as a Set Form Data action, or running a Custom Task. For example, you might place a Button control on a form, and on the event for that button, run a Custom Task that converts the form to a PDF document.
Form events can be accessed from a Dropdown control that lists all of the available events on the form. This dropdown is primarily used on the Set Form Data and Custom Task Event Mapping tabs, though it appears anywhere that an event is applicable.
This dropdown displays all of the available events that can be used to attach actions to the Form. By default, the dropdown shows only the events built into the form's life cycle, but any buttons or other event controls you place on the form will be automatically added to the selections displayed in the dropdown. The table below describes the default events that occur as part of the form's life cycle.
|
Event |
Description |
|---|---|
| Form Creation | Fired when a Form instance is called for display. |
| View State Init | Fired on the preparation of the Form for display. |
| Event | Fired on any Event |
| Before Conditions | Fired before any Form conditions, such as visibility or enabling conditions on controls, are called. |
| After Conditions | Fired after all Form conditions have been processed. |
| Before Validation | Fired when the Form has been submitted, but before any Form validation conditions are evaluated. |
| After Validation | Fired after all validation conditions have been processed. |
| Form Display | Fired when the form is actually displayed in the browser. All Fill Dropdown actions, form calculations for Calculation and Sum controls, and other automated form update events, are automatically processed on the Display event. |
| Form Completed | Fired after the form's display has been ended (i.e., when the form closes), and just prior to the form being disposed from memory. |
| No Event | Placeholder to prevent an action from firing on any event. |
| Ajax Request | Fired when a client-side JavaScript Ajax request is processed. |
So far, we've just talked about Form events in the context of the user interface, but Process Director also enables custom scripts to be run, and the script actions also run on the same events that UI configuration uses. Additionally, Custom Tasks also run on the same events.
The order of operations for these different actions is:
- Custom scripts: Scripted actions always run first on any event.
- UI and Datasets: After the custom scripts complete, the UI or Dataset actions, such as Set Form Data or Fill Dropdowns, will run.
- Custom Tasks: Custom Task run after all other actions.
The order in which the actions run is very important. For instance, if you want to configure the Set Form Data tab to run an action that is based on some data pulled from a Custom Task, you can't run both the Set Form Data action and the Custom Task action on the same event. The Custom Task will not run before the Set Form Data action, only after it. In such a case, you might have to run two Custom Tasks, with the first Custom Task retrieving the data, then running the Set Form Data Custom Task second, to ensure that the operations happen in the order you desire.
Additional advanced information on Form events from a scripting perspective can be found in the Custom Scripting and Form Class documentation in the Developer's Guide.
Documentation Feedback and Questions
If you notice some way that this document can be improved, we're happy to hear your suggestions. Similarly, if you can't find an answer you're looking for, ask it via feedback. Simply click on the button below to provide us with your feedback or ask a question. Please remember, though, that not every issue can be addressed through documentation. So, if you have a specific technical issue with Process Director, please open a support ticket.
